summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)Author
2019-10-21Merge tag 'mmp-soc-for-v5.5-2' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp into arm/soc ARM: Marvell MMP SoC patches for v5.5 This tag includes initial support for the Marvell MMP3 processor. MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad FZ-A1 tablet and Dell Wyse 3020/Tx0D thin clients. * tag 'mmp-soc-for-v5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp: MAINTAINERS: mmp: add Git repository ARM: mmp: remove MMP3 USB PHY registers from regs-usb.h ARM: mmp: move cputype.h to include/linux/soc/ ARM: mmp: add SMP support ARM: mmp: add support for MMP3 SoC ARM: mmp: define MMP_CHIPID by the means of CIU_REG() ARM: mmp: DT: convert timer driver to use TIMER_OF_DECLARE ARM: mmp: map the PGU as well ARM: mmp: don't select CACHE_TAUROS2 on all ARCH_MMP ARM: l2c: add definition for FWA in PL310 aux register Link: https://lore.kernel.org/r/3a035bed90f9d8acc49b2d11d20089b546062aea.camel@v3.sk Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'mmp-dt-for-v5.5' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp into arm/dt ARM: Marvell MMP Device Tree patches for v5.5 This tag includes binding documentation for various hardware found on Marvell MMP3 SoC along a DTS file for said hardware. * tag 'mmp-dt-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp: ARM: dts: mmp3: Add MMP3 SoC dts file dt-bindings: phy-mmp3-usb: Add bindings dt-bindings: mrvl,intc: Add a MMP3 interrupt controller dt-bindings: arm: mrvl: Document MMP3 compatible string dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema dt-bindings: arm: cpu: Add Marvell MMP3 SMP enable method Link: https://lore.kernel.org/r/d4897c4a92319527c46147244282803cd9f5a1ff.camel@v3.sk Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'samsung-defconfig-5.5' of ↵Olof Johansson
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/defconfig Samsung defconfig changes for v5.5 1. Enable Dynamic Memory Controller driver for Exynos5422, 2. Enable Arndale (Exynos5250) audio driver, 3. Sync multi_v7 defconfig with exynos by enabling useful and necessary drivers (NFC, watchdog, S2MPA01 regulator, IOMMU, Maxim extcon drivers, PHY for SATA and devfreq). * tag 'samsung-defconfig-5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: multi_v7_defconfig: Enable Exynos bus and memory frequency scaling (devfreq) ARM: multi_v7_defconfig: Enable options for boards with Exynos SoC ARM: exynos_defconfig: Enable Arndale audio driver ARM: exynos_defconfig: Enable DMC driver Link: https://lore.kernel.org/r/20191021180453.29455-2-krzk@kernel.org Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'samsung-dt-dmc-5.5' of ↵Olof Johansson
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Samsung DTS changes for DMC driver for v5.5 Add bindings and update device tree sources of Exynos5422 platforms with new Dynamic Memory Controller nodes and properties. * tag 'samsung-dt-dmc-5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: dt-bindings: memory-controllers: exynos5422-dmc: Correct example syntax and memory region ARM: dts: exynos: Add interrupts to DMC controller in Exynos5422 ARM: dts: exynos: Extend mapped region for DMC on Exynos5422 dt-bindings: memory-controllers: exynos5422-dmc: Add interrupt mode dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories ARM: dts: exynos: Add DMC device to Exynos5422 and Odroid XU3-family boards ARM: dts: exynos: Add syscon compatible to clock controller on Exynos542x dt-bindings: memory-controllers: Add Exynos5422 DMC device description dt-bindings: ddr: Add bindings for LPDDR3 memories dt-bindings: ddr: Rename lpddr2 directory Link: https://lore.kernel.org/r/20191021180453.29455-6-krzk@kernel.org Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'samsung-dt-5.5' of ↵Olof Johansson
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Samsung DTS ARM changes for v5.5 1. Add ARM architected timers on Exynos5 for KVM-based virtualization, 2. Extend chip identification needed for future Adaptive Supply Voltage, 3. Add audio support to Arndale board, 4. Fix init order of clock providers on s3c64xx, 5. A lot of cleanups and adjustments of DTS with DT schema. * tag 'samsung-dt-5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: dts: s3c64xx: Fix init order of clock providers ARM: dts: exynos: Rename SysRAM node to "sram" ARM: dts: exynos: Rename power domain nodes to "power-domain" in Exynos4 ARM: dts: exynos: Add audio support (WM1811 CODEC boards) to Arndale board ARM: dts: exynos: Use defines for MCT interrupt GIC SPI/PPI specifier ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos54xx ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos5250 ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4412 ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4210 ARM: dts: exynos: Rename Multi Core Timer node to "timer" ARM: dts: exynos: Split phandle in dmas property ARM: dts: exynos: Remove obsolete IRQ lines on Exynos3250 ARM: dts: exynos: Add samsung,asv-bin property to Odroid XU3 Lite ARM: dts: exynos: Add "syscon" compatible string to chipid node on Exynos5 ARM: dts: exynos: Add support ARM architected timers on Exynos5 Link: https://lore.kernel.org/r/20191021180453.29455-4-krzk@kernel.org Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'v5.5-rockchip-dts32-1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt New rk3288 features are Gamma support for the VOPs as well as declaring the cpuid found in the efuses. Veyron display got a cleanup to use the interpolated backlight values instead of declaring huge tables and finally a cleanup fixing some tabs/spaces issues in the dts files. * tag 'v5.5-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: ARM: dts: rockchip: remove some tabs and spaces from dtsi files ARM: dts: rockchip: Add RK3288 VOP gamma LUT address ARM: dts: rockchip: Use interpolated brightness tables for veyron ARM: dts: rockchip: Add cpu id to rk3288 efuse node Link: https://lore.kernel.org/r/1770986.Em1ahGqaF7@phil Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'renesas-arm-dt-for-v5.5-tag1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/dt Renesas ARM DT updates for v5.5 - Whitespace cleanups. * tag 'renesas-arm-dt-for-v5.5-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: ARM: dts: emev2: Add whitespace for GPIO nodes ARM: dts: lager: Replace spaces by TABs ARM: dts: gose: Replace spaces by TABs Link: https://lore.kernel.org/r/20191018101136.26350-2-geert+renesas@glider.be Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'arm-soc/for-5.4/devicetree-fixes-part2' of ↵Olof Johansson
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoC Device Tree fixes for 5.4, please pull the following: - Stefan removes the activity LED node from the CM3 DTS since there is no driver for that LED yet and leds-gpio cannot drive it either * tag 'arm-soc/for-5.4/devicetree-fixes-part2' of https://github.com/Broadcom/stblinux: ARM: dts: bcm2837-rpi-cm3: Avoid leds-gpio probing issue Link: https://lore.kernel.org/r/20191021194302.21024-1-f.fainelli@gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21ARM: OMAP2+: Drop legacy platform data for dra7 rngTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for am3 and am4 rngTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for omap4 hdq1wTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for dra7 hdq1wTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for am4 hdq1wTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for omap5 mcbspTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for omap4 mcbspTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for omap5 wdtTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for dra7 wdtTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for am3 and am4 wdtTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for omap5 mmcTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for am4 mmcTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for am3 mmcTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for omap5 i2cTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for am4 i2cTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for am3 i2cTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for omap5 uartTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for am4 uartTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for am33xx uartTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for omap5 mcspiTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for omap5 mcspiTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for omap5 mailboxTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Suman Anna <s-anna@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for omap4 mailboxTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Suman Anna <s-anna@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for am3 and am4 mailboxTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Keerthy <j-keerthy@ti.com> Cc: Suman Anna <s-anna@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for dra7 mailboxTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Suman Anna <s-anna@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for omap5 gpioTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: dts: Drop custom hwmod property for omap4 gpioTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the custom ti,hwmods dts property. We have already dropped the platform data earlier, but have been still allocating it dynamically, which is no longer needed. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: Drop legacy platform data for am3 and am4 gpioTony Lindgren
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Ankur Tyagi <ankur.tyagi@gallagher.com> Cc: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21Merge tag 'arm-soc/for-5.4/devicetree-fixes' of ↵Olof Johansson
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs Device Tree fixes for 5.4, please pull the following: - Stefan fixes the MMC controller bus-width property for the Raspberry Pi Zero Wireless which was incorrect after a prior refactoring * tag 'arm-soc/for-5.4/devicetree-fixes' of https://github.com/Broadcom/stblinux: ARM: dts: bcm2835-rpi-zero-w: Fix bus-width of sdhci Link: https://lore.kernel.org/r/20191015172356.9650-1-f.fainelli@gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'davinci-fixes-for-v5.4' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/fixes DaVinci fixes for v5.4 ====================== * fix GPIO backlight support on DA850 by enabling the needed config in davinci_all_defconfig. This is a fix because the driver and board support got converted to use BACKLIGHT_GPIO driver, but defconfig update is still missing in v5.4. * fix for McBSP DMA on DM365 * tag 'davinci-fixes-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: davinci_all_defconfig: enable GPIO backlight ARM: davinci: dm365: Fix McBSP dma_slave_map entry Link: https://lore.kernel.org/r/7f3393f9-59be-a2d4-c1e1-ba6e407681d1@ti.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'imx-fixes-5.4' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.4: - Re-enable SNVS power key for imx6q-logicpd board which was accidentally disabled by a SoC level change. - Fix I2C switches on vf610-zii-scu4-aib board by specifying property i2c-mux-idle-disconnect. - A fix on imx-scu API that reads UID from firmware to avoid kernel NULL pointer dump. - A series from Anson to correct i.MX7 GPT and i.MX8 USDHC IPG clock. - A fix on DRM_MSM Kconfig regression on i.MX5 by adding the option explicitly into imx_v6_v7_defconfig. - Fix ARM regulator states issue for zii-ultra board, which is impacting stability of the board. - A correction on CPU core idle state name for LayerScape LX2160A SoC. * tag 'imx-fixes-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: imx_v6_v7_defconfig: Enable CONFIG_DRM_MSM arm64: dts: imx8mn: Use correct clock for usdhc's ipg clk arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk arm64: dts: imx8mq: Use correct clock for usdhc's ipg clk ARM: dts: imx7s: Correct GPT's ipg clock source ARM: dts: vf610-zii-scu4-aib: Specify 'i2c-mux-idle-disconnect' ARM: dts: imx6q-logicpd: Re-Enable SNVS power key arm64: dts: lx2160a: Correct CPU core idle state name arm64: dts: zii-ultra: fix ARM regulator states soc: imx: imx-scu: Getting UID from SCU should have response Link: https://lore.kernel.org/r/20191017141851.GA22506@dragon Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21Merge tag 'omap-for-v5.4/fixes-rc3-signed' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Fixes for omaps for v5.4-rc cycle More fixes for omap variants: - Update more panel options in omap2plus_defconfig that got changed as we moved to use generic LCD panels - Remove unused twl_keypad for logicpd-torpedo-som to avoid boot time warnings. This is only a cosmetic fix, but at least dmesg output is now getting more readable after all the fixes to remove pointless warnings - Fix gpu_cm node name as we still have a non-standard node name dependency for clocks. This should eventually get fixed by use of domain specific compatible property - Fix use of i2c-mux-idle-disconnect for m3874-iceboard - Use level interrupt for omap4 & 5 wlcore to avoid lost edge interrupts * tag 'omap-for-v5.4/fixes-rc3-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: Use level interrupt for omap4 & 5 wlcore ARM: dts: am3874-iceboard: Fix 'i2c-mux-idle-disconnect' usage ARM: dts: omap5: fix gpu_cm clock provider name ARM: dts: logicpd-torpedo-som: Remove twl_keypad ARM: omap2plus_defconfig: Fix selected panels after generic panel changes Link: https://lore.kernel.org/r/pull-1571242890-118432@atomide.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-21arm/arm64: Make use of the SMCCC 1.1 wrapperSteven Price
Rather than directly choosing which function to use based on psci_ops.conduit, use the new arm_smccc_1_1 wrapper instead. In some cases we still need to do some operations based on the conduit, but the code duplication is removed. No functional change. Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-21KVM: arm64: Support stolen time reporting via shared structureSteven Price
Implement the service call for configuring a shared structure between a VCPU and the hypervisor in which the hypervisor can write the time stolen from the VCPU's execution time by other tasks on the host. User space allocates memory which is placed at an IPA also chosen by user space. The hypervisor then updates the shared structure using kvm_put_guest() to ensure single copy atomicity of the 64-bit value reporting the stolen time in nanoseconds. Whenever stolen time is enabled by the guest, the stolen time counter is reset. The stolen time itself is retrieved from the sched_info structure maintained by the Linux scheduler code. We enable SCHEDSTATS when selecting KVM Kconfig to ensure this value is meaningful. Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-21KVM: arm64: Implement PV_TIME_FEATURES callSteven Price
This provides a mechanism for querying which paravirtualized time features are available in this hypervisor. Also add the header file which defines the ABI for the paravirtualized time features we're about to add. Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-21KVM: arm/arm64: Factor out hypercall handling from PSCI codeChristoffer Dall
We currently intertwine the KVM PSCI implementation with the general dispatch of hypercall handling, which makes perfect sense because PSCI is the only category of hypercalls we support. However, as we are about to support additional hypercalls, factor out this functionality into a separate hypercall handler file. Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> [steven.price@arm.com: rebased] Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-21KVM: arm/arm64: Allow user injection of external data abortsChristoffer Dall
In some scenarios, such as buggy guest or incorrect configuration of the VMM and firmware description data, userspace will detect a memory access to a portion of the IPA, which is not mapped to any MMIO region. For this purpose, the appropriate action is to inject an external abort to the guest. The kernel already has functionality to inject an external abort, but we need to wire up a signal from user space that lets user space tell the kernel to do this. It turns out, we already have the set event functionality which we can perfectly reuse for this. Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-21KVM: arm/arm64: Allow reporting non-ISV data aborts to userspaceChristoffer Dall
For a long time, if a guest accessed memory outside of a memslot using any of the load/store instructions in the architecture which doesn't supply decoding information in the ESR_EL2 (the ISV bit is not set), the kernel would print the following message and terminate the VM as a result of returning -ENOSYS to userspace: load/store instruction decoding not implemented The reason behind this message is that KVM assumes that all accesses outside a memslot is an MMIO access which should be handled by userspace, and we originally expected to eventually implement some sort of decoding of load/store instructions where the ISV bit was not set. However, it turns out that many of the instructions which don't provide decoding information on abort are not safe to use for MMIO accesses, and the remaining few that would potentially make sense to use on MMIO accesses, such as those with register writeback, are not used in practice. It also turns out that fetching an instruction from guest memory can be a pretty horrible affair, involving stopping all CPUs on SMP systems, handling multiple corner cases of address translation in software, and more. It doesn't appear likely that we'll ever implement this in the kernel. What is much more common is that a user has misconfigured his/her guest and is actually not accessing an MMIO region, but just hitting some random hole in the IPA space. In this scenario, the error message above is almost misleading and has led to a great deal of confusion over the years. It is, nevertheless, ABI to userspace, and we therefore need to introduce a new capability that userspace explicitly enables to change behavior. This patch introduces KVM_CAP_ARM_NISV_TO_USER (NISV meaning Non-ISV) which does exactly that, and introduces a new exit reason to report the event to userspace. User space can then emulate an exception to the guest, restart the guest, suspend the guest, or take any other appropriate action as per the policy of the running system. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> Reviewed-by: Alexander Graf <graf@amazon.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-21ARM: 8926/1: v7m: remove register save to stack before svcafzal mohammed
r0-r3 & r12 registers are saved & restored, before & after svc respectively. Intention was to preserve those registers across thread to handler mode switch. On v7-M, hardware saves the register context upon exception in AAPCS complaint way. Restoring r0-r3 & r12 is done from stack location where hardware saves it, not from the location on stack where these registers were saved. To clarify, on stm32f429 discovery board: 1. before svc, sp - 0x90009ff8 2. r0-r3,r12 saved to 0x90009ff8 - 0x9000a00b 3. upon svc, h/w decrements sp by 32 & pushes registers onto stack 4. after svc, sp - 0x90009fd8 5. r0-r3,r12 restored from 0x90009fd8 - 0x90009feb Above means r0-r3,r12 is not restored from the location where they are saved, but since hardware pushes the registers onto stack, the registers are restored correctly. Note that during register saving to stack (step 2), it goes past 0x9000a000. And it seems, based on objdump, there are global symbols residing there, and it perhaps can cause issues on a non-XIP Kernel (on XIP, data section is setup later). Based on the analysis above, manually saving registers onto stack is at best no-op and at worst can cause data section corruption. Hence remove storing of registers onto stack before svc. Fixes: b70cd406d7fe ("ARM: 8671/1: V7M: Preserve registers across switch from Thread to Handler mode") Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com> Acked-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-10-21ARM: OMAP2+: make omap44xx_sha0_hwmod and omap44xx_l3_main_2__des staticBen Dooks
The omap44xx_sha0_hwmod and omap44xx_l3_main_2__des objects are not exported so make them static to avoid the following warnings: arch/arm/mach-omap2/omap_hwmod_44xx_data.c:793:19: warning: symbol 'omap44xx_sha0_hwmod' was not declared. Should it be static? arch/arm/mach-omap2/omap_hwmod_44xx_data.c:977:26: warning: symbol 'omap44xx_l3_main_2__des' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: prm44xx: make prm_{save,restore}_context staticBen Dooks
The prm_{save,restore}_context functions are not exported so make them static to avoid the following warnings: arch/arm/mach-omap2/prm44xx.c:748:6: warning: symbol 'prm_save_context' was not declared. Should it be static? arch/arm/mach-omap2/prm44xx.c:759:6: warning: symbol 'prm_restore_context' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: make dra7xx_sha0_hwmod staticBen Dooks
The dra7xx_sha0_hwmod object is not exported outside of omap_hwmod_7xx_data. so make it static to avoid the following warning: arch/arm/mach-omap2/omap_hwmod_7xx_data.c:686:19: warning: symbol 'dra7xx_sha0_hwmod' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>