summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2021-05-14ARM: dts: s5pv210: correct fuel gauge interrupt trigger level on Fascinate ↵Krzysztof Kozlowski1-1/+1
family [ Upstream commit 214e6ec8c9f5a3353d3282b3ff475d3ee86cc21a ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 99bb20321f0e ("ARM: dts: s5pv210: Correct fuelgauge definition on Aries") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-10-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ARM: dts: exynos: correct PMIC interrupt trigger level on SnowKrzysztof Kozlowski1-1/+1
[ Upstream commit 8987efbb17c2522be8615085df9a14da2ab53d34 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: c61248afa819 ("ARM: dts: Add max77686 RTC interrupt to cros5250-common") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-9-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250Krzysztof Kozlowski1-1/+1
[ Upstream commit f6368c60561370e4a92fac22982a3bd656172170 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 47580e8d94c2 ("ARM: dts: Specify MAX77686 pmic interrupt for exynos5250-smdk5250") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-8-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid X/U3 familyKrzysztof Kozlowski1-1/+1
[ Upstream commit 6503c568e97a52f8b7a3109718db438e52e59485 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: eea6653aae7b ("ARM: dts: Enable PMIC interrupts for exynos4412-odroid-common") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-6-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ARM: dts: exynos: correct PMIC interrupt trigger level on Midas familyKrzysztof Kozlowski1-1/+1
[ Upstream commit e52dcd6e70fab51f53292e53336ecb007bb60889 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 15dfdfad2d4a ("ARM: dts: Add basic dts for Exynos4412-based Trats 2 board") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-5-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ARM: dts: exynos: correct MUIC interrupt trigger level on Midas familyKrzysztof Kozlowski1-1/+1
[ Upstream commit 15107e443ab8c6cb35eff10438993e4bc944d9ae ] The Maxim MUIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 7eec1266751b ("ARM: dts: Add Maxim 77693 PMIC to exynos4412-trats2") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-4-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ARM: dts: exynos: correct fuel gauge interrupt trigger level on Midas familyKrzysztof Kozlowski1-1/+1
[ Upstream commit 8a45f33bd36efbb624198cfa9fdf1f66fd1c3d26 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: e8614292cd41 ("ARM: dts: Add Maxim 77693 fuel gauge node for exynos4412-trats2") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-3-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14ARM: dts: exynos: correct fuel gauge interrupt trigger level on GT-I9100Krzysztof Kozlowski1-1/+1
[ Upstream commit 46799802136670e00498f19898f1635fbc85f583 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212534.216197-1-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11crypto: arm/curve25519 - Move '.fpu' after '.arch'Nathan Chancellor1-1/+1
commit 44200f2d9b8b52389c70e6c7bbe51e0dc6eaf938 upstream. Debian's clang carries a patch that makes the default FPU mode 'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON instructions on hardware that does not support them: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch https://bugs.debian.org/841474 https://bugs.debian.org/842142 https://bugs.debian.org/914268 This results in the following build error when clang's integrated assembler is used because the '.arch' directive overrides the '.fpu' directive: arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON vmov.i32 q0, #1 ^ arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON vshr.u64 q1, q0, #7 ^ arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON vshr.u64 q0, q0, #8 ^ arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON vmov.i32 d4, #19 ^ Shuffle the order of the '.arch' and '.fpu' directives so that the code builds regardless of the default FPU mode. This has been tested against both clang with and without Debian's patch and GCC. Cc: stable@vger.kernel.org Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation") Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118 Reported-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Jessica Clarke <jrtc27@jrtc27.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-11ARM: dts: at91: change the key code of the gpio keyLudovic Desroches9-9/+18
[ Upstream commit ca7a049ad1a72ec5f03d1330b53575237fcb727c ] Having a button code and not a key code causes issues with libinput. udev won't set ID_INPUT_KEY. If it is forced, then it causes a bug within libinput. Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20210402130227.21478-1-nicolas.ferre@microchip.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11ARM: dts: ux500: Fix up TVK R3 sensorsLinus Walleij1-23/+50
[ Upstream commit aeceecd40d94ed3c00bfe1cfe59dd1bfac2fc6fe ] The TVK1281618 R3 sensors are different from the R2 board, some incorrectness is fixed and some new sensors added, we also rename the nodes appropriately with accelerometer@ etc. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11ARM: dts: BCM5301X: fix "reg" formatting in /memory nodeRafał Miłecki23-46/+46
[ Upstream commit 43986f38818278bb71a7fef6de689637bb734afe ] This fixes warnings/errors like: arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml: /: memory@0:reg:0: [0, 134217728, 2281701376, 402653184] is too long From schema: /lib/python3.6/site-packages/dtschema/schemas/reg.yaml Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11ARM: tegra: acer-a500: Rename avdd to vdda of touchscreen nodeDmitry Osipenko1-1/+1
[ Upstream commit b27b9689e1f3278919c6183c565d837d0aef6fc1 ] Rename avdd supply to vdda of the touchscreen node. The old supply name was incorrect. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11ARM: 9056/1: decompressor: fix BSS size calculation for LLVM ld.lldArd Biesheuvel1-2/+2
commit c4e792d1acce31c2eb7b9193ab06ab94de05bf42 upstream. The LLVM ld.lld linker uses a different symbol type for __bss_start, resulting in the calculation of KBSS_SZ to be thrown off. Up until now, this has gone unnoticed as it only affects the appended DTB case, but pending changes for ARM in the way the decompressed kernel is cleaned from the caches has uncovered this problem. On a ld.lld build: $ nm vmlinux |grep bss_ c1c22034 D __bss_start c1c86e98 B __bss_stop resulting in $ readelf -s arch/arm/boot/compressed/vmlinux | grep bss_size 433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size which is obviously incorrect, and may cause the cache clean to access unmapped memory, or cause the size calculation to wrap, resulting in no cache clean to be performed at all. Fix this by updating the sed regex to take D type symbols into account. Link: https://lore.kernel.org/linux-arm-kernel/6c65bcef-d4e7-25fa-43cf-2c435bb61bb9@collabora.com/ Link: https://lore.kernel.org/linux-arm-kernel/20210205085220.31232-1-ardb@kernel.org/ Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com> Reported-by: "kernelci.org bot" <bot@kernelci.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-28ARM: dts: Fix swapped mmc order for omap3Tony Lindgren1-0/+3
[ Upstream commit a1ebdb3741993f853865d1bd8f77881916ad53a7 ] Also some omap3 devices like n900 seem to have eMMC and micro-sd swapped around with commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4"). Let's fix the issue with aliases as discussed on the mailing lists. While the mmc aliases should be board specific, let's first fix the issue with minimal changes. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: 9071/1: uprobes: Don't hook on thumb instructionsFredrik Strupe1-2/+2
commit d2f7eca60b29006285d57c7035539e33300e89e5 upstream. Since uprobes is not supported for thumb, check that the thumb bit is not set when matching the uprobes instruction hooks. The Arm UDF instructions used for uprobes triggering (UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the same encoding as a pair of unallocated 32-bit thumb instructions (not UDF) when the condition code is 0b1111 (0xf). This in effect makes it possible to trigger the uprobes functionality from thumb, and at that using two unallocated instructions which are not permanently undefined. Signed-off-by: Fredrik Strupe <fredrik@strupe.net> Cc: stable@vger.kernel.org Fixes: c7edc9e326d5 ("ARM: add uprobes support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-21ARM: OMAP2+: Fix uninitialized sr_instTony Lindgren1-1/+1
[ Upstream commit fc85dc42a38405099f97aa2af709fe9504a82508 ] Fix uninitialized sr_inst. Fixes: fbfa463be8dc ("ARM: OMAP2+: Fix smartreflex init regression after dropping legacy data") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: footbridge: fix PCI interrupt mappingRussell King4-8/+7
[ Upstream commit 30e3b4f256b4e366a61658c294f6a21b8626dda7 ] Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()"), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised. Fixes: 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: 9069/1: NOMMU: Fix conversion for_each_membock() to for_each_mem_range()Vladimir Murzin2-2/+6
[ Upstream commit 45c2f70cba3a7eff34574103b2e2b901a5f771aa ] for_each_mem_range() uses a loop variable, yet looking into code it is not just iteration counter but more complex entity which encodes information about memblock. Thus condition i == 0 looks fragile. Indeed, it broke boot of R-class platforms since it never took i == 0 path (due to i was set to 1). Fix that with restoring original flag check. Fixes: b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Acked-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: OMAP2+: Fix warning for omap_init_time_of()Tony Lindgren1-1/+1
[ Upstream commit a3efe3f6d0eb64363f74af4b0e8ba6d19415cef2 ] Fix warning: no previous prototype for 'omap_init_time_of'. Fixes: e69b4e1a7577 ("ARM: OMAP2+: Add omap_init_time_of()") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: omap1: fix building with clang IASArnd Bergmann1-0/+1
[ Upstream commit 28399a5a6d569c9bdb612345e4933046ca37cde5 ] The clang integrated assembler fails to build one file with a complex asm instruction: arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: error: invalid instruction, any one of the following would fix this: mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit ^ arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: armv6t2 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit ^ arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: thumb2 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit ^ The problem is that 'NR_IRQS_LEGACY' is not defined here. Apparently gas does not care because we first add and then subtract this number, leading to the immediate value to be the same regardless of the specific definition of NR_IRQS_LEGACY. Neither the way that 'gas' just silently builds this file, nor the way that clang IAS makes nonsensical suggestions for how to fix it is great. Fortunately there is an easy fix, which is to #include the header that contains the definition. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210308153430.2530616-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: keystone: fix integer overflow warningArnd Bergmann1-2/+2
[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ] clang warns about an impossible condition when building with 32-bit phys_addr_t: arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] mem_end > KEYSTONE_HIGH_PHYS_END) { ~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~ arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare] if (mem_start < KEYSTONE_HIGH_PHYS_START || ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~ Change the temporary variable to a fixed-size u64 to avoid the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: dts: Fix moving mmc devices with aliases for omap4 & 5Tony Lindgren2-0/+10
[ Upstream commit 77335a040178a0456d4eabc8bf17a7ca3ee4a327 ] Fix moving mmc devices with dts aliases as discussed on the lists. Without this we now have internal eMMC mmc1 show up as mmc2 compared to the earlier order of devices. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21ARM: dts: Drop duplicate sha2md5_fck to fix clk_disable raceTony Lindgren1-8/+0
[ Upstream commit 140a776833957539c84301dbdb4c3013876de118 ] We have a duplicate legacy clock defined for sha2md5_fck that can sometimes race with clk_disable() with the dts configured clock for OMAP4_SHA2MD5_CLKCTRL when unused clocks are disabled during boot causing an "Unhandled fault: imprecise external abort". Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-14ARM: dts: imx6: pbab01: Set vmmc supply for both SD interfacesStefan Riedmueller1-0/+2
[ Upstream commit f57011e72f5fe0421ec7a812beb1b57bdf4bb47f ] Setting the vmmc supplies is crucial since otherwise the supplying regulators get disabled and the SD interfaces are no longer powered which leads to system failures if the system is booted from that SD interface. Fixes: 1e44d3f880d5 ("ARM i.MX6Q: dts: Enable I2C1 with EEPROM and PMIC on Phytec phyFLEX-i.MX6 Ouad module") Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-14ARM: OMAP4: PM: update ROM return address for OSWR and OFFCarlos Leija2-0/+40
[ Upstream commit b3d09a06d89f474cb52664e016849315a97e09d9 ] We need to add a dummy smc call to the cpuidle wakeup path to force the ROM code to save the return address after MMU is enabled again. This is needed to prevent random hangs on secure devices like droid4. Otherwise the system will eventually hang when entering deeper SoC idle states with the core and mpu domains in open-switch retention (OSWR). The hang happens as the ROM code tries to use the earlier physical return address set by omap-headsmp.S with MMU off while waking up CPU1 again. The hangs started happening in theory already with commit caf8c87d7ff2 ("ARM: OMAP2+: Allow core oswr for omap4"), but in practise the issue went unnoticed as various drivers were often blocking any deeper idle states with hardware autoidle features. This patch is based on an earlier TI Linux kernel tree commit 92f0b3028d9e ("OMAP4: PM: update ROM return address for OSWR and OFF") written by Carlos Leija <cileija@ti.com>, Praneeth Bajjuri <praneeth@ti.com>, and Bryan Buckley <bryan.buckley@ti.com>. A later version of the patch was updated to use CPU_PM notifiers by Tero Kristo <t-kristo@ti.com>. Signed-off-by: Carlos Leija <cileija@ti.com> Signed-off-by: Praneeth Bajjuri <praneeth@ti.com> Signed-off-by: Bryan Buckley <bryan.buckley@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Fixes: caf8c87d7ff2 ("ARM: OMAP2+: Allow core oswr for omap4") Reported-by: Carl Philipp Klemm <philipp@uvos.xyz> Reported-by: Merlijn Wajer <merlijn@wizzup.org> Cc: Ivan Jelincic <parazyd@dyne.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <kristo@kernel.org> [tony@atomide.com: updated to apply, updated description] Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-14ARM: OMAP4: Fix PMIC voltage domains for bionicTony Lindgren1-2/+2
[ Upstream commit 30916faa1a6009122e10d0c42338b8db44a36fde ] We are now registering the mpu domain three times instead of registering mpu, core and iva domains like we should. Fixes: d44fa156dcb2 ("ARM: OMAP2+: Configure voltage controller for cpcap") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-14ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pinMarek Behún1-0/+1
commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream. Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode. Without this the pin is by default in LED[2] mode, and the Marvell PHY driver configures LED[2] into "On - Link, Blink - Activity" mode. This fixes the issue where the pca9538 GPIO/interrupt controller (which can't mask interrupts in HW) received too many interrupts and after a time started ignoring the interrupt with error message: IRQ 71: nobody cared There is a work in progress to have the Marvell PHY driver support parsing PHY LED nodes from OF and registering the LEDs as Linux LED class devices. Once this is done the PHY driver can also automatically set the pin into INTn mode if it does not find LED[2] in OF. Until then, though, we fix this via `marvell,reg-init` DT property. Signed-off-by: Marek Behún <kabel@kernel.org> Reported-by: Rui Salvaterra <rsalvaterra@gmail.com> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia") Cc: Uwe Kleine-König <uwe@kleine-koenig.org> Cc: linux-arm-kernel@lists.infradead.org Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory CLEMENT <gregory.clement@bootlin.com> Cc: <stable@vger.kernel.org> Tested-by: Rui Salvaterra <rsalvaterra@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-10ARM: dts: am33xx: add aliases for mmc interfacesMans Rullgard1-0/+3
[ Upstream commit 9bbce32a20d6a72c767a7f85fd6127babd1410ac ] Without DT aliases, the numbering of mmc interfaces is unpredictable. Adding them makes it possible to refer to devices consistently. The popular suggestion to use UUIDs obviously doesn't work with a blank device fresh from the factory. See commit fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") for more discussion. Signed-off-by: Mans Rullgard <mans@mansr.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-30ARM: dts: imx6ull: fix ubi filesystem mount faileddillon min1-0/+1
[ Upstream commit e4817a1b6b77db538bc0141c3b138f2df803ce87 ] For NAND Ecc layout, there is a dependency from old kernel's nand driver setting and current. if old kernel use 4 bit ecc , we should use 4 bit in new kernel either. else will run into following error at filesystem mounting. So, enable fsl,use-minimum-ecc from device tree, to fix this mismatch [ 9.449265] ubi0: scanning is finished [ 9.463968] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read only 22528 bytes, retry [ 9.486940] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read only 22528 bytes, retry [ 9.509906] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read only 22528 bytes, retry [ 9.532845] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read 22528 bytes Fixes: f9ecf10cb88c ("ARM: dts: imx6ull: add MYiR MYS-6ULX SBC") Signed-off-by: dillon min <dillon.minfei@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-30ARM: OMAP2+: Fix smartreflex init regression after dropping legacy dataTony Lindgren1-17/+58
[ Upstream commit fbfa463be8dc7957ee4f81556e9e1ea2a951807d ] When I dropped legacy data for omap4 and dra7 smartreflex in favor of device tree based data, it seems I only testd for the "SmartReflex Class3 initialized" line in dmesg. I missed the fact that there is also omap_devinit_smartreflex() that happens later, and now it produces an error on boot for "No Voltage table for the corresponding vdd. Cannot create debugfs entries for n-values". This happens as we no longer have the smartreflex instance legacy data, and have not yet moved completely to device tree based booting for the driver. Let's fix the issue by changing the smartreflex init to use names. This should all eventually go away in favor of doing the init in the driver based on devicetree compatible value. Note that dra7xx_init_early() is not calling any voltage domain init like omap54xx_voltagedomains_init(), or a dra7 specific voltagedomains init. This means that on dra7 smartreflex is still not fully initialized, and also seems to be missing the related devicetree nodes. Fixes: a6b1e717e942 ("ARM: OMAP2+: Drop legacy platform data for omap4 smartreflex") Fixes: e54740b4afe8 ("ARM: OMAP2+: Drop legacy platform data for dra7 smartreflex") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-30ARM: dts: at91-sama5d27_som1: fix phy address to 7Claudiu Beznea1-2/+2
commit 221c3a09ddf70a0a51715e6c2878d8305e95c558 upstream. Fix the phy address to 7 for Ethernet PHY on SAMA5D27 SOM1. No connection established if phy address 0 is used. The board uses the 24 pins version of the KSZ8081RNA part, KSZ8081RNA pin 16 REFCLK as PHYAD bit [2] has weak internal pull-down. But at reset, connected to PD09 of the MPU it's connected with an internal pull-up forming PHYAD[2:0] = 7. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Fixes: 2f61929eb10a ("ARM: dts: at91: at91-sama5d27_som1: fix PHY ID") Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: <stable@vger.kernel.org> # 4.14+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-30ARM: dts: at91: sam9x60: fix mux-mask to match product's datasheetNicolas Ferre2-8/+9
commit 2c69c8a1736eace8de491d480e6e577a27c2087c upstream. Fix the whole mux-mask table according to datasheet for the sam9x60 product. Too much functions for pins were disabled leading to misunderstandings when enabling more peripherals or taking this table as an example for another board. Take advantage of this fix to move the mux-mask in the SoC file where it belongs and use lower case letters for hex numbers like everywhere in the file. Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board") Cc: <stable@vger.kernel.org> # 5.6+ Cc: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20210310152006.15018-1-nicolas.ferre@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-30ARM: dts: at91: sam9x60: fix mux-mask for PA7 so it can be set to A, B and CFederico Pellegrin1-1/+1
commit 664979bba8169d775959452def968d1a7c03901f upstream. According to the datasheet PA7 can be set to either function A, B or C (see table 6-2 of DS60001579D). The previous value would permit just configuring with function C. Signed-off-by: Federico Pellegrin <fede@evolware.org> Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board") Cc: <stable@vger.kernel.org> # 5.6+ Cc: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17ARM: efistub: replace adrl pseudo-op with adr_l macro invocationArd Biesheuvel1-2/+1
commit 67e3f828bd4bf5e4eb4214dc4eb227d8f1c8a877 upstream. The ARM 'adrl' pseudo instruction is a bit problematic, as it does not exist in Thumb mode, and it is not implemented by Clang either. Since the Thumb variant has a slightly bigger range, it is sometimes necessary to emit the 'adrl' variant in ARM mode where Thumb mode can use adr just fine. However, that still leaves the Clang issue, which does not appear to be supporting this any time soon. So let's switch to the adr_l macro, which works for both ARM and Thumb, and has unlimited range. Reviewed-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-17ARM: assembler: introduce adr_l, ldr_l and str_l macrosArd Biesheuvel1-0/+84
commit 0b1674638a5c69cbace63278625c199100955490 upstream. Like arm64, ARM supports position independent code sequences that produce symbol references with a greater reach than the ordinary adr/ldr instructions. Since on ARM, the adrl pseudo-instruction is only supported in ARM mode (and not at all when using Clang), having a adr_l macro like we do on arm64 is useful, and increases symmetry as well. Currently, we use open coded instruction sequences involving literals and arithmetic operations. Instead, we can use movw/movt pairs on v7 CPUs, circumventing the D-cache entirely. E.g., on v7+ CPUs, we can emit a PC-relative reference as follows: movw <reg>, #:lower16:<sym> - (1f + 8) movt <reg>, #:upper16:<sym> - (1f + 8) 1: add <reg>, <reg>, pc For older CPUs, we can emit the literal into a subsection, allowing it to be emitted out of line while retaining the ability to perform arithmetic on label offsets. E.g., on pre-v7 CPUs, we can emit a PC-relative reference as follows: ldr <reg>, 2f 1: add <reg>, <reg>, pc .subsection 1 2: .long <sym> - (1b + 8) .previous This is allowed by the assembler because, unlike ordinary sections, subsections are combined into a single section in the object file, and so the label references are not true cross-section references that are visible as relocations. (Subsections have been available in binutils since 2004 at least, so they should not cause any issues with older toolchains.) So use the above to implement the macros mov_l, adr_l, ldr_l and str_l, all of which will use movw/movt pairs on v7 and later CPUs, and use PC-relative literals otherwise. Reviewed-by: Nicolas Pitre <nico@fluxnic.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-17ARM: 9029/1: Make iwmmxt.S support Clang's integrated assemblerJian Cai2-44/+92
commit 3c9f5708b7aed6a963e2aefccbd1854802de163e upstream. This patch replaces 6 IWMMXT instructions Clang's integrated assembler does not support in iwmmxt.S using macros, while making sure GNU assembler still emit the same instructions. This should be easier than providing full IWMMXT support in Clang. This is one of the last bits of kernel code that could be compiled but not assembled with clang. Once all of it works with IAS, we no longer need to special-case 32-bit Arm in Kbuild, or turn off CONFIG_IWMMXT when build-testing. "Intel Wireless MMX Technology - Developer Guide - August, 2002" should be referenced for the encoding schemes of these extensions. Link: https://github.com/ClangBuiltLinux/linux/issues/975 Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Jian Cai <jiancai@google.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-07Xen/gnttab: handle p2m update errors on a per-slot basisJan Beulich1-4/+31
commit 8310b77b48c5558c140e7a57a702e7819e62f04e upstream. Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating error leaves the full batch in an ambiguous state as far as the caller is concerned. Instead flags respective slots as bad, unmapping what was mapped there right away. HYPERVISOR_grant_table_op()'s return value and the individual unmap slots' status fields get used only for a one-time - there's not much we can do in case of a failure. Note that there's no GNTST_enomem or alike, so GNTST_general_error gets used. The map ops' handle fields get overwritten just to be on the safe side. This is part of XSA-367. Cc: <stable@vger.kernel.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/96cccf5d-e756-5f53-b91a-ea269bfb9be0@suse.com Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04ARM: dts: aspeed: Add LCLK to lpc-snoopJohn Wang3-0/+3
commit d050d049f8b8077025292c1ecf456c4ee7f96861 upstream. Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201202051634.490-2-wangzhiqiang.bj@bytedance.com Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04ARM: 9065/1: OABI compat: fix build when EPOLL is not enabledRandy Dunlap1-0/+15
[ Upstream commit fd749fe4bcb00ad80d9eece709f804bb4ac6bf1e ] When CONFIG_EPOLL is not set/enabled, sys_oabi-compat.c has build errors. Fix these by surrounding them with ifdef CONFIG_EPOLL/endif and providing stubs for the "EPOLL is not set" case. ../arch/arm/kernel/sys_oabi-compat.c: In function 'sys_oabi_epoll_ctl': ../arch/arm/kernel/sys_oabi-compat.c:257:6: error: implicit declaration of function 'ep_op_has_event' [-Werror=implicit-function-declaration] 257 | if (ep_op_has_event(op) && | ^~~~~~~~~~~~~~~ ../arch/arm/kernel/sys_oabi-compat.c:264:9: error: implicit declaration of function 'do_epoll_ctl'; did you mean 'sys_epoll_ctl'? [-Werror=implicit-function-declaration] 264 | return do_epoll_ctl(epfd, op, fd, &kernel, false); | ^~~~~~~~~~~~ Fixes: c281634c8652 ("ARM: compat: remove KERNEL_DS usage in sys_oabi_epoll_ctl()") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> # from an lkp .config file Cc: linux-arm-kernel@lists.infradead.org Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: patches@armlinux.org.uk Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ coresVladimir Murzin1-2/+2
[ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ] It was observed that decompressor running on hardware implementing ARM v8.2 Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest, would stuck just after: Uncompressing Linux... done, booting the kernel. The reason is that it clears nTLSMD bit when disabling caches: nTLSMD, bit [3] When ARMv8.2-LSMAOC is implemented: No Trap Load Multiple and Store Multiple to Device-nGRE/Device-nGnRE/Device-nGnRnE memory. 0b0 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and generate a stage 1 Alignment fault. 0b1 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped. This bit is permitted to be cached in a TLB. This field resets to 1. Otherwise: Reserved, RES1 So as effect we start getting traps we are not quite ready for. Looking into history it seems that mask used for SCTLR clear came from the similar code for ARMv4, where bit[3] is the enable/disable bit for the write buffer. That not applicable to ARMv7 and onwards, so retire that bit from the masks. Fixes: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format") Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04clocksource/drivers/ixp4xx: Select TIMER_OF when neededArnd Bergmann1-1/+0
[ Upstream commit 7a3b8758bd6e45f7b671723b5c9fa2b69d0787ae ] Compile-testing the ixp4xx timer with CONFIG_OF enabled but CONFIG_TIMER_OF disabled leads to a harmless warning: arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ixp4xx.o' being placed in section `__timer_of_table' Move the select statement from the platform code into the driver so it always gets enabled in configurations that rely on it. Fixes: 40df14cc5cc0 ("clocksource/drivers/ixp4xx: Add OF initialization support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210103135955.3808976-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04ARM: at91: use proper asm syntax in pm_suspendArnd Bergmann1-1/+1
[ Upstream commit d30337da8677cd73cb19444436b311c13e57356f ] Compiling with the clang integrated assembler warns about a recently added instruction: <instantiation>:14:13: error: unknown token in expression ldr tmp1, =#0x00020010UL arch/arm/mach-at91/pm_suspend.S:542:2: note: while in macro instantiation at91_plla_enable Remove the extra '#' character that is not used for the 'ldr' instruction when doing an indirect load of a constant. Fixes: 4fd36e458392 ("ARM: at91: pm: add plla disable/enable support for sam9x60") Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20210204160129.2249394-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04ARM: s3c: fix fiq for clang IASArnd Bergmann1-6/+3
[ Upstream commit 7f9942c61fa60eda7cc8e42f04bd25b7d175876e ] Building with the clang integrated assembler produces a couple of errors for the s3c24xx fiq support: arch/arm/mach-s3c/irq-s3c24xx-fiq.S:52:2: error: instruction 'subne' can not set flags, but 's' suffix specified subnes pc, lr, #4 @@ return, still have work to do arch/arm/mach-s3c/irq-s3c24xx-fiq.S:64:1: error: invalid symbol redefinition s3c24xx_spi_fiq_txrx: There are apparently two problems: one with extraneous or duplicate labels, and one with old-style opcode mnemonics. Stefan Agner has previously fixed other problems like this, but missed this particular file. Fixes: bec0806cfec6 ("spi_s3c24xx: add FIQ pseudo-DMA support") Cc: Stefan Agner <stefan@agner.ch> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210204162416.3030114-1-arnd@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04ARM: dts: armada388-helios4: assign pinctrl to each fanRosen Penev1-3/+10
[ Upstream commit 46ecdfc1830eaa40a11d7f832089c82b0e67ea96 ] Split up the pins for each fan. This is needed in order to control them Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04ARM: dts: armada388-helios4: assign pinctrl to LEDsRosen Penev1-3/+12
[ Upstream commit e011c9025a4691b5c734029577a920bd6c320994 ] Split up the pins to match earlier definitions. Allows LEDs to flash properly. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04ARM: dts: Configure missing thermal interrupt for 4430Tony Lindgren1-0/+2
[ Upstream commit 44f416879a442600b006ef7dec3a6dc98bcf59c6 ] We have gpio_86 wired internally to the bandgap thermal shutdown interrupt on 4430 like we have it on 4460 according to the TRM. This can be found easily by searching for TSHUT. For some reason the thermal shutdown interrupt was never added for 4430, let's add it. I believe this is