summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2017-10-30Merge tag 'amlogic-soc' of ↵Arnd Bergmann6-6/+493
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into next/soc Pull "Amlogic SoC updates for v4.15" from Kevin Hilman: - add SMP support to Meson8/8b * tag 'amlogic-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: ARM: meson: enable MESON_IRQ_GPIO in Kconfig for meson8b ARM: meson: Add SMP bringup code for Meson8 and Meson8b ARM: smp_scu: allow the platform code to read the SCU CPU status ARM: smp_scu: add a helper for powering on a specific CPU dt-bindings: Amlogic: Add Meson8 and Meson8b SMP related documentation
2017-10-30Merge tag 'imx-soc-4.15' of ↵Arnd Bergmann7-92/+14
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/soc Pull "i.MX SoC changes for 4.15" from Shawn Guo: - A series from Marco Franchi from to clean up build warnings see with W=1 in arch/arm/mach-imx/. - Move i.MX6 speed grading check from i.MX platform code to cpufreq driver. The patch is suggested by cpufreq folks to go through arm-soc tree. - Enable cpuidle support on i.MX6DL starting from IMX_CHIP_REVISION_1_1. - Constify platform_suspend_ops for MXS platform. * tag 'imx-soc-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: cpufreq: imx6q: Move speed grading check to cpufreq driver ARM: imx: Enable cpuidle for i.MX6DL starting at 1.1 ARM: imx: mach-mx31lite: Make mx31lite_map_io static ARM: imx: cpuidle-imx5: Include "cpuidle.h" header file ARM: imx: 3ds-debugboard: Include "3ds_debugboard.h" header file ARM: imx: imx31moboard: Include "board-mx31moboard.h" header file ARM: mxs: constify platform_suspend_ops
2017-10-30Merge tag 'arm-soc/for-4.15/soc-part2' of ↵Arnd Bergmann4-1/+46
http://github.com/Broadcom/stblinux into next/soc Pull "Broadcom soc changes for 4.15 (part 2)" from Florian Fainelli: This pull request contains Broadcom ARM-based SoC changes for 4.15 (second part), please pull the following: - Florian adds support for the Broadcom Hurricane 2 SoC machine entry point and defines the debug UART address for use with earlyprintk/DEBUG_LL * tag 'arm-soc/for-4.15/soc-part2' of http://github.com/Broadcom/stblinux: ARM: debug: Add Hurricane 2 UART2 debug addresses ARM: bcm: Add support for Broadcom Hurricane 2 SoC
2017-10-30Merge tag 'arm-soc/for-4.15/defconfig' of ↵Arnd Bergmann1-0/+1
http://github.com/Broadcom/stblinux into next/soc Pull "Broadcom defconfig changes for 4.15" from Florian Fainelli: This pull request contains Broadcom ARM-based SoCs multi_v7_defconfig file updates for 4.15, please pull the following: - Florian enables the Broadcom Hurricane 2 SoC in multi_v7_defconfig (CONFIG_ARCH_BCM_HR2) * tag 'arm-soc/for-4.15/defconfig' of http://github.com/Broadcom/stblinux: ARM: multi_v7_defconfig: Enable CONFIG_ARCH_BCM_HR2
2017-10-30Merge tag 'keystone_config_4.15' of ↵Arnd Bergmann1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone into next/soc Pull "ARM: Keystone config update for 4.15" from Santosh Shilimkar: ARM: Enable PWM driver config * tag 'keystone_config_4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone: ARM: configs: keystone: Enable TIECAP PWM driver
2017-10-30Merge tag 'amlogic-defconfig' of ↵Arnd Bergmann1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into next/soc Pull "Amlogic: defconfig updates for v4.15" from Kevin Hilman: - enable SDIO/MMC controller * tag 'amlogic-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: ARM: multi_v7_defconfig: enable the Meson MX SDIO/MMC controller
2017-10-30Merge tag 'imx-defconfig-4.15' of ↵Arnd Bergmann1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/soc Pull "i.MX defconfig updates for 4.15" from Shawn Guo: - Turn on DRM_DW_HDMI_CEC option to get HDMI CEC support. - Enable MUX_MMIO to get ADV7180 probe on Gateworks GW51xx boards. * tag 'imx-defconfig-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: imx_v6_v7_defconfig: Select the CEC driver ARM: imx_v6_v7_defconfig: Select CONFIG_MUX_MMIO
2017-10-30Merge tag 'sunxi-core-for-4.15' of ↵Arnd Bergmann1-0/+1
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into next/soc Pull "Allwinner core changes for 4.15" from Maxime Ripard: A bunch of patches for the sunxi documentation and mach-sunxi. The most notable feature is the introduction of the R40 support. * tag 'sunxi-core-for-4.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: ARM: sunxi: add support for R40 SoC ARM: sunxi: fix the core number of V3s in sunxi README dt-bindings: add compatible string for Allwinner V3s SoC
2017-10-30Merge tag 'uniphier-fixes-v4.14' of ↵Arnd Bergmann3-8/+16
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier into fixes Pull "UniPhier ARM SoC fixes for v4.14" from Masahiro Yamada: - Add necessary clock to EHCI node * tag 'uniphier-fixes-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier: arm64: dts: uniphier: add STDMAC clock to EHCI nodes ARM: dts: uniphier: add STDMAC clock to EHCI nodes
2017-10-30i2c: gpio: Augment all boardfiles to use open drainLinus Walleij11-24/+32
We now handle the open drain mode internally in the I2C GPIO driver, but we will get warnings from the gpiolib that we override the default mode of the line so it becomes open drain. We can fix all in-kernel users by simply passing the right flag along in the descriptor table, and we already touched all of these files in the series so let's just tidy it up. Cc: Steven Miao <realmz6@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Wu, Aaron <Aaron.Wu@analog.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-30i2c: gpio: Convert to use descriptorsLinus Walleij17-121/+153
This converts the GPIO-based I2C-driver to using GPIO descriptors instead of the old global numberspace-based GPIO interface. We: - Convert the driver to unconditionally grab two GPIOs from the device by index 0 (SDA) and 1 (SCL) which will work fine with device tree and descriptor tables. The existing device trees will continue to work just like before, but without any roundtrip through the global numberspace. - Brutally convert all boardfiles still passing global GPIOs by registering descriptor tables associated with the devices instead so this driver does not need to keep supporting passing any GPIO numbers as platform data. There is no stepwise approach as elegant as this, I strongly prefer this big hammer over any antsteps for this conversion. This way the old GPIO numbers go away and NEVER COME BACK. Special conversion for the different boards utilizing I2C-GPIO: - EP93xx (arch/arm/mach-ep93xx): pretty straight forward as all boards were using the same two GPIO lines, just define these two in a lookup table for "i2c-gpio" and register these along with the device. None of them define any other platform data so just pass NULL as platform data. This platform selects GPIOLIB so all should be smooth. The pins appear on a gpiochip for bank "G" as pins 1 (SDA) and 0 (SCL). - IXP4 (arch/arm/mach-ixp4): descriptor tables have to be registered for each board separately. They all use "IXP4XX_GPIO_CHIP" so it is pretty straight forward. Most board define no other platform data than SCL/SDA so they can drop the #include of <linux/i2c-gpio.h> and assign NULL to platform data. The "goramo_mlr" (Goramo Multilink Router) board is a bit worrisome: it implements its own I2C bit-banging in the board file, and optionally registers an I2C serial port, but claims the same GPIO lines for itself in the board file. This is not going to work: there will be competition for the GPIO lines, so delete the optional extra I2C bus instead, no I2C devices are registered on it anyway, there are just hints that it may contain an EEPROM that may be accessed from userspace. This needs to be fixed up properly by the serial clock using I2C emulation so drop a note in the code. - KS8695 board acs5k (arch/arm/mach-ks8695/board-acs5.c) has some platform data in addition to the pins so it needs to be kept around sans GPIO lines. Its GPIO chip is named "KS8695" and the arch selects GPIOLIB. - PXA boards (arch/arm/mach-pxa/*) use some of the platform data so it needs to be preserved here. The viper board even registers two GPIO I2Cs. The gpiochip is named "gpio-pxa" and the arch selects GPIOLIB. - SA1100 Simpad (arch/arm/mach-sa1100/simpad.c) defines a GPIO I2C bus, and the arch selects GPIOLIB. - Blackfin boards (arch/blackfin/bf533 etc) for these I assume their I2C GPIOs refer to the local gpiochip defined in arch/blackfin/kernel/bfin_gpio.c names "BFIN-GPIO". The arch selects GPIOLIB. The boards get spiked with IF_ENABLED(I2C_GPIO) but that is a side effect of it being like that already (I would just have Kconfig select I2C_GPIO and get rid of them all.) I also delete any platform data set to 0 as it will get that value anyway from static declartions of platform data. - The MIPS selects GPIOLIB and the Alchemy machine is using two local GPIO chips, one of them has a GPIO I2C. We need to adjust the local offset from the global number space here. The ATH79 has a proper GPIO driver in drivers/gpio/gpio-ath79.c and AFAICT the chip is named "ath79-gpio" and the PB44 PCF857x expander spawns from this on GPIO 1 and 0. The latter board only use the platform data to specify pins so it can be cut altogether after this. - The MFD Silicon Motion SM501 is a special case. It dynamically spawns an I2C bus off the MFD using sm501_create_subdev(). We use an approach to dynamically create a machine descriptor table and attach this to the "SM501-LOW" or "SM501-HIGH" gpiochip. We use chip-local offsets to grab the right lines. We can get rid of two local static inline helpers as part of this refactoring. Cc: Steven Miao <realmz6@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Magnus Damm <magnus.damm@gmail.com> Cc: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Heiko Schocher <hs@denx.de> Acked-by: Wu, Aaron <Aaron.Wu@analog.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Ralf Baechle <ralf@linux-mips.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-10-30hwmon: (sht15) Root out platform dataLinus Walleij1-7/+10
After finding out there are active users of this sensor I noticed: - It has a single PXA27x board file using the platform data - The platform data is only used to carry two GPIO pins, all other fields are unused - The driver does not use GPIO descriptors but the legacy GPIO API I saw we can swiftly fix this by: - Killing off the platform data entirely - Define a GPIO descriptor lookup table in the board file - Use the standard devm_gpiod_get() to grab the GPIO descriptors from either the device tree or the board file table. This compiles, but needs testing. Cc: arm@kernel.org Cc: Marco Franchi <marco.franchi@nxp.com> Cc: Davide Hug <d@videhug.ch> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Marco Franchi <marco.franchi@nxp.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-10-29ARM: dts: meson: add the efuse nodeMartin Blumenstingl4-0/+31
Meson6, Meson8 and Meson8b use a similar IP block which has access to 512 bytes of efuse data. During SoC manufacturing some calibration settings for the CVBS connector and the internal temperature sensor are written to this efuse. On some boards it additionally stores for example the MAC addresses. The efuse is enabled on Meson8 and Meson8b but kept disabled on Meson6 since we do not have a clock driver there (which is required to read data from the efuse). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-29ARM: dts: meson8b: enable gpio interrupt controllerJerome Brunet2-0/+15
Add gpio interrupt controller node to the meson8b boards Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-29ARM: meson: enable MESON_IRQ_GPIO in Kconfig for meson8bJerome Brunet1-0/+1
select MESON_IRQ_GPIO in Kconfig for Amlogic's meson8b SoC Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-29ARM: dts: meson8b: add support for booting the secondary CPU coresCarlo Caione1-0/+21
Booting the secondary CPU cores involves the following nodes/devices: - SCU (Snoop-Control-Unit, for which we already have a DT node) - a reset line for each CPU core, provided by the reset-controller which is built into the clock-controller - the PMU (power management unit) which controls the power of the CPU cores - a range in the SRAM specifically reserved for booting secondary CPU cores - the "enable-method" which activates booting the secondary CPU cores This adds all required nodes and properties to boot the secondary CPU cores. Signed-off-by: Carlo Caione <carlo@caione.org> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-29ARM: dts: meson8: add support for booting the secondary CPU coresMartin Blumenstingl1-0/+21
Booting the secondary CPU cores involves the following nodes/devices: - SCU (Snoop-Control-Unit, for which we already have a DT node) - a reset line for each CPU core, provided by the reset-controller which is built into the clock-controller - the PMU (power management unit) which controls the power of the CPU cores - a range in the SRAM specifically reserved for booting secondary CPU cores - the "enable-method" which activates booting the secondary CPU cores This adds all required nodes and properties to boot the secondary CPU cores. Suggested-by: Carlo Caione <carlo@caione.org> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-29ARM: meson: Add SMP bringup code for Meson8 and Meson8bMartin Blumenstingl4-0/+443
This adds the necessary SMP-operations and startup code to use the additional cores on the Amlogic Meson8/Meson8m2 (both are using the same sequence) and Meson8b (using a slightly difference sequence) SoCs. Signed-off-by: Carlo Caione <carlo@endlessm.com> [add Meson8/Meson8m2 support and allow taking CPU cores offline as well] Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-29ARM: smp_scu: allow the platform code to read the SCU CPU statusMartin Blumenstingl2-1/+23
On Amlogic Meson8 / Meson8m2 (both Cortex-A9) and Meson8b (Cortex-A5) the CPU hotplug code needs to wait until the SCU status of the CPU that is being taken offline is SCU_PM_POWEROFF. Provide a utility function (which can be invoked for example from .cpu_kill()) which allows reading the SCU status of a CPU. While here, replace the magic number 0x3 with a preprocessor macro (SCU_CPU_STATUS_MASK) so we don't have to duplicate this magic number in the new function. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-29ARM: smp_scu: add a helper for powering on a specific CPUMartin Blumenstingl2-10/+31
To boot the secondary CPUs on the Amlogic Meson8/Meson8m2 (Cortex-A9) and Meson8b (Cortex-A5) SoCs we have to enable SCU mode SCU_PM_NORMAL, otherwise the secondary cores will not start. This patch adds a scu_cpu_power_enable() function which can be used to enable SCU_PM_NORMAL for a specific (logical) CPU. An internal helper function is also created, to avoid code duplication with scu_power_mode(). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-10-28Merge tag 'for-linus-4.14c-rc7-tag' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - a fix for the Xen gntdev device repairing an issue in case of partial failure of mapping multiple pages of another domain - a fix of a regression in the Xen balloon driver introduced in 4.13 - a build fix for Xen on ARM which will trigger e.g. for Linux RT - a maintainers update for pvops (not really Xen, but carrying through this tree just for convenience) * tag 'for-linus-4.14c-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: maintainers: drop Chris Wright from pvops arm/xen: don't inclide rwlock.h directly. xen: fix booting ballooned down hvm guest xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()
2017-10-26arm/xen: don't inclide rwlock.h directly.Sebastian Andrzej Siewior1-1/+1
rwlock.h should not be included directly. Instead linux/splinlock.h should be included. One thing it does is to break the RT build. Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: xen-devel@lists.xenproject.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2017-10-26ARM: dts: mvebu: pl310-cache disable double-linefillYan Markman3-6/+6
Under heavy system stress mvebu SoC using Cortex A9 sporadically encountered instability issues. The "double linefill" feature of L2 cache was identified as causing dependency between read and write which lead to the deadlock. Especially, it was the cause of deadlock seen under heavy PCIe traffic, as this dependency violates PCIE overtaking rule. Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration") Cc: stable@vger.kernel.org Signed-off-by: Yan Markman <ymarkman@marvell.com> Signed-off-by: Igal Liberman <igall@marvell.com> Signed-off-by: Nadav Haklai <nadavh@marvell.com> [gregory.clement@free-electrons.com: reformulate commit log, add Armada 375 and add Fixes tag] Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-10-25ARM: OMAP3: Delete an unnecessary variable initialisation in ↵Markus Elfring1-1/+1
omap3xxx_hwmod_init() The local variable "bus" will eventually be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2017-10-25ARM: OMAP3: Use common error handling code in omap3xxx_hwmod_init()Markus Elfring1-8/+8
Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2017-10-25locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns ↵Mark Rutland3-3/+3
to READ_ONCE()/WRITE_ONCE() Please do not apply this to mainline directly, instead please re-run the coccinelle script shown below and apply its output. For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't harmful, and changing them results in churn. However, for some features, the read/write distinction is critical to correct operation. To distinguish these cases, separate read/write accessors must be used. This patch migrates (most) remaining ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following coccinelle script: ---- // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and // WRITE_ONCE() // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch virtual patch @ depends on patch @ expression E1, E2; @@ - ACCESS_ONCE(E1) = E2 + WRITE_ONCE(E1, E2) @ depends on patch @ expression E; @@ - ACCESS_ONCE(E) + READ_ONCE(E) ---- Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: davem@davemloft.net Cc: linux-arch@vger.kernel.org Cc: mpe@ellerman.id.au Cc: shuah@kernel.org Cc: snitzer@redhat.com Cc: thor.thayer@linux.intel.com Cc: tj@kernel.org Cc: viro@zeniv.linux.org.uk Cc: will.deacon@arm.com Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24linux/compiler.h: Split into compiler.h and compiler_types.hWill Deacon1-2/+1
linux/compiler.h is included indirectly by linux/types.h via uapi/linux/types.h -> uapi/linux/posix_types.h -> linux/stddef.h -> uapi/linux/stddef.h and is needed to provide a proper definition of offsetof. Unfortunately, compiler.h requires a definition of smp_read_barrier_depends() for defining lockless_dereference() and soon for defining READ_ONCE(), which means that all users of READ_ONCE() will need to include asm/barrier.h to avoid splats such as: In file included from include/uapi/linux/stddef.h:1:0, from include/linux/stddef.h:4, from arch/h8300/kernel/asm-offsets.c:11: include/linux/list.h: In function 'list_empty': >> include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' [-Werror=implicit-function-declaration] smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \ ^ A better alternative is to include asm/barrier.h in linux/compiler.h, but this requires a type definition for "bool" on some architectures (e.g. x86), which is defined later by linux/types.h. Type "bool" is also used directly in linux/compiler.h, so the whole thing is pretty fragile. This patch splits compiler.h in two: compiler_types.h contains type annotations, definitions and the compiler-specific parts, whereas compiler.h #includes compiler-types.h and additionally defines macros such as {READ,WRITE.ACCESS}_ONCE(). uapi/linux/stddef.h and linux/linkage.h are then moved over to include linux/compiler_types.h, which fixes the build for h8 and blackfin. Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1508840570-22169-2-git-send-email-will.deacon@arm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24Merge tag 'v4.14-rc6' into locking/core, to pick up fixesIngo Molnar17-31/+72
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24ARM: 8715/1: add a private asm/unaligned.hArnd Bergmann2-1/+27
The asm-generic/unaligned.h header provides two different implementations for accessing unaligned variables: the access_ok.h version used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers are in fact aligned, while the le_struct.h version convinces gcc that the alignment of a pointer is '1', to make it issue the correct load/store instructions depending on the architecture flags. On ARMv5 and older, we always use the second version, to let the compiler use byte accesses. On ARMv6 and newer, we currently use the access_ok.h version, so the compiler can use any instruction including stm/ldm and ldrd/strd that will cause an alignment trap. This trap can significantly impact performance when we have to do a lot of fixups and, worse, has led to crashes in the LZ4 decompressor code that does not have a trap handler. This adds an ARM specific version of asm/unaligned.h that uses the le_struct.h/be_struct.h implementation unconditionally. This should lead to essentially the same code on ARMv6+ as before, with the exception of using regular load/store instructions instead of the trapping instructions multi-register variants. The crash in the LZ4 decompressor code was probably introduced by the patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update LZ4 compressor module"), so linux-4.11 and higher would be affected most. However, we probably want to have this backported to all older stable kernels as well, to help with the performance issues. There are two follow-ups that I think we should also work on, but not backport to stable kernels, first to change the asm-generic version of the header to remove the ARM special case, and second to review all other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they might be affected by the same problem on ARM. Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-24ARM: dts: imx53-tx53: fix interrupt flagsLothar Waßmann2-3/+3
Some interrupts properties are given '0' as the flags argument or no flags argument at all. Change them to use the appropriate interrupt flags. Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2017-10-24ARM: dts: imx28-tx28: fix interrupt flagsLothar Waßmann1-2/+2
Some interrupts properties are given '0' as the flags argument. Change them to use the appropriate interrupt flags. Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2017-10-23ARM: dts: uniphier: add resets propertiesMasahiro Yamada5-0/+52
Add resets properties to all nodes that have reset lines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-23ARM: dts: uniphier: add GPIO hog definitionMasahiro Yamada4-0/+32
Interrupt lines from on-board devices are connected to the GPIO controller. Add GPIO hogging so that the corresponding GPIO line is automatically requested. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-23ARM: dts: uniphier: route on-board device IRQ to GPIO controllerMasahiro Yamada5-4/+5
Interrupt lines from on-board devices are connected to the GPIO controller. Handle this correctly. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-23ARM: dts: uniphier: add GPIO controller nodesMasahiro Yamada5-0/+77
The GPIO controller also acts as an interrupt controller and the interrupt lines are connected to the AIDET block. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-23ARM: 8713/1: NOMMU: Support MPU in XIP configurationVladimir Murzin5-7/+90
Currently, there is assumption in early MPU setup code that kernel image is located in RAM, which is obviously not true for XIP. To run code from ROM we need to make sure that it is covered by MPU. However, due to we allocate regions (semi-)dynamically we can run into issue of trimming region we are running from in case ROM spawns several MPU regions. To help deal with that we enforce minimum alignments for start end end of XIP address space as 1MB and 128Kb correspondingly. Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23ARM: 8712/1: NOMMU: Use more MPU regions to cover memoryVladimir Murzin2-46/+149
PMSAv7 defines curious alignment requirements to the regions: - size must be power of 2, and - region start must be aligned to the region size Because of that we currently adjust lowmem bounds plus we assign only one MPU region to cover memory all these lead to significant amount of memory could be wasted. As an example, consider 64Mb of memory at 0x70000000 - it fits alignment requirements nicely; now, imagine that 2Mb of memory is reserved for coherent DMA allocation, so now Linux is expected to see 62Mb of memory... and here annoying thing happens - memory gets truncated to 32Mb (we've lost 30Mb!), i.e. MPU layout looks like: 0: base 0x70000000, size 0x2000000 This patch tries to allocate as much as possible MPU slots to minimise amount of truncated memory. Moreover, with this patch MPU subregions starting to get used. MPU subregions allow us reduce the number of MPU slots used. For example given above, MPU layout looks like: 0: base 0x70000000, size 0x2000000 1: base 0x72000000, size 0x1000000 2: base 0x73000000, size 0x1000000, disable subreg 7 (0x73e00000 - 0x73ffffff) Where without subregions we'd get: 0: base 0x70000000, size 0x2000000 1: base 0x72000000, size 0x1000000 2: base 0x73000000, size 0x800000 3: base 0x73800000, size 0x400000 4: base 0x73c00000, size 0x200000 To achieve better layout we fist try to cover specified memory as is (maybe with help of subregions) and if we failed, we truncate memory to fit alignment requirements (so it occupies one MPU slot) and perform one more attempt with the reminder, and so on till we either cover all memory or run out of MPU slots. Tested-by: Szemző András <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23ARM: 8711/1: V7M: Add support for MPU to M-classVladimir Murzin5-20/+113
This patch makes it possible to use MPU with v7M cores. Tested-by: Szemző András <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23ARM: 8710/1: Kconfig: Kill CONFIG_VECTORS_BASEVladimir Murzin1-9/+0
The last user of CONFIG_VECTORS_BASE has gone, so kill it. Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reported-by: Afzal Mohammed <afzal.mohd.ma@gmail.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23ARM: 8709/1: NOMMU: Disallow MPU for XIPVladimir Murzin1-1/+1
It seems that MPU never worked with XIP, so we just disallow such combination. Tested-by: Szemző András <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23ARM: 8708/1: NOMMU: Rework MPU to be mostly done in CVladimir Murzin6-40/+127
Currently, there are several issues with how MPU is setup: 1. We won't boot if MPU is missing 2. We won't boot if use XIP 3. Further extension of MPU setup requires asm skills The 1st point can be relaxed, so we can continue with boot CPU even if MPU is missed and fail boot for secondaries only. To address the 2nd point we could create region covering CONFIG_XIP_PHYS_ADDR - _end and that might work for the first stage of MPU enable, but due to MPU's alignment requirement we could cover too much, IOW we need more flexibility in how we're partitioning memory regions... and it'd be hardly possible to archive because of the 3rd point. This patch is trying to address 1st and 3rd issues and paves the path for 2nd and further improvements. The most visible change introduced with this patch is that we start using mpu_rgn_info array (as it was supposed?), so change in MPU setup done by boot CPU is recorded there and feed to secondaries. It allows us to keep minimal region setup for boot CPU and do the rest in C. Since we start programming MPU regions in C evaluation of MPU constrains (number of regions supported and minimal region order) can be done once, which in turn open possibility to free-up "probe" region early. Tested-by: Szemző András <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23ARM: 8707/1: NOMMU: Update MPU accessors to use cp15 helpersVladimir Murzin1-22/+26
Currently, inline assembly for accessing to MPU's cp15 lacks volatile keyword which opens possibility to compiler to optimise such accesses as soon as we start using them more intensively. Rather than fixing inline asm, lets move MPU accessors to use cp15 helpers which do the right thing. Tested-by: Szemző András <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23ARM: 8706/1: NOMMU: Move out MPU setup in separate moduleVladimir Murzin4-257/+276
Having MPU handling code in dedicated module makes it easier to enhance/maintain it. Tested-by: Szemző András <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-23Merge 4.14-rc6 into staging-nextGreg Kroah-Hartman17-31/+72
We want the IIO and staging driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-23ARM: dts: display5: Device tree description of LWN's DISPLAY5 boardLukasz Majewski3-0/+648
This commit adds device tree description of Liebherr's Display5 board. Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2017-10-23ARM: dts: imx53-qsb-common: Fix 'led_gpio7_7@0' node with unit name and no ↵Marco Franchi1-1/+1
reg property The following build warning is seen with W=1: Warning (unit_address_vs_reg): Node /soc/aips@50000000/iomuxc@53fa8000/imx53-qsb/led_gpio7_7@0 has a unit name, but no reg property Fix this warning by removing '@0' from such node. Signed-off-by: Marco Franchi <marco.franchi@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2017-10-23ARM: dts: imx53-m53evk: Fix 'led_gpio@0' node with unit name and no reg propertyMarco Franchi1-1/+1
The following build warning is seen with W=1: Warning (unit_address_vs_reg): Node /soc/aips@50000000/iomuxc@53fa8000/imx53-m53evk/led_gpio@0 has a unit name, but no reg property Fix this warning by removing '@0' from such node. Signed-off-by: Marco Franchi <marco.franchi@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2017-10-23ARM: dts: imx53: Fix 'usbphy@x' node with unit name and no reg propertyMarco Franchi1-2/+2
The following build warnings are seen with W=1: Warning (unit_address_vs_reg): Node /soc/aips@50000000/usbphy@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /soc/aips@50000000/usbphy@1 has a unit name, but no reg property Fix these warnings by changing '@' to '-'. Signed-off-by: Marco Franchi <marco.franchi@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2017-10-23ARM: dts: imx51-ts4800: Fix 'port@0' node with unit name and no reg propertyMarco Franchi1-1/+1
The following build warning is seen with W=1: Warning (unit_address_vs_reg): Node /display-di0/port@0 has a unit name, but no reg property Fix this warning by removing '@' from such node. Signed-off-by: Marco Franchi <marco.franchi@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2017-10-23ARM: dts: imx51-apf51dev: Fix 'backlight@bl1' node with unit name and no reg ↵Marco Franchi1-2/+2
property The following build warning is seen with W=1: Warning (unit_address_vs_reg): Node /backlight@bl1 has a unit name, but no reg property Fix this warning by removing '@bl1'from such node and change 'bl1grp' to 'backlightgrp', once there is only one backlight in this dts. Signed-off-by: Marco Franchi <marco.franchi@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 18:46:20 +0300