| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <117136352.nniJfEyVGO@diego>
Date: Thu, 04 Sep 2025 17:49:16 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Ulf Hansson <ulf.hansson@...aro.org>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel@...labora.com, linux-rockchip@...ts.infradead.org,
Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
Sebastian Reichel <sebastian.reichel@...labora.com>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Subject: Re: [PATCH] pmdomian: core: don't unset stay_on during sync_state
Hi,
Am Dienstag, 2. September 2025, 20:23:04 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> This reverts commit de141a9aa52d6b2fbeb63f98975c2c72276f0878.
>
> On RK3576, the UFS controller's power domain has a quirk that requires
> it to stay enabled, infrastricture for which was added in Commit
> cd3fa304ba5c ("pmdomain: core: Introduce dev_pm_genpd_rpm_always_on()").
>
> Unfortunately, Commit de141a9aa52d ("pmdomain: core: Leave powered-on
> genpds on until sync_state") appears to break this quirk wholesale. The
> result is that RK3576 devices with the UFS controller enabled but unused
> will freeze once pmdomain shuts off unused domains.
>
> Revert it until a better fix can be found.
>
> Fixes: de141a9aa52d ("pmdomain: core: Leave powered-on genpds on until sync_state")
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
just an observation independent of the conversation in the other thread.
This patch/revert whatever fixes an actual issue for me.
On the rk3588 the NPU power-domains are a hirarchy of
PD_NPU
PD_NPUTOP (core0)
PD_NPU1 (core1)
PD_NPU2 (core2)
and the PD_NPU does need a supply regulator.
(1) With "just" v6.17-rc + the rocket driver probing and then idling, I get:
# cat /sys/kernel/debug/regulator/regulator_summary
regulator use open bypass opmode voltage current min max
---------------------------------------------------------------------------------------
dc_12v 4 3 0 unknown 12000mV 0mA 12000mV 12000mV
[...]
vcc5v0_baseboard 2 1 0 unknown 5000mV 0mA 5000mV 5000mV
vcc5v0_sys 18 18 0 unknown 5000mV 0mA 5000mV 5000mV
[...]
vdd_npu_s0 0 0 0 normal 800mV 0mA 550mV 950mV
vcc_1v2_s3 2 1 0 unknown 1200mV 0mA 1200mV 1200mV
fe1b0000.ethernet-phy 1 0mA 0mV 0mV
vdd_gpu_s0 1 2 0 normal 675mV 0mA 550mV 950mV
fb000000.gpu-mali 1 0mA 675mV 850mV
fd8d8000.power-management:power-controller-domain 0 0mA 0mV 0mV
[...]
# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status children performance
/device runtime status managed by
------------------------------------------------------------------------------
[...]
gpu off-0 0
fb000000.gpu suspended 0 SW
npu2 off-0 0
fdada000.iommu suspended 0 SW
fdad0000.npu suspended 0 SW
npu1 off-0 0
fdaca000.iommu suspended 0 SW
fdac0000.npu suspended 0 SW
nputop off-0 0
npu1, npu2
fdab9000.iommu suspended 0 SW
fdab0000.npu suspended 0 SW
npu on 0
nputop
Observe that the PD_NPU never got its regulator and the domain also
never actually gets turned off. While the domains directly attached to
the cores get turned off.
(2) with Nicolas's patch applied on top, I get the correct behaviour,
that was also happening with v6.16 before
# cat /sys/kernel/debug/regulator/regulator_summary
regulator use open bypass opmode voltage current min max
---------------------------------------------------------------------------------------
dc_12v 4 3 0 unknown 12000mV 0mA 12000mV 12000mV
[...]
vcc5v0_baseboard 2 1 0 unknown 5000mV 0mA 5000mV 5000mV
vcc5v0_sys 18 18 0 unknown 5000mV 0mA 5000mV 5000mV
[...]
vdd_npu_s0 0 1 0 normal 800mV 0mA 550mV 950mV
fd8d8000.power-management:power-controller-domain 0 0mA 0mV 0mV
vdd_cpu_big1_s0 2 1 0 normal 1000mV 0mA 550mV 1050mV
cpu6-cpu 1 0mA 1000mV 1000mV
vdd_gpu_s0 1 2 0 normal 675mV 0mA 550mV 950mV
fb000000.gpu-mali 1 0mA 675mV 850mV
fd8d8000.power-management:power-controller-domain 0 0mA 0mV 0mV
[...]
# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status children performance
/device runtime status managed by
------------------------------------------------------------------------------
[...]
gpu off-0 0
fb000000.gpu suspended 0 SW
npu2 off-0 0
fdada000.iommu suspended 0 SW
fdad0000.npu suspended 0 SW
npu1 off-0 0
fdaca000.iommu suspended 0 SW
fdac0000.npu suspended 0 SW
nputop off-0 0
npu1, npu2
fdab9000.iommu suspended 0 SW
fdab0000.npu suspended 0 SW
npu off-0 0
nputop
The regulator handling is working correctly and also the parent PD_NPU
domain gets turned off when its children are off.
Heiko
Powered by blists - more mailing lists