On Sun, 28 May 2017, Benjamin Herrenschmidt wrote:
> Hi !
>
> So I'm toying a bit with the gadget subsystem, writing an UDC driver
> for the Aspeed BMC SoC.
>
> One thing this HW does (which I'm not yet enabling) is that it can
> show as a virtual hub with up to 5 devices underneath.
>
> The hub and each device has independent EP0's, and there's a pool
> of 15 "generic" endpoints that can be assigned to them otherwise.
>
> There's additional HW support for the hub's EP1 to be mostly operating
> autonomously in HW, returning the virtual hub port status.
>
> However, all of the hub EP0 needs to be done in SW (descriptors
> etc...).
>
> So my question is how would you guys recommend I should structure this
> in my driver ? The "dumb" option is to implement all of the hub stuff
> locally in my driver, including the responses to all the descriptor
> request etc... and expose effectively 5 UDC gadget "slots" for the
> user to hookup gadget drivers to.
That's what I would do.
> Another approach would be to try to have a gadget "slot" for the hub
> itself that is somewhat hard-wired to a hub function (which I would
> implement separately).
>
> The latter "sounds" nicer, however there is a need for a back channel
> between the main driver and the hub function unless we lift the
> abstraction to contain hub controls which I'm not sure is worthwhile.
There are no "hub" gadget drivers. I suppose one could be written in
some sort of generic way, but there would be little point since there's
essentially no hub gadget hardware. Yours is the only example I've
heard of. After all, there's no reason for a hub to be programmable --
it serves only one function and that can be handled perfectly well by
fixed firmware.
> Also, can somebody enlighten me a bit more on what the "vbus" stuff
> is about ? I haven't quite figured it out. There seem to be no
> documentation (unless I missed it) on the various interfaces and UDC
> driver is supposed to provide.
Vbus is the +5V power provided on the USB bus by the host controller.
Bus-powered devices use it as their sole power source, and self-powered
devices may use it in conjunction with their own alternative power
source.
If a UDC driver sees that vbus isn't present then it can assume the UDC
isn't connected to anything. (There are some odd exceptions involving
USB OTG ("On-The-Go"), where the host and peripheral can swap roles --
normally you don't have to worry about that.) That's how the driver
detects a disconnection.
The interfaces required for a UDC driver are explained to some extent
by the kerneldoc in include/linux/usb/gadget.h. For anything you still
don't understand, feel free to ask on this mailing list.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
