[PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Alan Stern]

On Wed, 16 Dec 2015, Rob Herring wrote:

> On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
> >> Hi all,
> >>
> >> There is a known issue that the USB code can't handle USB HUB's
> >> external pins well, in that case, it may cause some onboard
> >> USB HUBs can't work since their PHY's clock or reset pin needs to
> >> operate.
> >>
> >> The user reported this issue at below:
> >> http://www.spinics.net/lists/linux-usb/msg131502.html
> >>
> >> In this patch set, I add a generic onboard USB HUB driver to
> >> handle this problem, the external signals will be configured
> >> before usb controller's initialization, it much likes we did
> >> it at board code before.
> >>
> >> The user needs to add this generic hub node at dts to support it.
> >>
> >> @The udoo users, help to test please.
> >
> > I still think need to do this properly by representing the hub
> > device as a USB device, using power sequencing code like MMC does.
> 
> I agree on doing it properly, but am not sure that pwrseq binding for
> MMC is proper. The pwrseq binding is fairly limited and working around
> the driver model IMO. Hubs may also need I2C setup which I don't think
> could be done generically other than some defined sequence of i2c
> transactions. The current project I'm working on needs to use I2C to
> configure the hub to use HSIC mode for example. I really think we need
> a pre-probe driver hook to handle this. That would allow device
> specific setup to live in the driver.
> 
> Perhaps a more simple approach would be just forcing driver probe if a
> DT node is present. I'm not all that familiar with USB drivers, but
> presumably there is some setup before probe like setting the USB
> device address. We'd have to allow doing that later during probe.

It's not clear (to me, anyway) how this is meant to work.  USB is a
completely discoverable bus: There is no way to represent devices
statically; they have to be discovered.  But a device can't be
discovered unless it is functional, so if an onboard hub (or any other
sort of USB device) requires power, clocks, or something similar in
order to function, it won't be discovered.  There won't be any device
structure to probe, and "forcing driver probe" won't accomplish
anything.

It seems to me that the only way something like this could be made to
work is if the necessary actions are keyed off the host controller (and
in particular, _not_ the hub driver), presumably at the time the
controller is probed.  With anything else, you run the risk that the
necessary resources won't get enabled before they are needed.

Alan Stern