linux-kernel - Re: [PATCH v3 09/20] mfd: sec: Add support for S2MPG11 PMIC via ACPM

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: <efb6d4a68d70e0f24b981aa0dff69e3186827f75.camel@linaro.org>
Date: Mon, 17 Nov 2025 06:44:18 +0000
From: André Draszik <andre.draszik@...aro.org>
To: Mark Brown <broonie@...nel.org>
Cc: Lee Jones <lee@...nel.org>, 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>, Linus Walleij <linus.walleij@...aro.org>, Bartosz
 Golaszewski	 <brgl@...ev.pl>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 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 v3 09/20] mfd: sec: Add support for S2MPG11 PMIC via ACPM

Hi Mark,

On Sun, 2025-11-16 at 16:46 +0000, Mark Brown wrote:
> On Sun, Nov 16, 2025 at 12:49:55PM +0000, André Draszik wrote:
> 
> > The typical use of the S2MPG10 PMIC is in combination with an S2MPG11
> > PMIC in a main/sub configuration. Bucks of one are usually used as
> > supplies for LDOs of either itself or of the other: several S2MPG10
> > LDOs are consumers of various S2MPG10 bucks & S2MPG11 bucks, and
> > several S2MPG11 LDOs are supplied by various S2MPG10 bucks & S2MPG11
> > bucks.
> 
> If you're doing something to resolve such rats nesting of PMICs you
> should do something that works as standard rather than just bodging this
> one driver in a way that treats this specific device as a special
> snowflake.  That might reasonably mean going and refactoring existing
> drivers to look like this one,

I have no insight into which other drivers / setups might have a similar
problem.

>  it is a fairly obvious approach.  We
> should really have a uniform approach that works well rather than random
> variation between devices though.
> 
> We could also do this at the regulator level by arranging for the
> devices we make for the regulators to have deferrable drivers, that'd
> be a core only change.

That should work, yes, I'll investigate a little.

Thanks
A.