On Mon, Oct 5, 2020 at 2:36 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Oct 05, 2020 at 12:18:12PM -0700, Matthias Kaehlcke wrote: > > On Mon, Oct 05, 2020 at 12:15:27PM -0400, Alan Stern wrote: > > > 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. > > Loading a driver module whenever DT says a device exists? Not a bad > idea. I don't know what would be involved, but no doubt it is possible. MODULE_DEVICE_TABLE mostly as I mentioned in my other reply. > Note that, except for a few special cases, the kernel identifies the > appropriate driver for USB hubs not by the VID/PID but instead by the > device class or interface class. I suppose the compatible string could > include that information too? We can go back to 1998 OpenFirmware and it's already there[1]. 'usb,class9' for a hub. There's a few other variations defined. > > Having the initialization code outside of the driver could lead to code > > duplication, since the driver might want to power the device down in > > certain situations (e.g. system suspend). > > True. On the other hand, how common do you think it would be for > drivers not to want to mess with the power settings? I think in that case you'd generally want firmware to enable things and the kernel then does no power control. We have ~1500 boards using DT and maybe ~10 with USB devices described in DT. So the whole thing is not common to begin with. Rob [1] https://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
