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: <aRn_-o-vie_QoDXD@sirena.co.uk>
Date: Sun, 16 Nov 2025 16:46:50 +0000
From: Mark Brown <broonie@...nel.org>
To: André Draszik <andre.draszik@...aro.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

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, 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.

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