On Mon, Oct 5, 2020 at 11:06 AM Matthias Kaehlcke [off-list ref] wrote:

On Sat, Oct 03, 2020 at 08:41:42AM -0400, Alan Stern wrote:

quoted

On Fri, Oct 02, 2020 at 05:58:22PM -0500, Rob Herring wrote:

quoted

On Fri, Oct 2, 2020 at 1:36 PM Alan Stern [off-list ref] wrote:

quoted

Regardless of how the situation is represented in DT, there remains the
issue of where (i.e., in which driver module) the appropriate code
belongs.  This goes far beyond USB.  In general, what happens when one
sort of device normally isn't hooked up through a power regulator, so
its driver doesn't have any code to enable a regulator, but then some
system does exactly that?

Even worse, what if the device is on a discoverable bus, so the driver
doesn't get invoked at all until the device is discovered, but on the
new system it can't be discovered until the regulator is enabled?

Yep, it's the same issue here with USB, MDIO which just came up a few
weeks ago, MMC/SD which hacked around it with 'mmc-pwrseq' binding
(not something I want to duplicate) and every other discoverable bus.
What do they all have in common? The kernel's driver model being
unable to cope with this situation. We really need a common solution
here and not bus or device specific hack-arounds.

To me this doesn't seem quite so much to be a weakness of the kernel's
driver model.

It's a platform-specific property, one that is not discoverable and
therefore needs to be represented somehow in DT or ACPI or something
similar.  Something that says "Device A cannot operate or be discovered
until power regulator B is enabled", for example.

The decision to enable the power regulator at system startup would be
kernel policy, not a part of the DT description.  But there ought to be
a standard way of recognizing which resource requirements of this sort
should be handled at startup.  Then there could be a special module (in
the driver model core? -- that doesn't really seem appropriate) which
would search through the whole DT database for resources of this kind
and enable them.

This might work for some cases that only have a single resource or multiple
resources but no timing/sequencing requirements. For the more complex cases
it would probably end up in something similar to the pwrseq series
(https://lore.kernel.org/patchwork/project/lkml/list/?series=314989&state=%2A&archive=both),
which was nack-ed by Rafael, Rob also expressed he didn't want to go
down that road.

TBC, I'm against repeating a 'pwrseq binding' like MMC has which is a
separate node. That's how the referenced binding started out IIRC, but
I was fine with what's in v16. I'm not against common/generic code for
handling pwrseq for 'simple' cases, but we need to allow for complex
cases and not try to keep extending some generic binding to handle
every last quirk.

Rob