On Sun, 2017-06-11 at 10:09 -0400, Alan Stern wrote:
>
> Under a non-emulated hub, the wakeup() function would start sending the
> wakeup signal upstream and then return. The gadget's resume callback
> would not be invoked until later, probably at the end of the wakeup
> sequence (the API isn't s
On Sun, 11 Jun 2017, Benjamin Herrenschmidt wrote:
> > > Now where things become interesting:
> > >
> > > - A wakeup() from the gadget. If the port is suspended but nothing
> > > else above it, what do I do ? Mark the port resumed and move on ? Do I
> > > need to call the gadget resume() callbac
On Sun, 2017-06-11 at 11:00 +1000, Benjamin Herrenschmidt wrote:
>
> > No, a reset sent to the vhub does not broadcast anything to the
> > downstream ports. It merely disables all of them and clears all their
> > status bits (the connect and connect-change bits will then get set if a
> > gadget i
On Sat, 2017-06-10 at 12:58 -0400, Alan Stern wrote:
> On Sat, 10 Jun 2017, Benjamin Herrenschmidt wrote:
>
> with the obvious resume case above I assume. A port reset
> > would probably also "resume" though I would forward a reset to the
> > gadget rather than a resume, right ? (but clear my "su
On Sat, 10 Jun 2017, Benjamin Herrenschmidt wrote:
> Hi !
>
> The USB spec is twisting my brain sideways trying to figure out how to
> properly handle suspend/resume in the case of the aspeed vHub.
>
> Reminder: This is a combo-gadget HW that has 5 UDC "ports" (gadgets)
> and a virtual hub above
Hi !
The USB spec is twisting my brain sideways trying to figure out how to
properly handle suspend/resume in the case of the aspeed vHub.
Reminder: This is a combo-gadget HW that has 5 UDC "ports" (gadgets)
and a virtual hub above them, so it looks to the host as a hub with 5
ports, the hub func
