summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)Author
2015-12-09xen/events: Always allocate legacy interrupts on PV guestsBoris Ostrovsky
commit b4ff8389ed14b849354b59ce9b360bdefcdbf99c upstream. After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before allocating descs for legacy IRQs") early_irq_init() will no longer preallocate descriptors for legacy interrupts if PIC does not exist, which is the case for Xen PV guests. Therefore we may need to allocate those descriptors ourselves. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmodeArnd Bergmann
commit 54c09889bff6d99c8733eed4a26c9391b177c88b upstream. The z2 machine calls pxa27x_set_pwrmode() in order to power off the machine, but this function gets discarded early at boot because it is marked __init, as pointed out by kbuild: WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode() The function z2_power_off() references the function __init pxa27x_set_pwrmode(). This is often because z2_power_off lacks a __init annotation or the annotation of pxa27x_set_pwrmode is wrong. This removes the __init section modifier to fix rebooting and the build error. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: ba4a90a6d86a ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available") Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: dts: sun6i: hummingbird: Fix VDD-CPU and VDD-GPU regulator namesChen-Yu Tsai
commit 976d84fce6aa1e5bf92b8d06d69014ac45fd5fad upstream. The VDD-CPU and VDD-GPU regulators were incorrectly swapped. Fixes: bab03561224ba ("ARM: dts: sun6i: hummingbird: Add AXP221 regulator nodes") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: dts: Fix WLAN regression on omap5-uevmTony Lindgren
commit 0efc898a9bea7a2e8e583c6efab0e19dc7093078 upstream. Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added device tree bindings for the TI WLAN SDIO on many omap variants. I recall wondering how come omap5-uevm did not have the WLAN added and this issue has been bugging me for a while now, and I finally tracked it down to a bad pinmux regression, and a missing deferred probe handling for the 32k clock from palmas that's requested by twl6040. Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data") added pin muxing for mcspi4 that conflicts with the onboard WLAN. While some omap5-uevm don't have WLAN populated, the pins are not reused for other devices. And as the SDIO bus should be probed, let's try to enable WLAN by default. Let's fix the regression and add the WLAN configuration as done for the other boards in 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings"). And let's use the new MMC pwrseq for the 32k clock as suggested by Javier Martinez Canillas <javier@dowhile0.org>. Note that without a related deferred probe fix for twl6040, the 32k clock is not initialized if palmas-clk is a module and twl6040 is built-in. Let's also use the generic "non-removable" instead of the legacy "ti,non-removable" property while at it. And finally, note that omap5 seems to require WAKEUP_EN for the WLAN GPIO interrupt. Fixes: 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data") Cc: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: at91: pm: at91_pm_suspend_in_sram() must be 8-byte alignedPatrick Doyle
commit 5fcf8d1a0e84792b2bc44922c5d833dab96a9c1e upstream. fncpy() requires that the source and the destination are both 8-byte aligned. Signed-off-by: Patrick Doyle <pdoyle@irobot.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: d94e688cae56 ("ARM: at91/pm: move the copying the sram function to the sram initialization phase") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: at91/dt: corrections to i2c1 declaration to sama5d4Holger Busse
commit d1a9c24ad16ab2b26f1574bc3f2c165a7beff5df upstream. Correcting the dma declaration for i2c1 dma. Signed-off-by: Holger Busse <h.busse@kathrein-sachsen.de> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 4cc7cdf35c5f ("ARM: at91/dt: add i2c1 declaration to sama5d4") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: tegra: paz00: use con_id's to refer GPIO's in gpiod_lookup tableDmitry Osipenko
commit e77b675f8786f38d40fc1562e1275875daf67fef upstream. Commit 72daceb9a10a ("net: rfkill: gpio: Add default GPIO driver mappings for ACPI") removed possibility to request GPIO by table index for non-ACPI platforms without changing its users. As result "shutdown" GPIO request will fail if request for "reset" GPIO succeeded or "reset" will be requested instead of "shutdown" if "reset" wasn't defined. Fix it by making gpiod_lookup_table use con_id's instead of indexes. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Fixes: 72daceb (net: rfkill: gpio: Add default GPIO driver mappings for ACPI) Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Marc Dietrich <marvin24@gmx.de> Tested-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: dts: imx27.dtsi: change the clock information for usbPeter Chen
commit facf47ee6b4d07d43c3bfd6f0762f1b28f64703a upstream. For imx27, it needs three clocks to let the controller work, the old code is wrong, and usbmisc has not included clock handling code any more. Without this patch, it will cause below data abort when accessing usbmisc registers. usbcore: registered new interface driver usb-storage Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600 pgd = c0004000 [f4424600] *pgd=10000452(bad) Internal error: : 8 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-next-20150701-dirty #3089 Hardware name: Freescale i.MX27 (Device Tree Support) task: c7832b60 ti: c783e000 task.ti: c783e000 PC is at usbmisc_imx27_init+0x4c/0xbc LR is at usbmisc_imx27_init+0x40/0xbc pc : [<c03cb5c0>] lr : [<c03cb5b4>] psr: 60000093 sp : c783fe08 ip : 00000000 fp : 00000000 r10: c0576434 r9 : 0000009c r8 : c7a773a0 r7 : 01000000 r6 : 60000013 r5 : c7a776f0 r4 : c7a773f0 r3 : f4424600 r2 : 00000000 r1 : 00000001 r0 : 00000001 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: a0004000 DAC: 00000017 Process swapper (pid: 1, stack limit = 0xc783e190) Stack: (0xc783fe08 to 0xc7840000) Signed-off-by: Peter Chen <peter.chen@freescale.com> Reported-by: Fabio Estevam <fabio.estevam@freescale.com> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: common: edma: Fix channel parameter for irq callbacksPeter Ujfalusi
commit 696d8b70c09dd421c4d037fab04341e5b30585cf upstream. In case when the interrupt happened for the second eDMA the channel number was incorrectly passed to the client driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: 8427/1: dma-mapping: add support for offset parameter in dma_mmap()Marek Szyprowski
commit 7e31210349e9e03a9a4dff31ab5f2bc83e8e84f5 upstream. IOMMU-based dma_mmap() implementation lacked proper support for offset parameter used in mmap call (it always assumed that mapping starts from offset zero). This patch adds support for offset parameter to IOMMU-based implementation. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-09ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()Marek Szyprowski
commit 371f0f085f629fc0f66695f572373ca4445a67ad upstream. dma_mmap() function in IOMMU-based dma-mapping implementation lacked a check for valid range of mmap parameters (offset and buffer size), what might have caused access beyond the allocated buffer. This patch fixes this issue. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: 8449/1: fix bug in vdsomunge swab32 macroH. Nikolaus Schaller
commit 38850d786a799c3ff2de0dc1980902c3263698dc upstream. Commit 8a603f91cc48 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h") unfortunately introduced a bug created but not found during discussion and patch simplification. Reported-by: Efraim Yawitz <efraim.yawitz@gmail.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Fixes: 8a603f91cc48 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h") Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.hH. Nikolaus Schaller
commit 8a603f91cc4848ab1a0458bc065aa9f64322e123 upstream. If the host toolchain is not glibc based then the arm kernel build fails with HOSTCC arch/arm/vdso/vdsomunge arch/arm/vdso/vdsomunge.c:48:22: fatal error: byteswap.h: No such file or directory Observed: with omap2plus_defconfig and compile on Mac OS X with arm ELF cross-compiler. Reason: byteswap.h is a glibc only header. Solution: replace by private byte-swapping macros (taken from arch/mips/boot/elf2ecoff.c and kindly improved by Russell King) Tested to compile on Mac OS X 10.9.5 host. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: ux500: modify initial levelshifter statusLinus Walleij
commit 83bf6b13834d9c926905e45cdfda23fe218fc598 upstream. commit 1d8aca9df612f5751892fb2642d72536f2f48fd0 "ARM: ux500: fix MMC/SD card regression" fixed broken the level shifter: it should be default ON but became default OFF. Fixes: 1d8aca9df612 "ARM: ux500: fix MMC/SD card regression" Reported-and-tested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: dts: am57xx-beagle-x15: set VDD_SD to always-onTomi Valkeinen
commit 7e381ec6a36aa44f15fc1a76e6efb9e2cd942e61 upstream. LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled depending on whether an SD card is inserted or not. This patch sets LDO1 regulator to always-on. This patch has a side effect of fixing another issue, HDMI DDC not working when SD card is not inserted: Why this happens is that the tpd12s015 (HDMI level shifter/ESD protection chip) has LS_OE GPIO input, which needs to be enabled for the HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD. So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays off. The proper fix for the HDMI DDC issue would be to maybe have the pinctrl framework manage the pin specific power. Apparently this fixes also a third issue (copy paste from Kishon's patch): ldo1_reg in addition to being connected to the io lines is also connected to the card detect line. On card removal, omap_hsmmc driver does a regulator_disable causing card detect line to be pulled down. This raises a card insertion interrupt and once the MMC core detects there is no card inserted, it does a regulator disable which again raises a card insertion interrupt. This happens in a loop causing infinite MMC interrupts. Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15") Cc: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Louis McCarthy <compeoree@gmail.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: dts: imx7d: Fix UART2 base addressFabio Estevam
commit 178b2d09afc05a46f68b190c6594f3a429bc2385 upstream. The UART2 memory space starts at address 0x30890000 (UART2_URXD). Fix it so that UART2 can be used. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Fixes: 949673450291 ("ARM: dts: add imx7d soc dtsi file") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: dts: Fix audio card detection on Peach boardsAlim Akhtar
commit b8bb9baad27e455c467e8fac47eebadbe765c18f upstream. Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"), sound card detection is broken on peach boards and gives below errors: [ 3.630457] max98090 7-0010: MAX98091 REVID=0x51 [ 3.634233] max98090 7-0010: use default 2.8v micbias [ 3.640985] snow-audio sound: HiFi <-> 3830000.i2s mapping ok [ 3.645307] max98090 7-0010: Invalid master clock frequency [ 3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() failed: -22 [ 3.658914] snow-audio sound: snd_soc_register_card failed (-22) [ 3.664366] snow-audio: probe of sound failed with error -22 This patch adds missing assigned-clocks and assigned-clock-parents for pmu_system_controller node which is used as "mclk" for audio codec. Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards") Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Kukjin Kim <kgene@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: dts: berlin: change BG2Q's USB PHY compatibleThomas Hebb
commit 1f744fd317dc55cadd7132c57c499e3117aea01d upstream. Currently, BG2Q shares a compatible with BG2. This is incorrect, since BG2 and BG2Q use different USB PLL dividers. In reality, BG2Q shares a divider with BG2CD. Change BG2Q's USB PHY compatible string to reflect that. Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: mvebu: correct a385-db-ap compatible stringMarcin Wojtas
commit db347f1a5304d68c68c52f19971924b1e5842f3c upstream. This commit enables standby support on Armada 385 DB-AP board, because the PM initalization routine requires "marvell,armada380" compatible string for all Armada 38x-based platforms. Beside the compatible "marvell,armada38x" was wrong and should be fixed in the stable kernels too. [gregory.clement@free-electrons.com: add information, about the fixes] Fixes: e5ee12817e9ea ("ARM: mvebu: Add Armada 385 Access Point Development Board support") Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: orion: Fix DSA platform device after mvmdio conversionFlorian Fainelli
commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 upstream. DSA expects the host_dev pointer to be the device structure associated with the MDIO bus controller driver. First commit breaking that was c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver"), and then, it got completely under the radar for a while. Reported-by: Frans van de Wiel <fvdw@fvdw.eu> Fixes: c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09ARM: EXYNOS: Fix double of_node_put() when parsing child power domainsKrzysztof Kozlowski
commit 51a6256b00008a3c520f6f31bcd62cd15cb05960 upstream. On each next iteration of for_each_compatible_node() the reference counter for current device node is already decreased by the loop iterator. The manual call to of_node_get() is required only on loop break which is not happening here. The double of_node_get() (with enabled CONFIG_OF_DYNAMIC) lead to decreasing the counter below expected, initial value. Fixes: fe4034a3fad7 ("ARM: EXYNOS: Add missing of_node_put() when parsing power domains") Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Kukjin Kim <kgene@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-09KVM: arm: use GIC support unconditionallyArnd Bergmann
commit 4a5d69b73948d0e03cd38d77dc11edb2e707165f upstream. The vgic code on ARM is built for all configurations that enable KVM, but the parent_data field that it references is only present when CONFIG_IRQ_DOMAIN_HIERARCHY is set: virt/kvm/arm/vgic.c: In function 'kvm_vgic_map_phys_irq': virt/kvm/arm/vgic.c:1781:13: error: 'struct irq_data' has no member named 'parent_data' This flag is implied by the GIC driver, and indeed the VGIC code only makes sense if a GIC is present. This changes the CONFIG_KVM symbol to always select GIC, which avoids the issue. Fixes: 662d9715840 ("arm/arm64: KVM: Kill CONFIG_KVM_ARM_{VGIC,TIMER}") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-27ARM: ux500: simplify secondary CPU bootLinus Walleij
commit c00def71efd919e8ae835a25f4f4c80a4b2d36d3 upstream. This removes a lot of ancient cruft from the Ux500 SMP boot. Instead of the pen grab/release, just point the ROM to secondary_boot() and start the second CPU there, then send the IPI. Use our own SMP enable method. This enables us to remove the last static mapping and get both CPUs booting properly. Tested this and it just works. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: dts: fix usb pin control for imx-rex dtsFelipe F. Tonello
commit 0af822110871400908d5b6f83a8908c45f881d8f upstream. This fixes a duplicated pin control causing this error: imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already requested by regulators:regulator@2; cannot claim for 2184000.usb imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22 imx6q-pinctrl 20e0000.iomuxc: could not request pin 137 (MX6Q_PAD_GPIO_1) from group usbotggrp on device 20e0000.iomuxc imx_usb 2184000.usb: Error applying setting, reverse things back imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already requested by regulators:regulator@1; cannot claim for 2184200.usb imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22 imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31) from group usbh1grp on device 20e0000.iomuxc imx_usb 2184200.usb: Error applying setting, reverse things back Signed-off-by: Felipe F. Tonello <eu@felipetonello.com> Fixes: e2047e33f2bd ("ARM: dts: add initial Rex Pro board support") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420Joonyoung Shim
commit c7d2ecd9f64c351cb4d551f1f472d0fc09c3cae8 upstream. The sysmmu_fimd1_1 should bind the clock CLK_SMMU_FIMD1M1, not the clock CLK_SMMU_FIMD1M0. CLK_SMMU_FIMD1M0 is a clock for the sysmmu_fimd1_0. This wrong clock binding causes the problem that is blocked in iommu_map function when IOMMU is enabled and exynos-drm driver tries to allocate buffer via DMA mapping API on Odroid-XU3 board. Fixes: b70045167815 ("ARM: dts: add sysmmu nodes for exynos5420") Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC ↵Timo Sigurdsson
specifications commit eaeef1ad9b6ea6df1d1220c254d9563da60cb9d1 upstream. sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise the voltage for the lowest operating point to 1.0 volts in order to stay within the SoC specifications. It is an undervolted setting that isn't stable across all SoCs and boards out there. Fixes: d96b7161916f ("ARM: dts: sun7i: Add cpu clock reference and operating points to dtsi") Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de> Acked-by: Iain Paton <ipaton0@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: EXYNOS: reset Little cores when cpu is upChanho Park
commit 833b5794e3303cc97a0d2d4ba97f26cc9d9b4b79 upstream. The cpu booting of exynos5422 has been still broken since we discussed it in last year[1]. This patch is inspired from Odroid XU3 code (Actually, it was from samsung exynos vendor kernel)[2]. This weird reset code was founded exynos5420 octa cores series SoCs and only required for the first boot core is the Little core (Cortex A7). Some of the exynos5420 boards and all of the exynos5422 boards will require this code. There is two ways to check the little core is the first cpu. One is checking GPG2CON[1] GPIO value and the other is checking the cluster number of the first cpu. I selected the latter because it's more easier than the former. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html [2] https://patchwork.kernel.org/patch/6782891/ Cc: Kevin Hilman <khilman@kernel.org> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Chanho Park <parkch98@gmail.com> [k.kozlowski: Adding stable for v4.1+, reformat comment] Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: pxa: ssp: Fix build error by removing originally incorrect DT bindingJarkko Nikula
commit b692cb83b14d2f741f513221f5f78042c674c2a9 upstream. Commit 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types") caused build error here because it removed the type LPSS_SSP and I didn't notice the type was used here too. I believe commit a6e56c28a178 ("ARM: pxa: ssp: add DT bindings") added it accidentally by copying all enum pxa_ssp_type types from include/linux/pxa2xx_ssp.h even LPSS_SSP was for Intel LPSS SPI devices. Fix the build error by removing this incorrect binding. Fixes: 03fbf488cece ("spi: pxa2xx: Differentiate Intel LPSS types") Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reported-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work againCarl Frederik Werner
commit 3a2fa775bd1d0579113666c1a2e37654a34018a0 upstream. Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio. According to the OMAP35x Technical Reference Manual CONTROL_PADCONF_I2C3_SDA[15:0] 0x480021C4 mode0: i2c3_sda CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170 the pinmux address of gpio 170 must be 0x480021C6. The former wrong address broke i2c3 (used by hdmi ddc), resulting in kernel message: omap_i2c 48060000.i2c: controller timed out Fixes: 8cecf52befd7 ("ARM: omap3-beagle.dts: add display information") Signed-off-by: Carl Frederik Werner <frederik@cfbw.eu> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsetsGrazvydas Ignotas
commit 1dbdad75074d16c3e3005180f81a01cdc04a7872 upstream. The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the pins up, communication with tca6424a doesn't work (controller timeouts) and it is not possible to enable HDMI. Fixes: 9be495c42609 ("ARM: dts: omap5-evm: Add I2c pinctrl data") Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpointsDoug Anderson
commit 7ae85dc7687c7e7119053d83d02c560ea217b772 upstream. In (23a4e40 arm: kgdb: Handle read-only text / modules) we moved to using patch_text() to set breakpoints so that we could handle the case when we had CONFIG_DEBUG_RODATA. That patch used patch_text(). Unfortunately, patch_text() assumes that we're not in atomic context when it runs since it needs to grab a mutex and also wait for other CPUs to stop (which it does with a completion). This would result in a stack crawl if you had CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb. The crawl looked something like: BUG: scheduling while atomic: swapper/0/0/0x00010007 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073 Hardware name: Rockchip (Device Tree) (unwind_backtrace) from [<c00133d4>] (show_stack+0x20/0x24) (show_stack) from [<c05400e8>] (dump_stack+0x84/0xb8) (dump_stack) from [<c004913c>] (__schedule_bug+0x54/0x6c) (__schedule_bug) from [<c054065c>] (__schedule+0x80/0x668) (__schedule) from [<c0540cfc>] (schedule+0xb8/0xd4) (schedule) from [<c0543a3c>] (schedule_timeout+0x2c/0x234) (schedule_timeout) from [<c05417c0>] (wait_for_common+0xf4/0x188) (wait_for_common) from [<c0541874>] (wait_for_completion+0x20/0x24) (wait_for_completion) from [<c00a0104>] (__stop_cpus+0x58/0x70) (__stop_cpus) from [<c00a0580>] (stop_cpus+0x3c/0x54) (stop_cpus) from [<c00a06c4>] (__stop_machine+0xcc/0xe8) (__stop_machine) from [<c00a0714>] (stop_machine+0x34/0x44) (stop_machine) from [<c00173e8>] (patch_text+0x28/0x34) (patch_text) from [<c001733c>] (kgdb_arch_set_breakpoint+0x40/0x4c) (kgdb_arch_set_breakpoint) from [<c00a0d68>] (kgdb_validate_break_address+0x2c/0x60) (kgdb_validate_break_address) from [<c00a0e90>] (dbg_set_sw_break+0x1c/0xdc) (dbg_set_sw_break) from [<c00a2e88>] (gdb_serial_stub+0x9c4/0xba4) (gdb_serial_stub) from [<c00a11cc>] (kgdb_cpu_enter+0x1f8/0x60c) (kgdb_cpu_enter) from [<c00a18cc>] (kgdb_handle_exception+0x19c/0x1d0) (kgdb_handle_exception) from [<c0016f7c>] (kgdb_compiled_brk_fn+0x30/0x3c) (kgdb_compiled_brk_fn) from [<c00091a4>] (do_undefinstr+0x1a4/0x20c) (do_undefinstr) from [<c001400c>] (__und_svc_finish+0x0/0x34) It turns out that when we're in kgdb all the CPUs are stopped anyway so there's no reason we should be calling patch_text(). We can instead directly call __patch_text() which assumes that CPUs have already been stopped. Fixes: 23a4e4050ba9 ("arm: kgdb: Handle read-only text / modules") Reported-by: Aapo Vienamo <avienamo@nvidia.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: 8429/1: disable GCC SRA optimizationArd Biesheuvel
commit a077224fd35b2f7fbc93f14cf67074fc792fbac2 upstream. While working on the 32-bit ARM port of UEFI, I noticed a strange corruption in the kernel log. The following snprintf() statement (in drivers/firmware/efi/efi.c:efi_md_typeattr_format()) snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]", was producing the following output in the log: | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | | | | |UC] |RUN| | | | | | | |UC] As it turns out, this is caused by incorrect code being emitted for the string() function in lib/vsprintf.c. The following code if (!(spec.flags & LEFT)) { while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } } for (i = 0; i < len; ++i) { if (buf < end) *buf = *s; ++buf; ++s; } while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } when called with len == 0, triggers an issue in the GCC SRA optimization pass (Scalar Replacement of Aggregates), which handles promotion of signed struct members incorrectly. This is a known but as yet unresolved issue. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular case, it is causing the second while loop to be executed erroneously a single time, causing the additional space characters to be printed. So disable the optimization by passing -fno-ipa-sra. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: fix Thumb2 signal handling when ARMv6 is enabledRussell King
commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab upstream. When a kernel is built covering ARMv6 to ARMv7, we omit to clear the IT state when entering a signal handler. This can cause the first few instructions to be conditionally executed depending on the parent context. In any case, the original test for >= ARMv7 is broken - ARMv6 can have Thumb-2 support as well, and an ARMv6T2 specific build would omit this code too. Relax the test back to ARMv6 or greater. This results in us always clearing the IT state bits in the PSR, even on CPUs where these bits are reserved. However, they're reserved for the IT state, so this should cause no harm. Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler") Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> Tested-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22ARM: 8401/1: perf: Set affinity for PPI based PMUsStephen Boyd
commit 8ded1e1a92daa96307e4b84b707fee5993bc6047 upstream. For PPI based PMUs, we bail out early in of_pmu_irq_cfg() without setting the PMU's supported_cpus bitmap. This causes the smp_call_function_any() in armv7_probe_num_events() to fail. Set the bitmap to be all CPUs so that we properly probe PMUs that use PPIs. Fixes: cc88116da0d1 ("arm: perf: treat PMUs as CPU affine") Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22arm: KVM: Disable virtual timer even if the guest is not using itMarc Zyngier
commit 688bc577ac42ae3d07c889a1f0a72f0b23763d58 upstream. When running a guest with the architected timer disabled (with QEMU and the kernel_irqchip=off option, for example), it is important to make sure the timer gets turned off. Otherwise, the guest may try to enable it anyway, leading to a screaming HW interrupt. The fix is to unconditionally turn off the virtual timer on guest exit. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-22arm: KVM: Fix incorrect device to IPA mappingMarek Majtyka
commit ca09f02f122b2ecb0f5ddfc5fd47b29ed657d4fd upstream. A critical bug has been found in device memory stage1 translation for VMs with more then 4GB of address space. Once vm_pgoff size is smaller then pa (which is true for LPAE case, u32 and u64 respectively) some more significant bits of pa may be lost as a shift operation is performed on u32 and later cast onto u64. Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12 expected pa(u64): 0x0000002010030000 produced pa(u64): 0x0000000010030000 The fix is to change the order of operations (casting first onto phys_addr_t and then shifting). Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> [maz: fixed changelog and patch formatting] Signed-off-by: Marek Majtyka <marek.majtyka@tieto.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-29lib/decompressors: use real out buf size for gunzip with kernelYinghai Lu
commit 2d3862d26e67a59340ba1cf1748196c76c5787de upstream. When loading x86 64bit kernel above 4GiB with patched grub2, got kernel gunzip error. | early console in decompress_kernel | decompress_kernel: | input: [0x807f2143b4-0x807ff61aee] | output: [0x807cc00000-0x807f3ea29b] 0x027ea29c: output_len | boot via startup_64 | KASLR using RDTSC... | new output: [0x46fe000000-0x470138cfff] 0x0338d000: output_run_size | decompress: [0x46fe000000-0x47007ea29b] <=== [0x807f2143b4-0x807ff61aee] | | Decompressing Linux... gz... | | uncompression error | | -- System halted the new buffer is at 0x46fe000000ULL, decompressor_gzip is using 0xffffffb901ffffff as out_len. gunzip in lib/zlib_inflate/inflate.c cap that len to 0x01ffffff and decompress fails later. We could hit this problem with crashkernel booting that uses kexec loading kernel above 4GiB. We have decompress_* support: 1. inbuf[]/outbuf[] for kernel preboot. 2. inbuf[]/flush() for initramfs 3. fill()/flush() for initrd. This bug only affect kernel preboot path that use outbuf[]. Add __decompress and take real out_buf_len for gunzip instead of guessing wrong buf size. Fixes: 1431574a1c4 (lib/decompressors: fix "no limit" output buffer length) Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Jon Medhurst <tixy@linaro.org> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-29arm/arm64: KVM: vgic: Check for !irqchip_in_kernel() when mapping resourcesPavel Fedin
commit c2f58514cfb374d5368c9da945f1765cd48eb0da upstream. Until b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops"), kvm_vgic_map_resources() used to include a check on irqchip_in_kernel(), and vgic_v2_map_resources() still has it. But now vm_ops are not initialized until we call kvm_vgic_create(). Therefore kvm_vgic_map_resources() can being called without a VGIC, and we die because vm_ops.map_resources is NULL. Fixing this restores QEMU's kernel-irqchip=off option to a working state, allowing to use GIC emulation in userspace. Fixes: b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops") Signed-off-by: Pavel Fedin <p.fedin@samsung.com> [maz: reworked commit message] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21ARM: rockchip: fix broken buildCaesar Wang
commit cb8cc37f4d38d96552f2c52deb15e511cdacf906 upstream. The following was seen in branch[0] build. arch/arm/mach-rockchip/platsmp.c:154:23: error: 'rockchip_secondary_startup' undeclared (first use in this function) branch[0]: git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git v4.3-armsoc/soc The broken build is caused by the commit fe4407c0dc58 ("ARM: rockchip: fix the CPU soft reset"). Signed-off-by: Caesar Wang <wxt@rock-chips.com> The breakage was a result of it being wrongly merged in my branch with the cache invalidation rework from Russell 02b4e2756e01c ("ARM: v7 setup function should invalidate L1 cache"). Signed-off-by: Heiko Stuebner <heiko@sntech.de> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21ARM: dts: rockchip: fix rk3288 watchdog irqHeiko Stuebner
commit 1a1b698b115467242303daf5fe1d3c9886c2fa17 upstream. The watchdog irq is actually SPI 79, which translates to the original 111 in the manual where the SPI irqs start at 32. The current dw_wdt driver does not use the irq at all, so this issue never surfaced. Nevertheless fix this for a time we want to use the irq. Fixes: 2ab557b72d46 ("ARM: dts: rockchip: add core rk3288 dtsi") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21ARM: rockchip: fix the CPU soft resetCaesar Wang
commit fe4407c0dc58215a7abfb7532740d79ddabe7a7a upstream. We need different orderings when turning a core on and turning a core off. In one case we need to assert reset before turning power off. In ther other case we need to turn power on and the deassert reset. In general, the correct flow is: CPU off: reset_control_assert regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), BIT(pd)) wait_for_power_domain_to_turn_off CPU on: regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), 0) wait_for_power_domain_to_turn_on reset_control_deassert This is needed for stressing CPU up/down, as per: cd /sys/devices/system/cpu/ for i in $(seq 10000); do echo "================= $i ============" for j in $(seq 100); do while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "000"" ]] echo 0 > cpu1/online echo 0 > cpu2/online echo 0 > cpu3/online done while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" != "111" ]]; do echo 1 > cpu1/online echo 1 > cpu2/online echo 1 > cpu3/online done done done The following is reproducable log: [34466.186812] PM: noirq suspend of devices complete after 0.669 msecs [34466.186824] Disabling non-boot CPUs ... [34466.187509] CPU1: shutdown [34466.188672] CPU2: shutdown [34473.736627] Kernel panic - not syncing:Watchdog detected hard LOCKUP on cpu 0 ....... or others similar log: ....... [ 4072.454453] CPU1: shutdown [ 4072.504436] CPU2: shutdown [ 4072.554426] CPU3: shutdown [ 4072.577827] CPU1: Booted secondary processor [ 4072.582611] CPU2: Booted secondary processor <hang> Tested by cpu up/down scripts, the results told us need delay more time before write the sram. The wait time is affected by many aspects (e.g: cpu frequency, bootrom frequency, sram frequency, bus speed, ...). Although the cpus other than cpu0 will write the sram, the speedy is no the same as cpu0, if the cpu0 early wake up, perhaps the other cpus can't startup. As we know, the cpu0 can wake up when the cpu1/2/3 write the 'sram+4/8' and send the sev. Anyway..... At the moment, 1ms delay will be happy work for cpu up/down scripts test. Signed-off-by: Caesar Wang <wxt@rock-chips.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Fixes: 3ee851e212d0 ("ARM: rockchip: add basic smp support for rk3288") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUPVignesh R
commit b9e23f321940d2db2c9def8ff723b8464fb86343 upstream. Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence, program clock domain to SW_WKUP. Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21ARM: dts: fix clock-frequency of display timing0 for exynos3250-rinatoHyungwon Hwang
commit 65e3293381e1cf1abcfe1aa22b914650a40e3af4 upstream. After the commit abc0b1447d49 ("drm: Perform basic sanity checks on probed modes"), proper clock-frequency becomes mandatory for validating the mode of panel. The display does not work if there is no mode validated. Also, this clock-frequency must be set appropriately for getting required frame rate. Fixes: abc0b1447d49 ("drm: Perform basic sanity checks on probed modes") Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Sigend-off-by: Kukjin Kim <kgene@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21ARM: orion5x: fix legacy orion5x IRQ numbersBenjamin Cama
commit 5be9fc23cdb42e1d383ecc8eae8a8ff70a752708 upstream. Since v3.18, attempts to deliver IRQ0 are rejected, breaking orion5x. Fix this by increasing all interrupts by one, as did 5d6bed2a9c8b for dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including dove) as the specific handler is needed to shift back IRQ numbers by one. [gregory.clement@free-electrons.com]: moved the select MULTI_IRQ_HANDLER from PLAT_ORION_LEGACY to ARCH_ORION5X as it broke the build for dove. Fixes: a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq") Signed-off-by: Benjamin Cama <benoar@dolka.fr> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Detlef Vollmann <dv@vollmann.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21ARM: BCM63xx: fix parameter to of_get_cpu_node in bcm63138_smp_boot_secondarySudeep Holla
commit a6b4b25bd15c0a490769422a7eee355e9e91a57b upstream. of_get_cpu_node provides the device node associated with the given logical CPU and cpu_logical_map contains the physical id for each CPU in the logical ordering. Passing cpu_logical_map(cpu) to of_get_cpu_node is incorrect. This patch fixes the issue by passing the logical CPU number to of_get_cpu_node Fixes: ed5cd8163da8 ("ARM: BCM63xx: Add SMP support for BCM63138") Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: bcm-kernel-feedback-list@broadcom.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-22Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "Another couple of small ARM fixes. A patch from Masahiro Yamada who noticed that "make -jN all zImage" would end up generating bad images where N > 1, and a patch from Nicolas to fix the Marvell CPU user access optimisation code when page faults are disabled" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: 8418/1: add boot image dependencies to not generate invalid images ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage
2015-08-20ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanismGrygorii Strashko
The conversion of the wakeupgen irqchip to hierarchical irq domains failed to provide a mechanism to properly set the trigger type of an interrupt. The wakeupgen irq chip itself has no mechanism and therefor no irq_set_type() callback. The code before the conversion relayed the trigger configuration directly to the underlying GIC. Restore the correct behaviour by setting the wakeupgen irq_set_type callback to irq_chip_set_type_parent(). This propagates the set_trigger() call to the underlying GIC irqchip. [ tglx: Massaged changelog ] Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains') Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: <linux@arm.linux.org.uk> Cc: <nsekhar@ti.com> Cc: <jason@lakedaemon.net> Cc: <balbi@ti.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <marc.zyngier@arm.com> Cc: stable@vger.kernel.org # 4.1 Link: http://lkml.kernel.org/r/1439554830-19502-5-git-send-email-grygorii.strashko@ti.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-08-18ARM: 8418/1: add boot image dependencies to not generate invalid imagesMasahiro Yamada
U-Boot is often used to boot the kernel on ARM boards, but uImage is not built by "make all", so we are often inclined to do "make all uImage" to generate DTBs, modules and uImage in a single command, but we should notice a pitfall behind it. In fact, "make all uImage" could generate an invalid uImage if it is run with the parallel option (-j). You can reproduce this problem with the following procedure: [1] First, build "all" and "uImage" separately. You will get a valid uImage $ git clean -f -x -d $ export CROSS_COMPILE=<your-tools-prefix> $ make -s -j8 ARCH=arm multi_v7_defconfig $ make -s -j8 ARCH=arm all $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:21:35 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6138648 Bytes = 5994.77 kB = 5.85 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:20 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 6138712 Aug 8 23:21 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:20 arch/arm/boot/zImage [2] Update some source file(s) $ touch init/main.c [3] Then, re-build "all" and "uImage" simultaneously. You will get an invalid uImage at random. $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CC init/main.o CHK include/generated/compile.h LD init/built-in.o LINK vmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map OBJCOPY arch/arm/boot/Image Building modules, stage 2. Kernel: arch/arm/boot/Image is ready GZIP arch/arm/boot/compressed/piggy.gzip AS arch/arm/boot/compressed/piggy.gzip.o Kernel: arch/arm/boot/Image is ready LD arch/arm/boot/compressed/vmlinux GZIP arch/arm/boot/compressed/piggy.gzip OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:23:14 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 26472 Bytes = 25.85 kB = 0.03 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready MODPOST 192 modules AS arch/arm/boot/compressed/piggy.gzip.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:23 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 26536 Aug 8 23:23 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:23 arch/arm/boot/zImage Please notice the uImage is extremely small when this issue is encountered. Besides, "Kernel: arch/arm/boot/zImage is ready" is displayed twice, before and after the uImage log. The root cause of this is the race condition between zImage and uImage. Actually, uImage depends on zImage, but the dependency between the two is only described in arch/arm/boot/Makefile. Because arch/arm/boot/Makefile is not included from the top-level Makefile, it cannot know the dependency between zImage and uImage. Consequently, when we run make with the parallel option, Kbuild updates vmlinux first, and then two different threads descends into the arch/arm/boot/Makefile almost at the same time, one for updating zImage and the other for uImage. While one thread is re-generating zImage, the other also tries to update zImage before creating uImage on top of that. zImage is overwritten by the slower thread and then uImage is created based on the half-written zImage. This is the reason why "Kernel: arch/arm/boot/zImage is ready" is displayed twice, and a broken uImage is created. The same problem could happen on bootpImage. This commit adds dependencies among Image, zImage, uImage, and bootpImage to arch/arm/Makefile, which is included from the top-level Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-08-18ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usageNicolas Pitre
The mmap semaphore should not be taken when page faults are disabled. Since pagefault_disable() no longer disables preemption, we now need to use faulthandler_disabled() in place of in_atomic(). Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Mark Salter <msalter@redhat.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-08-16Merge tag 'armsoc-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "A smallish batch of fixes, a little more than expected this late, but all fixes are contained to their platforms and seem reasonably low risk: - a somewhat large SMP fix for ux500 that still seemed warranted to include here - OMAP DT fixes for pbias regulator specification that broke due to some DT reshuffling - PCIe IRQ routing bugfix for i.MX - networking fixes for keystone - runtime PM for OMAP GPMC - a couple of error path bug fixes for exynos" * tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: dts: keystone: Fix the mdio bindings by moving it to soc specific file ARM: dts: keystone: fix the clock node for mdio memory: omap-gpmc: Don't try to save uninitialized GPMC context ARM: imx6: correct i.MX6 PCIe interrupt routing ARM: ux500: add an SMP enablement type and move cpu nodes ARM: dts: dra7: Fix broken pbias device creation ARM: dts: OMAP5: Fix broken pbias device creation ARM: dts: OMAP4: Fix broken pbias device creation ARM: dts: omap243x: Fix broken pbias device creation ARM: EXYNOS: fix double of_node_put() on error path ARM: EXYNOS: Fix potentian kfree() of ro memory
generated by cgit v1.2.3 (git 2.46.0) at 2026-04-18 14:33:03 +0000