linux-stable.git/arch/arm/boot, branch linux-6.13.y Linux kernel stable tree ARM: dts: imx6qdl-apalis: Fix poweroff on Apalis iMX6 2025-03-28T21:04:56+00:00 Stefan Eichenberger stefan.eichenberger@toradex.com 2025-01-10T15:18:29+00:00 1748132fbbe6e4ae7a3dfc2bd7d6b666b192dc14 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> 
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>
ARM: dts: BCM5301X: Fix switch port labels of ASUS RT-AC3200 2025-03-28T21:04:52+00:00 Chester A. Unal chester.a.unal@arinc9.com 2025-03-04T15:55:36+00:00 8fdd95c4c8182576fd1858e5a5118d6e9092a056 [ 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> 
[ 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>
ARM: dts: BCM5301X: Fix switch port labels of ASUS RT-AC5300 2025-03-28T21:04:51+00:00 Chester A. Unal chester.a.unal@arinc9.com 2025-03-03T13:06:50+00:00 45beded21ed3450bf007407837e2c4c86a3b6aba [ 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> 
[ 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>
ARM: dts: bcm2711: Don't mark timer regs unconfigured 2025-03-28T21:04:51+00:00 Phil Elwell phil@raspberrypi.com 2025-02-22T09:41:13+00:00 f2253815757bf74e8f5fe2d69764c3c5117ae0a9 [ 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> 
[ 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>
ARM: dts: bcm2711: PL011 UARTs are actually r1p5 2025-03-28T21:04:51+00:00 Phil Elwell phil@raspberrypi.com 2025-02-23T12:56:13+00:00 173d2fb15b643812bcc1c6d3a5c126157b08de51 [ 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> 
[ 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>
ARM: dts: bcm2711: Fix xHCI power-domain 2025-03-28T21:04:51+00:00 Stefan Wahren wahrenst@gmx.net 2025-02-01T11:27:29+00:00 393947e06867923d4c2be380d46efd03407a8ce2 [ 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> 
[ 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>
ARM: dts: ti/omap: gta04: fix pm issues caused by spi module 2025-02-17T10:36:37+00:00 Andreas Kemnade andreas@kemnade.info 2024-12-04T17:41:52+00:00 8e9f20390e632c19f97e154d8b6a2d21c558fee5 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> 
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>
ARM: dts: dra7: Add bus_dma_limit for l4 cfg bus 2025-02-17T10:36:37+00:00 Romain Naour romain.naour@skf.com 2024-11-15T10:25:37+00:00 f348d868579b82d0abbe08bdc693beea0fbcb846 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> 
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>
ARM: dts: mediatek: mt7623: fix IR nodename 2025-02-08T09:01:56+00:00 Rafał Miłecki rafal@milecki.pl 2024-06-17T09:46:33+00:00 db4f26e221fd654d31dd96f5ea95d449e32f660f [ 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> 
[ 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>
ARM: dts: microchip: sama5d27_wlsom1_ek: Add no-1-8-v property to sdmmc0 node 2025-02-08T09:01:52+00:00 Cristian Birsan cristian.birsan@microchip.com 2024-11-19T16:01:07+00:00 2a92cffb8daceaba4e006e6aa05849b60d7594fe [ 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> 
[ 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>