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

["André Draszik" <andre.draszik@linaro.org>]

Hi Mark,

On Sun, 2025-11-16 at 01:14 +0000, Mark Brown wrote:
> On Fri, Nov 14, 2025 at 09:56:41PM +0000, André Draszik wrote:
> 
> > I'm happy to use an alternative approach that can solve my problem, if there
> > is something that I have missed. I think the commit message for patch 8
> > describes the problem in better detail than this one.
> 
> The more normal thing would be to just register one child device for all
> the regulators and then register them in a loop in the probe function of
> that device.

Thanks Mark, I'm aware of that, but that approach doesn't work as
I hoped to have explained in the commit message in patch 8 in this
series, I'll copy it below:

--- snip ---
Bucks can conceivably be used as supplies for LDOs, but currently it
can be impossible to mark BUCKs as LDO supplies. This becomes
particularly an issue with the upcoming support for the S2MPG11 PMIC.

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.

So we have a circular dependency here - LDOs (and potentially also
bucks) of one PMIC depend on bucks of the other.

This means that if all S2MPG10 rails are handled by the same instance
of the S2MPG10 regulator driver, probe of all rails will defer, 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 and probe will
ultimately fail. In other words it's currently impossible to mark BUCKs
as LDO supplies.

Additionally, multiple (LDO-) rails may share the same (buck) supply
rail and some of these LDOs might supply important consumers, e.g. RAM.
To stay with RAM, if one of those consumers needs to defer probe before
the rail supplying RAM has probed, the shared (buck) supply gets
disabled and the whole system comes to a halt, since Linux hasn't seen
the DDR-supplying rail yet, and hasn't had a chance to mark the buck
rail as having another consumer.

By splitting all rails into separate driver instances, the circular
dependency is gone, each individual instance can probe when its supplies
are ready. This approach also solves the multiple-consumers-on-one-rail
issue during probe.

The mfd_cell's ::id field is used to inform the regulator driver which
regulator to instantiate.
--- snap ---

Does that explain the problem well enough?

So unless I'm missing something, registering just one child device
simply doesn't work, the rails have to be instantiated individually.

One could register all bucks as one device, and then only the LDOs
individually, but IMHO that approach would make it more convoluted,
not simpler.

Do you have any other suggestions?


Cheers,
Andre'