On Tue, 27 Jul 2021 at 03:41, Matthias Kaehlcke <mka@xxxxxxxxxxxx> wrote: > > This series adds: > - the onboard_usb_hub_driver > - glue in the xhci-plat driver to create and destroy the > onboard_usb_hub platform devices if needed > - a device tree binding for the Realtek RTS5411 USB hub controller > - device tree changes that add RTS5411 entries for the QCA SC7180 > based boards trogdor and lazor > - a couple of stubs for platform device functions to avoid > unresolved symbols with certain kernel configs > > The main issue the driver addresses is that a USB hub needs to be > powered before it can be discovered. For discrete onboard hubs (an > example for such a hub is the Realtek RTS5411) this is often solved > by supplying the hub with an 'always-on' regulator, which is kind > of a hack. Some onboard hubs may require further initialization > steps, like changing the state of a GPIO or enabling a clock, which > requires even more hacks. This driver creates a platform device > representing the hub which performs the necessary initialization. > Currently it only supports switching on a single regulator, support > for multiple regulators or other actions can be added as needed. > Different initialization sequences can be supported based on the > compatible string. I have the feeling that you might want to check if you can use pwrseq subsystem being proposed at https://lore.kernel.org/linux-arm-msm/20211006035407.1147909-1-dmitry.baryshkov@xxxxxxxxxx/. It has been created for exactly the same reason of handling complex power up/down requirements in a bus-neutral way. So instead of creating an onboard-usb-hub, you might want to populate the hub node with the reference to pwrseq device and make usb core call into pwrseq. How does that sound to you? > > Besides performing the initialization the driver can be configured > to power the hub off during system suspend. This can help to extend > battery life on battery powered devices which have no requirements > to keep the hub powered during suspend. The driver can also be > configured to leave the hub powered when a wakeup capable USB device > is connected when suspending, and power it off otherwise. -- With best wishes Dmitry
