linux-kernel - Re: [PATCH v4 6/7] pmdomain: rockchip: add regulator support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <vkeenncm2azxe6topeajc5d43d7gqgqrjtqadaz6cxbe4f7ucm@c4nhv5rrjvhd>
Date: Wed, 11 Dec 2024 00:27:17 +0100
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Heiko Stübner <heiko@...ech.de>
Cc: Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Ulf Hansson <ulf.hansson@...aro.org>, Mark Brown <broonie@...nel.org>, 
	Liam Girdwood <lgirdwood@...il.com>, Elaine Zhang <zhangqing@...k-chips.com>, 
	Adrián Martínez Larumbe <adrian.larumbe@...labora.com>, Boris Brezillon <boris.brezillon@...labora.com>, 
	Chen-Yu Tsai <wens@...e.org>, devicetree@...r.kernel.org, linux-rockchip@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH v4 6/7] pmdomain: rockchip: add regulator support

Hi,

On Tue, Dec 10, 2024 at 06:51:34PM +0100, Heiko Stübner wrote:
> Am Dienstag, 10. Dezember 2024, 18:06:46 CET schrieb Sebastian Reichel:
> > Some power domains require extra voltages to be applied. For example
> > trying to enable the GPU power domain on RK3588 fails when the SoC
> > does not have VDD GPU enabled. The same is expected to happen for
> > the NPU, which also has a dedicated supply line.
> > 
> > We get the regulator using devm_of_regulator_get(), so a missing
> > dependency in the devicetree is handled gracefully by printing a warning
> > and creating a dummy regulator. This is necessary, since existing DTs do
> > not have the regulator described. They might still work if the regulator
> > is marked as always-on. It is also working if the regulator is enabled
> > at boot time and the GPU driver is probed before the kernel disables
> > unused regulators.
> > 
> > The regulator itself is not acquired at driver probe time, since that
> > creates an unsolvable circular dependency. The power domain driver must
> > be probed early, since SoC peripherals need it. Regulators on the other
> > hand depend on SoC peripherals like SPI, I2C or GPIO. MediaTek does not
> > run into this, since they have two power domain drivers.
> > 
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> 
> Reviewed-by: Heiko Stuebner <heiko@...ech.de>
> 
> sidenote:
> part of me is asking, why we're limiting regulator handling only to
> specific individual domains when all domains sort of have supplying
> regulators - just ones that normally always stay on.
> 
> But, the binding is generic, so we can extend that later on in the driver
> if needed. Especially as this fixes a problem that happens right now.

I agree, that this should probably be extended to some additional
power domains, like the NPU in the future (as mentioned in the commit
message). Specifying the full requirements for all internal power
domains would result in some dependency cycles since the regulators
(for RK3588) need the SPI PMIC and for SPI controller needs some
power domains to probe :) We are also missing the necessary
information which regulators are needed for each particular power
domain. I don't think its worth the trouble.

Greetings,

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)