linux-dev/arch/arm/mach-moxart, branch master

ARM: rework endianess selection

2022-04-08T15:20:54Z

Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago. The problems is that CONFIG_BIG_ENDIAN depends on ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform in the config, but would actually have to be supported by all of them. This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and tend to just work aside from problems in nonportable device drivers. For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM were never set together, so this was disabled on all those machines except for IXP4xx. As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to formalize this logic: all ARMv4/v5 platforms get an explicit dependency on being either big-endian (ixp4xx) or little-endian (the rest). We may want to fix ixp4xx in the future to support both, but it does not work in LE mode at the moment. For the ARMv6/v7 platforms, there are two ways this could be handled a) allow both modes only for platforms selecting 'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the others, given that these were added intentionally at some point. b) allow both modes everwhere, given that it was already possible to build that way by e.g. selecting ARCH_VIRT, and that the list is not an accurate reflection of which platforms may or may not work. Out of these, I picked b) because it seemed slighly more logical to me. Signed-off-by: Arnd Bergmann

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157

2019-05-30T18:26:37Z

Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Richard Fontana Reviewed-by: Kate Stewart Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46Z

Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/fttmr010: Merge Moxa into FTTMR010

2017-06-12T08:45:10Z

This merges the Moxa Art timer driver into the Faraday FTTMR010 driver and replaces all Kconfig symbols to use the Faraday driver instead. We are now so similar that the drivers can be merged by just adding a few lines to the Faraday timer. Differences: - The Faraday driver explicitly sets the counter to count upwards for the clocksource, removing the need for the clocksource core to invert the value. - The Faraday driver also handles sched_clock() On the Aspeed, the counter can only count downwards, so support the timers in downward-counting mode as well, and flag the Aspeed to use this mode. This mode was tested on the Gemini so I have high hopes that it'll work fine on the Aspeed as well. After this we have one driver for all three SoCs and a generic Faraday FTTMR010 timer driver, which is nice. Cc: Joel Stanley Cc: Jonas Jensen Signed-off-by: Linus Walleij Reviewed-by: Joel Stanley Tested-by: Joel Stanley Signed-off-by: Daniel Lezcano

irqchip/faraday: Replace moxa with ftintc010

2017-04-07T09:36:30Z

The Moxa Art interrupt controller is very very likely just an instance of the Faraday FTINTC010 interrupt controller from Faraday Technology. An indication would be its close association with the FA526 ARM core and the fact that the register layout is the same. The implementation in irq-moxart.c can probably be right off replaced with the irq-ftintc010.c driver by adding a compatible string, selecting this irqchip from the machine and run. As a bonus we have an irqchip driver supporting high/low and rising/falling edges for the Moxa Art, and shared code with the Gemini platform. Acked-by: Olof Johansson Tested-by: Jonas Jensen Signed-off-by: Linus Walleij Signed-off-by: Marc Zyngier

Merge tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

2016-08-01T22:21:13Z

Pull ARM SoC cleanups from Olof Johansson: "The cleanup branch keeps going down in size as we've completed a lot of the major legacy platform removals and conversions. A handful of changes this time around, some of the themes or larger sets are: - A bunch of i.MX cleanups around platform detection, init call cleanups - Misc fixes of missing/implicit includes - Removal of ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB" * tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (40 commits) ARM: mps2: fix typo ARM: s3c64xx: avoid warning about 'struct device_node' bus: mvebu-mbus: make mvebu_mbus_syscore_ops static bus: mvebu-mbus: fix __iomem on register pointers ARM: tegra: Remove board_init_funcs array ARM: iop: Fix indentation ARM: imx: remove cpu_is_mx*() ARM: imx: remove last call to cpu_is_mx5* ARM: imx: rework mx27_pm_init() call ARM: imx: deconstruct mx3_idle ARM: imx: deconstruct mxc_rnga initialization ARM: imx: remove cpu_is_mx1 check ARM: i.MX: Do not explicitly call l2x0_of_init() ARM: i.MX: system.c: Tweak prefetch settings for performance ARM: i.MX: system.c: Replace magic numbers ARM: i.MX: system.c: Remove redundant errata 752271 code ARM: i.MX: system.c: Convert goto to if statement ARM: Kirkwood: fix kirkwood_pm_init() declaration/type ARM: Kirkwood: make kirkwood_disable_mbus_error_propagation() static ARM: orion5x: make orion5x_legacy_handle_irq static ...

clocksource/drivers/moxart: Add the COMPILE_TEST option

2016-06-28T08:22:08Z

Change the Kconfig option logic to fullfil with the current approach. A new Kconfig option is added, CONFIG_MOXART_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up to the platform's Kconfig to select the timer. Signed-off-by: Daniel Lezcano

ARM: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB

2016-06-03T19:18:13Z

This replaces: - "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB" as this can now be selected directly. - "select ARCH_WANT_OPTIONAL_GPIOLIB" with no dependency: GPIOLIB is now selectable by everyone, so we need not declare our intent to select it. When ordering the symbols the following rationale was used: if the selects were in alphabetical order, I moved select GPIOLIB to be in alphabetical order, but if the selects were not maintained in alphabetical order, I just replaced "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB". Cc: Michael Büsch Cc: arm@kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Linus Walleij Signed-off-by: Olof Johansson

ARM: use "depends on" for SoC configs instead of "if" after prompt

2015-12-01T21:44:51Z

Many ARM sub-architectures use prompts followed by "if" conditional, but it is wrong. Please notice the difference between config ARCH_FOO bool "Foo SoCs" if ARCH_MULTI_V7 and config ARCH_FOO bool "Foo SoCs" depends on ARCH_MULTI_V7 These two are *not* equivalent! In the former statement, it is not ARCH_FOO, but its prompt that depends on ARCH_MULTI_V7. So, it is completely valid that ARCH_FOO is selected by another, but ARCH_MULTI_V7 is still disabled. As it is not unmet dependency, Kconfig never warns. This is probably not what you want. The former should be used only when you need to do so, and you really understand what you are doing. (In most cases, it should be wrong!) For enabling/disabling sub-architectures, the latter is always correct. As a good side effect, this commit fixes some entries over 80 columns (mach-imx, mach-integrator, mach-mbevu). [Arnd: I note that there is not really a bug here, according to the discussion that followed, but I can see value in being consistent and in making the lines shorter] Signed-off-by: Masahiro Yamada Acked-by: Maxime Ripard Acked-by: Nicolas Ferre Acked-by: Heiko Stuebner Acked-by: Patrice Chotard Acked-by: Liviu Dudau Acked-by: Krzysztof Kozlowski Acked-by: Jun Nie Acked-by: Matthias Brugger Acked-by: Simon Horman Acked-by: Gregory CLEMENT Acked-by: Shawn Guo Acked-by: Sebastian Hesselbarth Acked-by: Thierry Reding Acked-by: Krzysztof Halasa Acked-by: Maxime Coquelin Signed-off-by: Arnd Bergmann

ARM: use menuconfig for sub-arch menus

2014-06-17T15:09:48Z

The System Type menu is getting quite long with platforms and is inconsistent in handling of sub-arch specific options. Tidy up the menu by making platform options a menuconfig entry containing any platform specific config items. [arnd: change OMAP part according to suggestion from Tony Lindgren ] Signed-off-by: Rob Herring Signed-off-by: Arnd Bergmann