| 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: <878503621.0ifERbkFSE@diego>
Date: Thu, 04 Sep 2025 17:55:33 +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
Am Donnerstag, 4. September 2025, 17:49:16 Mitteleuropäische Sommerzeit schrieb Heiko Stübner:
> 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.
ah and just saw Nicolas' mail from 6 minutes earlier.
So I guess what saves me here is the rocket driver being built as a
module, power-domain getting turned off early, rocket probes with
pd off and then gets its supplies as expected.
Heiko
>
> 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