linux-kernel - Re: [PATCH 07/17] mfd: sec-common: Instantiate s2mpg10 bucks and ldos separately

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] [day] [month] [year] [list]

Message-ID: <e29a3494986d78ca964846b54fd3e5bc78e4afd4.camel@linaro.org>
Date: Wed, 25 Jun 2025 16:12:07 +0100
From: André Draszik <andre.draszik@...aro.org>
To: Lee Jones <lee@...nel.org>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>, Rob Herring <robh@...nel.org>,
  Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
 Liam Girdwood <lgirdwood@...il.com>,  Mark Brown <broonie@...nel.org>,
 Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski	
 <brgl@...ev.pl>, Peter Griffin <peter.griffin@...aro.org>, Will McVicker	
 <willmcvicker@...gle.com>, kernel-team@...roid.com, 
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH 07/17] mfd: sec-common: Instantiate s2mpg10 bucks and
 ldos separately

On Fri, 2025-06-13 at 15:49 +0100, André Draszik wrote:
> Hi Lee,
> 
> Thanks for your review!
> 
> On Fri, 2025-06-13 at 15:19 +0100, Lee Jones wrote:
> > On Wed, 04 Jun 2025, André Draszik wrote:
> > 
> > > Bucks can conceivably be used as supplies for LDOs, which means we need
> > > to instantiate them separately from each other so that the supply-
> > > consumer links can be resolved successfully at probe time.
> > > 
> > > By doing so, the kernel will defer and retry instantiating the LDOs
> > > once BUCKs have been created while without this change, it can be
> > > impossible to mark BUCKs as LDO supplies. This becomes particularly
> > > an issue with the upcoming support for the S2MPG11 PMIC, where
> > > typically certain S2MP10/11 buck rails supply certain S2MP11/10 LDO
> > > rails.
> > > 
> > > The platform_device's ::id field is used to inform the regulator driver
> > > which type of regulators (buck or ldo) to instantiate.
> > 
> > I'm confused.
> > 
> > There is nothing that differentiates the two, so why do you need to?
> 
> On gs101, we have two PMICs, s2mpg10 and s2mpg11. Several s2mpg10 LDOs
> are consumers of various s2mpg10 bucks & s2mpg10 bucks, and several
> s2mpg11 LDOs are also supplied by various s2mpg10 bucks & s2mpg11 bucks.
> 
> So we have a circular dependency here. LDOs of one PMIC depend on bucks
> of the other.
> 
> If all s2mpg10 rails are handled by the same instance of the s2mpg10
> regulator driver, probe will defer (and ultimately fail), because the
> supplies to the LDOs can not be resolved during probe.
> 
> The same goes for s2mpg11.
> 
> The result is that neither driver can probe successfully (unless you're
> _extremely_ lucky due to parallel probing, but we can not rely on that,
> of course).
> 
> By splitting LDO and buck rails into separate instances, this circular
> dependency is gone, the buck-instance of each respective driver can probe,
> which then allows the LDO instance of the other driver to probe.

My next version will have that changed to be fully granular (one mfd cell
per regulator), since I've come to the conclusion that the high-level
split is non-ideal, otherwise important supplies might be turned off during
EPROBE_DEFER of a consumer, affecting unrelated consumers (rails) that
haven't probed yet, since multiple consumers share the same supply.


Cheers,
Andre'