On Mon, Oct 5, 2020 at 2:18 PM Matthias Kaehlcke <mka@xxxxxxxxxxxx> wrote: > > On Mon, Oct 05, 2020 at 12:15:27PM -0400, Alan Stern wrote: > > On Mon, Oct 05, 2020 at 09:06:55AM -0700, Matthias Kaehlcke wrote: > > > On Sat, Oct 03, 2020 at 08:41:42AM -0400, Alan Stern wrote: > > > > 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. > > > > One of the important points of my suggestion was that the resource init > > should be done _outside_ of the device's driver, precisely because the > > driver module might not even be loaded until the resources are set up > > and the device is discovered. > > > > The conclusion is that we need to have code that is aware of some > > detailed needs of a specific device but is not part of the device's > > driver. I'm not sure what the best way to implement this would be. > > Wouldn't it be possible to load the module when the DT specifies that > the device exists? For USB the kernel would need the VID/PID to identify > the module, these could be extracted from the compatible string. You don't even have to do that. Just add the MODULE_DEVICE_TABLE with the compatible strings and module loading will just work once you walk the USB bus in DT. Though probably you'd still need the VID/PID to create the device. Rob
