Thread (28 messages) 28 messages, 8 authors, 2021-02-24

Re: [PATCH v5 0/4] USB: misc: Add onboard_usb_hub driver

From: Matthias Kaehlcke <mka@chromium.org>
Date: 2021-02-10 22:38:26
Also in: linux-arm-msm, linux-usb, lkml

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:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help