summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2025-08-20ARM: tegra: Use I/O memcpy to write to IRAMAaron Kling1-1/+1
[ Upstream commit 398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1 ] Kasan crashes the kernel trying to check boundaries when using the normal memcpy. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250522-mach-tegra-kasan-v1-1-419041b8addb@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20ARM: rockchip: fix kernel hang during smp initializationAlexander Kochetkov1-6/+9
[ Upstream commit 7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814 ] In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4 Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Link: https://lore.kernel.org/r/20250703140453.1273027-1-al.kochet@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: arm/aes-neonbs - work around gcc-15 warningArnd Bergmann1-1/+1
[ Upstream commit d5fa96dc5590915f060fee3209143313e4f5b03b ] I get a very rare -Wstringop-overread warning with gcc-15 for one function in aesbs_ctr_encrypt(): arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:212:1446: error: '__builtin_memcpy' offset [17, 2147483647] is out of the bounds [0, 16] of object 'buf' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds=] 212 | src = dst = memcpy(buf + sizeof(buf) - bytes, arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:218:17: error: 'aesbs_ctr_encrypt' reading 1 byte from a region of size 0 [-Werror=stringop-overread] 218 | aesbs_ctr_encrypt(dst, src, ctx->rk, ctx->rounds, bytes, walk.iv); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 2 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 3 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 6 of type 'u8[0]' {aka 'unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:36:17: note: in a call to function 'aesbs_ctr_encrypt' 36 | asmlinkage void aesbs_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[], This could happen in theory if walk.nbytes is larger than INT_MAX and gets converted to a negative local variable. Keep the type unsigned like the orignal nbytes to be sure there is no integer overflow. Fixes: c8bf850e991a ("crypto: arm/aes-neonbs-ctr - deal with non-multiples of AES block size") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interfaceAnnette Kobou1-1/+0
[ Upstream commit 47ef5256124fb939d8157b13ca048c902435cf23 ] The polarity of the DE signal of the transceiver is active-high for sending. Therefore rs485-rts-active-low is wrong and needs to be removed to make RS485 transmissions work. Signed-off-by: Annette Kobou <annette.kobou@kontron.de> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm: dts: ti: omap: Fixup pinheader typoAlbin Törnqvist1-1/+1
[ Upstream commit a3a4be32b69c99fc20a66e0de83b91f8c882bf4c ] This commit fixes a typo introduced in commit ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names"). gpio0_7 is located on the P9 header on the BBB. This was verified with a BeagleBone Black by toggling the pin and checking with a multimeter that it corresponds to pin 42 on the P9 header. Signed-off-by: Albin Törnqvist <albin.tornqvist@codiax.se> Link: https://lore.kernel.org/r/20250624114839.1465115-2-albin.tornqvist@codiax.se Fixes: ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names") Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15ARM: dts: vfxxx: Correctly use two tuples for timer addressKrzysztof Kozlowski1-1/+1
[ Upstream commit f3440dcf8b994197c968fbafe047ce27eed226e8 ] Address and size-cells are 1 and the ftm timer node takes two address spaces in "reg" property, so this should be in two <> tuples. Change has no functional impact, but original code is confusing/less readable. Fixes: 07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer node.") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-01ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGSNathan Chancellor1-1/+1
[ Upstream commit 87c4e1459e80bf65066f864c762ef4dc932fad4b ] After commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target"), which updated as-instr to use the 'assembler-with-cpp' language option, the Kbuild version of as-instr always fails internally for arch/arm with <command-line>: fatal error: asm/unified.h: No such file or directory compilation terminated. because '-include' flags are now taken into account by the compiler driver and as-instr does not have '$(LINUXINCLUDE)', so unified.h is not found. This went unnoticed at the time of the Kbuild change because the last use of as-instr in Kbuild that arch/arm could reach was removed in 5.7 by commit 541ad0150ca4 ("arm: Remove 32bit KVM host support") but a stable backport of the Kbuild change to before that point exposed this potential issue if one were to be reintroduced. Follow the general pattern of '-include' paths throughout the tree and make unified.h absolute using '$(srctree)' to ensure KBUILD_AFLAGS can be used independently. Closes: https://lore.kernel.org/CACo-S-1qbCX4WAVFA63dWfHtrRHZBTyyr2js8Lx=Az03XHTTHg@mail.gmail.com/ Cc: stable@vger.kernel.org Fixes: d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target") Reported-by: KernelCI bot <bot@kernelci.org> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [ No KBUILD_RUSTFLAGS in 6.12 ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-01ARM: 9450/1: Fix allowing linker DCE with binutils < 2.36Nathan Chancellor1-1/+1
commit 53e7e1fb81cc8ba2da1cb31f8917ef397caafe91 upstream. Commit e7607f7d6d81 ("ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE") accidentally broke the binutils version restriction that was added in commit 0d437918fb64 ("ARM: 9414/1: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATION"), reintroducing the segmentation fault addressed by that workaround. Restore the binutils version dependency by using CONFIG_LD_CAN_USE_KEEP_IN_OVERLAY as an additional condition to ensure that CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION is only enabled with binutils >= 2.36 and ld.lld >= 21.0.0. Closes: https://lore.kernel.org/6739da7d-e555-407a-b5cb-e5681da71056@landley.net/ Closes: https://lore.kernel.org/CAFERDQ0zPoya5ZQfpbeuKVZEo_fKsonLf6tJbp32QnSGAtbi+Q@mail.gmail.com/ Cc: stable@vger.kernel.org Fixes: e7607f7d6d81 ("ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE") Reported-by: Rob Landley <rob@landley.net> Tested-by: Rob Landley <rob@landley.net> Reported-by: Martin Wetterwald <martin@wetterwald.eu> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27ARM: OMAP2+: Fix l4ls clk domain handling in STANDBYSukrut Bellary3-2/+15
[ Upstream commit 47fe74098f3dadba2f9cc1e507d813a4aa93f5f3 ] Don't put the l4ls clk domain to sleep in case of standby. Since CM3 PM FW[1](ti-v4.1.y) doesn't wake-up/enable the l4ls clk domain upon wake-up, CM3 PM FW fails to wake-up the MPU. [1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/ Signed-off-by: Sukrut Bellary <sbellary@baylibre.com> Tested-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20250318230042.3138542-2-sbellary@baylibre.com Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27ARM: omap: pmic-cpcap: do not mess around without CPCAP or OMAP4Andreas Kemnade1-1/+5
commit 7397daf1029d5bfd3415ec8622f5179603d5702d upstream. The late init call just writes to omap4 registers as soon as CONFIG_MFD_CPCAP is enabled without checking whether the cpcap driver is actually there or the SoC is indeed an OMAP4. Rather do these things only with the right device combination. Fixes booting the BT200 with said configuration enabled and non-factory X-Loader and probably also some surprising behavior on other devices. Fixes: c145649bf262 ("ARM: OMAP2+: Configure voltage controller for cpcap to low-speed") CC: stable@vger.kernel.org Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reivewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20250331144439.769697-1-andreas@kemnade.info Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap()Ross Stutterheim1-3/+1
commit 96e0b355883006554a0bee3697da475971d6bba8 upstream. arm/memremap: fix arch_memremap_can_ram_remap() commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") added the definition of arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages can be used from the linear mapping. memblock_is_map_memory() was called with the pfn of the address given to arch_memremap_can_ram_remap(); however, memblock_is_map_memory() expects to be given an address for arm, not a pfn. This results in calls to memremap() returning a newly mapped area when it should return an address in the existing linear mapping. Fix this by removing the address to pfn translation and pass the address directly. Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") Signed-off-by: Ross Stutterheim <ross.stutterheim@garmin.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: stable@vger.kernel.org Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19ARM: aspeed: Don't select SRAMJoel Stanley1-1/+0
[ Upstream commit e4f59f873c3ffe2a0150e11115a83e2dfb671dbf ] The ASPEED devices have SRAM, but don't require it for basic function (or any function; there's no known users of the driver). Fixes: 8c2ed9bcfbeb ("arm: Add Aspeed machine") Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://patch.msgid.link/20250115103942.421429-1-joel@jms.id.au Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ARM: dts: qcom: apq8064: move replicator out of soc nodeDmitry Baryshkov1-33/+34
[ Upstream commit f2420037d90a8354594b3da541e19dcbb60c75e1 ] The CoreSight static replicator device isn't a part of the system MMIO bus, as such it should not be a part of the soc node. Follow the example of other platforms and move it out of the soc bus to the top-level (and reoder ports to follow alphabetic order). Fixes: 7a5c275fd821 ("ARM: dts: qcom: Add apq8064 CoreSight components") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250318-fix-nexus-4-v2-10-bcedd1406790@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ARM: dts: qcom: apq8064 merge hw splinlock into corresponding syscon deviceDmitry Baryshkov1-9/+4
[ Upstream commit 325c6a441ae1f8fcb1db9bb945b8bdbd3142141e ] Follow up the expected way of describing the SFPB hwspinlock and merge hwspinlock node into corresponding syscon node, fixing several dt-schema warnings. Fixes: 24a9baf933dc ("ARM: dts: qcom: apq8064: Add hwmutex and SMEM nodes") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250318-fix-nexus-4-v2-7-bcedd1406790@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ARM: dts: qcom: apq8064: add missing clocks to the timer nodeDmitry Baryshkov1-0/+2
[ Upstream commit 4b0eb149df58b6750cd8113e5ee5b3ac7cc51743 ] In order to fix DT schema warning and describe hardware properly, add missing sleep clock to the timer node. Fixes: f335b8af4fd5 ("ARM: dts: qcom: Add initial APQ8064 SoC and IFC6410 board device trees") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250318-fix-nexus-4-v2-6-bcedd1406790@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ARM: dts: at91: at91sam9263: fix NAND chip selectsWolfram Sang3-3/+3
[ Upstream commit c72ede1c24be689733bcd2233a3a56f2478429c8 ] NAND did not work on my USB-A9263. I discovered that the offending commit converted the PIO bank for chip selects wrongly, so all A9263 boards need to be fixed. Fixes: 1004a2977bdc ("ARM: dts: at91: Switch to the new NAND bindings") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20250402210446.5972-2-wsa+renesas@sang-engineering.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ARM: dts: at91: usb_a9263: fix GPIO for Dataflash chip selectWolfram Sang1-1/+1
[ Upstream commit 67ba341e57ab158423818ed33bfa1c40eb0e5e7e ] Dataflash did not work on my board. After checking schematics and using the proper GPIO, it works now. Also, make it active low to avoid: flash@0 enforce active low on GPIO handle Fixes: 2432d201468d ("ARM: at91: dt: usb-a9263: add dataflash support") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250404112742.67416-2-wsa+renesas@sang-engineering.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29ARM: at91: pm: fix at91_suspend_finish for ZQ calibrationLi Bin1-10/+11
[ Upstream commit bc4722c3598d0e2c2dbf9609a3d3198993093e2b ] For sama7g5 and sama7d65 backup mode, we encountered a "ZQ calibrate error" during recalibrating the impedance in BootStrap. We found that the impedance value saved in at91_suspend_finish() before the DDR entered self-refresh mode did not match the resistor values. The ZDATA field in the DDR3PHY_ZQ0CR0 register uses a modified gray code to select the different impedance setting. But these gray code are incorrect, a workaournd from design team fixed the bug in the calibration logic. The ZDATA contains four independent impedance elements, but the algorithm combined the four elements into one. The elements were fixed using properly shifted offsets. Signed-off-by: Li Bin <bin.li@microchip.com> [nicolas.ferre@microchip.com: fix indentation and combine 2 patches] Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Tested-by: Ryan Wanner <Ryan.Wanner@microchip.com> Tested-by: Durai Manickam KR <durai.manickamkr@microchip.com> Tested-by: Andrei Simion <andrei.simion@microchip.com> Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Link: https://lore.kernel.org/r/28b33f9bcd0ca60ceba032969fe054d38f2b9577.1740671156.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29ARM: tegra: Switch DSI-B clock parent to PLLD on Tegra114Svyatoslav Ryhel1-1/+1
[ Upstream commit 2b3db788f2f614b875b257cdb079adadedc060f3 ] PLLD is usually used as parent clock for internal video devices, like DSI for example, while PLLD2 is used as parent for HDMI. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://lore.kernel.org/r/20250226105615.61087-3-clamor95@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-09ARM: dts: opos6ul: add ksz8081 phy propertiesSébastien Szymanski1-0/+3
[ Upstream commit 6e1a7bc8382b0d4208258f7d2a4474fae788dd90 ] Commit c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK specific PHY fixup") removed a PHY fixup that setted the clock mode and the LED mode. Make the Ethernet interface work again by doing as advised in the commit's log, set clock mode and the LED mode in the device tree. Fixes: c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK specific PHY fixup") Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02crypto: lib/Kconfig - Hide arch options from userHerbert Xu1-6/+10
commit 17ec3e71ba797cdb62164fea9532c81b60f47167 upstream. The ARCH_MAY_HAVE patch missed arm64, mips and s390. But it may also lead to arch options being enabled but ineffective because of modular/built-in conflicts. As the primary user of all these options wireguard is selecting the arch options anyway, make the same selections at the lib/crypto option level and hide the arch options from the user. Instead of selecting them centrally from lib/crypto, simply set the default of each arch option as suggested by Eric Biggers. Change the Crypto API generic algorithms to select the top-level lib/crypto options instead of the generic one as otherwise there is no way to enable the arch options (Eric Biggers). Introduce a set of INTERNAL options to work around dependency cycles on the CONFIG_CRYPTO symbol. Fixes: 1047e21aecdf ("crypto: lib/Kconfig - Fix lib built-in failure when arch is modular") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Arnd Bergmann <arnd@kernel.org> Closes: https://lore.kernel.org/oe-kbuild-all/202502232152.JC84YDLp-lkp@intel.com/ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-02crypto: lib/Kconfig - Fix lib built-in failure when arch is modularHerbert Xu1-3/+3
[ Upstream commit 1047e21aecdf17c8a9ab9fd4bd24c6647453f93d ] The HAVE_ARCH Kconfig options in lib/crypto try to solve the modular versus built-in problem, but it still fails when the the LIB option (e.g., CRYPTO_LIB_CURVE25519) is selected externally. Fix this by introducing a level of indirection with ARCH_MAY_HAVE Kconfig options, these then go on to select the ARCH_HAVE options if the ARCH Kconfig options matches that of the LIB option. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501230223.ikroNDr1-lkp@intel.com/ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCENathan Chancellor2-1/+7
commit e7607f7d6d81af71dcc5171278aadccc94d277cd upstream. ld.lld prior to 21.0.0 does not support using the KEEP keyword within an overlay description, which may be needed to avoid discarding necessary sections within an overlay with '--gc-sections', which can be enabled for the kernel via CONFIG_LD_DEAD_CODE_DATA_ELIMINATION. Disallow CONFIG_LD_DEAD_CODE_DATA_ELIMINATION without support for KEEP within OVERLAY and introduce a macro, OVERLAY_KEEP, that can be used to conditionally add KEEP when it is properly supported to avoid breaking old versions of ld.lld. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/381599f1fe973afad3094e55ec99b1620dba7d8c Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [nathan: Fix conflict in init/Kconfig due to lack of RUSTC symbols] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-10ARM: 9444/1: add KEEP() keyword to ARM_VECTORSChristian Eggers1-3/+3
commit c3d944a367c0d9e4e125c7006e52f352e75776dc upstream. Without this, the vectors are removed if LD_DEAD_CODE_DATA_ELIMINATION is enabled. At startup, the CPU (silently) hangs in the undefined instruction exception as soon as the first timer interrupt arrives. On my setup, the system also boots fine without the 2nd and 3rd KEEP() statements, so I cannot tell whether these are actually required. [nathan: Use OVERLAY_KEEP() to avoid breaking old ld.lld versions] Cc: stable@vger.kernel.org Fixes: ed0f94102251 ("ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION") Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-29ARM: shmobile: smp: Enforce shmobile_smp_* alignmentGeert Uytterhoeven1-0/+1
commit 379c590113ce46f605439d4887996c60ab8820cc upstream. When the addresses of the shmobile_smp_mpidr, shmobile_smp_fn, and shmobile_smp_arg variables are not multiples of 4 bytes, secondary CPU bring-up fails: smp: Bringing up secondary CPUs ... CPU1: failed to come online CPU2: failed to come online CPU3: failed to come online smp: Brought up 1 node, 1 CPU Fix this by adding the missing alignment directive. Fixes: 4e960f52fce16a3b ("ARM: shmobile: Move shmobile_smp_{mpidr, fn, arg}[] from .text to .bss") Closes: https://lore.kernel.org/r/CAMuHMdU=QR-JLgEHKWpsr6SbaZRc-Hz9r91JfpP8c3n2G-OjqA@mail.gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/c499234d559a0d95ad9472883e46077311051cd8.1741612208.git.geert+renesas@glider.be Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-29ARM: dts: imx6qdl-apalis: Fix poweroff on Apalis iMX6Stefan Eichenberger1-5/+5
commit 83964a29379cb08929a39172780a4c2992bc7c93 upstream. The current solution for powering off the Apalis iMX6 is not functioning as intended. To resolve this, it is necessary to power off the vgen2_reg, which will also set the POWER_ENABLE_MOCI signal to a low state. This ensures the carrier board is properly informed to initiate its power-off sequence. The new solution uses the regulator-poweroff driver, which will power off the regulator during a system shutdown. Cc: <stable@vger.kernel.org> Fixes: 4eb56e26f92e ("ARM: dts: imx6q-apalis: Command pmic to standby for poweroff") Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-29ARM: davinci: da850: fix selecting ARCH_DAVINCI_DA8XXDavid Lechner1-0/+1
[ Upstream commit 45d5fe1c53baaed1fb3043f45d1e15ebb4bbe86a ] Chips in the DA850 family need to have ARCH_DAVINCI_DA8XX to be selected in order to enable some peripheral drivers. This was accidentally removed in a previous commit. Fixes: dec85a95167a ("ARM: davinci: clean up platform support") Signed-off-by: David Lechner <dlechner@baylibre.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-29ARM: dts: BCM5301X: Fix switch port labels of ASUS RT-AC3200Chester A. Unal1-4/+4
[ Upstream commit 24d4c56dd68906bf55ff8fc2e2d36760f97dce5f ] After using the device for a while, Tom reports that he initially described the switch port labels incorrectly. Apparently, ASUS's own firmware also describes them incorrectly. Correct them to what is seen on the chassis. Reported-by: Tom Brautaset <tbrautaset@gmail.com> Fixes: b116239094d8 ("ARM: dts: BCM5301X: Add DT for ASUS RT-AC3200") Signed-off-by: Chester A. Unal <chester.a.unal@arinc9.com> Link: https://lore.kernel.org/r/20250304-for-broadcom-fix-rt-ac3200-switch-ports-v1-1-7e249a19a13e@arinc9.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-29ARM: dts: BCM5301X: Fix switch port labels of ASUS RT-AC5300Chester A. Unal1-4/+4
[ Upstream commit 56e12d0c8d395b6e48f128858d4f725c1ded6c95 ] After using the device for a while, Tom reports that he initially described the switch port labels incorrectly. Correct them. Reported-by: Tom Brautaset <tbrautaset@gmail.com> Fixes: 961dedc6b4e4 ("ARM: dts: BCM5301X: Add DT for ASUS RT-AC5300") Signed-off-by: Chester A. Unal <chester.a.unal@arinc9.com> Link: https://lore.kernel.org/r/20250303-for-broadcom-fix-rt-ac5300-switch-ports-v1-1-e058856ef4d3@arinc9.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-29ARM: dts: bcm2711: Don't mark timer regs unconfiguredPhil Elwell1-2/+0
[ Upstream commit c24f272ae751a9f54f8816430e7f2d56031892cc ] During upstream process of Raspberry Pi 4 back in 2019 the ARMv7 stubs didn't configured the ARM architectural timer. This firmware issue has been fixed in 2020, which gave users enough time to update their system. So drop this property to allow the use of the vDSO version of clock_gettime. Link: https://github.com/raspberrypi/tools/pull/113 Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250222094113.48198-1-wahrenst@gmx.net Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-29ARM: OMAP1: select CONFIG_GENERIC_IRQ_CHIPArnd Bergmann1-0/+1
[ Upstream commit 98f3ab18a0a55aa1ff2cd6b74bd0c02c8f76f17e ] When GENERIC_IRQ_CHIP is disabled, OMAP1 kernels fail to link: arm-linux-gnueabi-ld: arch/arm/mach-omap1/irq.o: in function `omap1_init_irq': irq.c:(.init.text+0x1e8): undefined reference to `irq_alloc_generic_chip' arm-linux-gnueabi-ld: irq.c:(.init.text+0x228): undefined reference to `irq_setup_generic_chip' arm-linux-gnueabi-ld: irq.c:(.init.text+0x2a8): undefined reference to `irq_gc_set_wake' arm-linux-gnueabi-ld: irq.c:(.init.text+0x2b0): undefined reference to `irq_gc_mask_set_bit' arm-linux-gnueabi-ld: irq.c:(.init.text+0x2b4): undefined reference to `irq_gc_mask_clr_bit' This has apparently been the case for many years, but I never caught it in randconfig builds until now, as there are dozens of other drivers that also 'select GENERIC_IRQ_CHIP' and statistically there is almost always one of them enabled. Fixes: 55b447744389 ("ARM: OMAP1: Switch to use generic irqchip in preparation for sparse IRQ") Link: https://lore.kernel.org/r/20250205121151.289535-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-29ARM: dts: bcm2711: PL011 UARTs are actually r1p5Phil Elwell1-4/+5
[ Upstream commit 0de09025f161f67c07978c4742e221243d070d41 ] The ARM PL011 UART instances in BCM2711 are r1p5 spec, which means they have 32-entry FIFOs. The correct periphid value for this is 0x00341011. Thanks to N Buchwitz for pointing this out. Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20250223125614.3592-2-wahrenst@gmx.net Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-29ARM: dts: bcm2711: Fix xHCI power-domainStefan Wahren2-5/+1
[ Upstream commit f44fa354a0715577ca32b085f6f60bcf32c748dd ] During s2idle tests on the Raspberry CM4 the VPU firmware always crashes on xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze > state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Power grafx off [ 70.761127] USB: Set power to 0 [ 74.653040] USB: Failed to set power to 1 (-110) This seems to be caused because of the mixed usage of raspberrypi-power and bcm2835-power at the same time. So avoid the usage of the VPU firmware power-domain driver, which prevents the VPU crash. Fixes: 522c35e08b53 ("ARM: dts: bcm2711: Add BCM2711 xHCI support") Link: https://github.com/raspberrypi/linux/issues/6537 Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20250201112729.31509-1-wahrenst@gmx.net Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-17ARM: dts: ti/omap: gta04: fix pm issues caused by spi moduleAndreas Kemnade1-0/+10
commit 0cfbd7805fe13406500e6a6f2aa08f198d5db4bd upstream. Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal, disabling SPI leads to messages like when suspending: Powerdomain (core_pwrdm) didn't enter target state 0 and according to /sys/kernel/debug/pm_debug/count off state is not entered. That was not connected to SPI during the discussion of disabling SPI. See: https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/ The reason is that SPI is per default in slave mode. Linux driver will turn it to master per default. It slave mode, the powerdomain seems to be kept active if active chip select input is sensed. Fix that by explicitly disabling the SPI3 pins which used to be muxed by the bootloader since they are available on an optionally fitted header which would require dtb overlays anyways. Fixes: a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage") CC: stable@vger.kernel.org Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20241204174152.2360431-1-andreas@kemnade.info Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17ARM: dts: dra7: Add bus_dma_limit for l4 cfg busRomain Naour1-0/+2
commit c1472ec1dc4419d0bae663c1a1e6cb98dc7881ad upstream. A bus_dma_limit was added for l3 bus by commit cfb5d65f2595 ("ARM: dts: dra7: Add bus_dma_limit for L3 bus") to fix an issue observed only with SATA on DRA7-EVM with 4GB RAM and CONFIG_ARM_LPAE enabled. Since kernel 5.13, the SATA issue can be reproduced again following the SATA node move from L3 bus to L4_cfg in commit 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Fix it by adding an empty dma-ranges property to l4_cfg and segment@100000 nodes (parent device tree node of SATA controller) to inherit the 2GB dma ranges limit from l3 bus node. Note: A similar fix was applied for PCIe controller by commit 90d4d3f4ea45 ("ARM: dts: dra7: Fix bus_dma_limit for PCIe"). Fixes: 8af15365a368 ("ARM: dts: Configure interconnect target module for dra7 sata"). Link: https://lore.kernel.org/linux-omap/c583e1bb-f56b-4489-8012-ce742e85f233@smile.fr/ Cc: stable@vger.kernel.org # 5.13 Signed-off-by: Romain Naour <romain.naour@skf.com> Link: https://lore.kernel.org/r/20241115102537.1330300-1-romain.naour@smile.fr Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08ARM: dts: mediatek: mt7623: fix IR nodenameRafał Miłecki1-1/+1
[ Upstream commit 90234cf9b37c57201a24b78c217a91a8af774109 ] Fix following validation error: arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: cir@10013000: $nodename:0: 'cir@10013000' does not match '^ir(-receiver)?(@[a-f0-9]+)?$' from schema $id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml# Fixes: 91044f38dae7 ("arm: dts: mt7623: add ir nodes to the mt7623.dtsi file") Cc: linux-media@vger.kernel.org Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240617094634.23173-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: omap1: Fix up the Retu IRQ on Nokia 770Aaro Koskinen1-1/+1
[ Upstream commit ad455e48bba7f21bb5108406da0854cf8dede8ea ] The Retu IRQ is off by one, as a result the power button does not work. Fix it. Fixes: 084b6f216778 ("ARM: omap1: Fix up the Nokia 770 board device IRQs") Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/Z3UxH_fOzuftjnuX@darkstar.musicnaut.iki.fi Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: microchip: sama5d27_wlsom1_ek: Add no-1-8-v property to sdmmc0 nodeCristian Birsan1-0/+1
[ Upstream commit 4d9e5965df04c0adf260c3009c55d5fe240f7286 ] Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V. This property will stop the LDO regulator from switching to 1.8V when the MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the SDMMC interface pins in GPIO mode (PA0 - PA13). On this board, PA10 is used as GPIO to enable the power switch controlling USB Vbus for the USB Host. The change is needed to fix the PA10 voltage level to 3.3V instead of 1.8V. Fixes: 5d4c3cfb63fe ("ARM: dts: at91: sama5d27_wlsom1: add SAMA5D27 wlsom1 and wlsom1-ek") Suggested-by: Mihai Sain <mihai.sain@microchip.com> Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com> Tested-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20241119160107.598411-3-cristian.birsan@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: microchip: sama5d29_curiosity: Add no-1-8-v property to sdmmc0 nodeCristian Birsan1-0/+1
[ Upstream commit c21c23a0f2e9869676eff0d53fb89e151e14c873 ] Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V. This property will stop the LDO regulator from switching to 1.8V when the MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the SDMMC interface pins in GPIO mode (PA0 - PA13). On this board, PA6 is used as GPIO to enable the power switch controlling USB Vbus for the USB Host. The change is needed to fix the PA6 voltage level to 3.3V instead of 1.8V. Fixes: d85c4229e925 ("ARM: dts: at91: sama5d29_curiosity: Add device tree for sama5d29_curiosity board") Suggested-by: Mihai Sain <mihai.sain@microchip.com> Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com> Tested-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20241119160107.598411-2-cristian.birsan@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: stm32: Swap USART3 and UART8 alias on STM32MP15xx DHCOM SoMMarek Vasut1-2/+2
[ Upstream commit 479b8227ffc433929ba49200182b6383569f9615 ] Swap USART3 and UART8 aliases on STM32MP15xx DHCOM SoM, make sure UART8 is listed first, USART3 second, because the UART8 is labeled as UART2 on the SoM pinout, while USART3 is labeled as UART3 on the SoM pinout. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: stm32: Deduplicate serial aliases and chosen node for STM32MP15xx ↵Marek Vasut4-32/+7
DHCOM SoM [ Upstream commit 73317d327123472cb70e9ecbe050310f1d235e93 ] Deduplicate /aliases { serialN = ... } and /chosen node into stm32mp15xx-dhcom-som.dtsi , since the content is identical on all carrier boards using the STM32MP15xx DHCOM SoM. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Stable-dep-of: 479b8227ffc4 ("ARM: dts: stm32: Swap USART3 and UART8 alias on STM32MP15xx DHCOM SoM") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08arm: dts: socfpga: use reset-name "stmmaceth-ocp" instead of "ahb"Mamta Shukla1-3/+3
[ Upstream commit 62a40a0d5634834790f7166ab592be247390d857 ] The ahb reset is deasserted in probe before first register access, while the stmmacheth-ocp reset needs to be asserted every time before changing the phy mode in Arria10[1]. Changed in Upstream to "ahb"(331085a423b arm64: dts: socfpga: change the reset-name of "stmmaceth-ocp" to "ahb" ).This change was intended for arm64 socfpga and it is not applicable to Arria10. Further with STMMAC-SELFTEST Driver enabled, ethtool test also FAILS. $ ethtool -t eth0 [ 322.946709] socfpga-dwmac ff800000.ethernet eth0: entered promiscuous mode [ 323.374558] socfpga-dwmac ff800000.ethernet eth0: left promiscuous mode The test result is FAIL The test extra info: 1. MAC Loopback 0 2. PHY Loopback -110 3. MMC Counters -110 4. EEE -95 5. Hash Filter MC 0 6. Perfect Filter UC -110 7. MC Filter -110 8. UC Filter 0 9. Flow Control -110 10. RSS -95 11. VLAN Filtering -95 12. VLAN Filtering (perf) -95 13. Double VLAN Filter -95 14. Double VLAN Filter (perf) -95 15. Flexible RX Parser -95 16. SA Insertion (desc) -95 17. SA Replacement (desc) -95 18. SA Insertion (reg) -95 19. SA Replacement (reg) -95 20. VLAN TX Insertion -95 21. SVLAN TX Insertion -95 22. L3 DA Filtering -95 23. L3 SA Filtering -95 24. L4 DA TCP Filtering -95 25. L4 SA TCP Filtering -95 26. L4 DA UDP Filtering -95 27. L4 SA UDP Filtering -95 28. ARP Offload -95 29. Jumbo Frame -110 30. Multichannel Jumbo -95 31. Split Header -95 32. TBS (ETF Scheduler) -95 [ 324.881327] socfpga-dwmac ff800000.ethernet eth0: Link is Down [ 327.995360] socfpga-dwmac ff800000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx Link:[1] https://www.intel.com/content/www/us/en/docs/programmable/683711/21-2/functional-description-of-the-emac.html Fixes: 331085a423b ("arm64: dts: socfpga: change the reset-name of "stmmaceth-ocp" to "ahb") Signed-off-by: Mamta Shukla <mamta.shukla@leica-geosystems.com> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: aspeed: yosemite4: correct the compatible string for max31790Ricky CX Wu1-12/+4
[ Upstream commit b1a1ecb669bfa763ee5e86a038d7c9363eee7548 ] Fix the compatible string for max31790 to match the binding document. Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Signed-off-by: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com> Link: https://patch.msgid.link/20241003074251.3818101-6-Delphine_CC_Chiu@wiwynn.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: aspeed: yosemite4: Add required properties for IOE on fan boardsRicky CX Wu1-0/+4
[ Upstream commit c64ac96f8f8d957cdc6ec3c93dd9a6c4e6d78506 ] Add the required properties for IO expander on fan boards. Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Signed-off-by: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com> Link: https://patch.msgid.link/20241003074251.3818101-5-Delphine_CC_Chiu@wiwynn.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: aspeed: yosemite4: correct the compatible string of adm1272Ricky CX Wu1-2/+2
[ Upstream commit ece3e20e3389ec8a32944ad44746ee379bf1d3eb ] Remove the space in the compatible string of adm1272 to match the pattern of compatible. Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Signed-off-by: Ricky CX Wu <ricky.cx.wu.wiwynn@gmail.com> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com> Fixes: 2b8d94f4b4a4765d ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Link: https://patch.msgid.link/20240927085213.331127-1-Delphine_CC_Chiu@wiwynn.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: stm32: Fix IPCC EXTI declaration on stm32mp151Arnaud Pouliquen1-1/+1
[ Upstream commit 4ea654242e0c75bdf6b45d3c619c5fdcb2e9312a ] The GIC IRQ type used for IPCC RX should be IRQ_TYPE_LEVEL_HIGH. Replacing the interrupt with the EXTI event changes the type to the numeric value 1, meaning IRQ_TYPE_EDGE_RISING. The issue is that EXTI event 61 is a direct event.The IRQ type of direct events is not used by EXTI and is propagated to the parent IRQ controller of EXTI, the GIC. Align the IRQ type to the value expected by the GIC by replacing the second parameter "1" with IRQ_TYPE_LEVEL_HIGH. Fixes: 7d9802bb0e34 ("ARM: dts: stm32: remove the IPCC "wakeup" IRQ on stm32mp151") Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: stm32: Increase CPU core voltage on STM32MP13xx DHCOR SoMMarek Vasut1-2/+2
[ Upstream commit a4422a9183278162093d4524fdf4b6bbd7dd8a28 ] The STM32MP13xx DHCOR DHSBC is populated with STM32MP13xx part capable of 1 GHz operation, increase the CPU core voltage to 1.35 V to make sure the SoC is stable even if the blobs unconditionally force the CPU to 1 GHz operation. It is not possible to make use of CPUfreq on the STM32MP13xx because the SCMI protocol 0x13 is not implemented by upstream OpTee-OS which is the SCMI provider. Fixes: 6331bddce649 ("ARM: dts: stm32: Add support for STM32MP13xx DHCOR SoM and DHSBC board") Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: dts: imx7-tqma7: add missing vs-supply for LM75A (rev. 01xxx)Alexander Stein1-0/+1
[ Upstream commit 78e08cebfe41a99d12a3a79d3e3be913559182e2 ] Add missing supply for LM75. Fixes the kernel warning: lm75 0-0048: supply vs not found, using dummy regulator Fixes: c9d4affbe60a ("ARM: dts: imx: tqma7: add lm75a sensor (rev. 01xxx)") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Markus Niebel <markus.niebel@ew.tq-group.com> Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ARM: at91: pm: change BU Power Switch to automatic modeNicolas Ferre1-11/+20
[ Upstream commit 6fc5bdfa872b7da51b5507a1327a17c3db2fcf95 ] Change how the Backup Unit Power is configured and force the automatic/hardware mode. This change eliminates the need for software management of the power switch, ensuring it transitions to the backup power source before entering low power modes. This is done in the only location where this switch was configured. It's usually done in the bootloader. Previously, the loss of the VDDANA (or VDDIN33) power source was not automatically compensated by an alternative power source. This resulted in the loss of Backup Unit content, including Backup Self-refresh low power mode information, OTP emulation configuration, and boot configuration, for instance. Fixes: ac809e7879b1 ("ARM: at91: pm: switch backup area to vbat in backup mode") Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20241125165648.509162-1-nicolas.ferre@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-01-17ARM: dts: imxrt1050: Fix clocks for mmcJesse Taube1-1/+1
[ Upstream commit 5f122030061db3e5d2bddd9cf5c583deaa6c54ff ] One of the usdhc1 controller's clocks should be IMXRT1050_CLK_AHB_PODF not IMXRT1050_CLK_OSC. Fixes: 1c4f01be3490 ("ARM: dts: imx: Add i.MXRT1050-EVK support") Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>