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

On Mon, Oct 05, 2020 at 12:18:12PM -0700, Matthias Kaehlcke wrote:

quoted

On Mon, Oct 05, 2020 at 12:15:27PM -0400, Alan Stern wrote:

quoted

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.

quoted

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