On Sat, Oct 03, 2020 at 08:41:42AM -0400, Alan Stern wrote: > On Fri, Oct 02, 2020 at 05:58:22PM -0500, Rob Herring wrote: > > On Fri, Oct 2, 2020 at 1:36 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > 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. It seems to me that initialization of the resources needs to be done by the/a driver for the device, which knows about the sequencing requirements. Potentially this could be done in a pre-probe function that you brought up earlier.
