Hi Krzysztof, On Wed, Feb 10, 2021 at 10:04:51PM +0100, Krzysztof Kozlowski wrote: > On Wed, Feb 10, 2021 at 09:10:35AM -0800, Matthias Kaehlcke wrote: > > This series adds the onboard_usb_hub_driver, the corresponding > > device tree bindings and creation of onboard_usb_hub platform in > > the xhci-plat driver during probe(). > > > > 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. > > It seems you are re-developing the power sequence drivers which perform > exactly this. Peter Chen some time ago was bringing power sequence to > USB devices, but I lost track where this ended up. > > Some of his (and my) very old work (2017...) can be found here: > https://github.com/krzk/linux/tree/wip/odroid-u3-usb3503-pwrseq pwrseq was brought up in the discussion about this driver, but wasn't deemed suitable for this use case which might require more complex configurations: https://lore.kernel.org/patchwork/patch/1313000/#1512725 > Instead of adding custom driver hiding some USB hub implementation, > power sequence seems a generic solution. What if you need to power cycle > other embedded USB device? Not a hub? The driver could be extended to also cover other types of devices if desired. Maybe it should be called usb-pwrseq then, even though it's not directly related with the original pwrseq series.
