[PATCH v2] usb: dwc2: resume root hub when device detect with suspend state
Julius Werner
jwerner at chromium.org
Wed Nov 19 11:27:25 PST 2014
On Wed, Nov 19, 2014 at 1:47 AM, 李云志 <lyz at rock-chips.com> wrote:
> hi Julius & Alan
>
> Shall we use dwc2's private status "hsotg->lx_state" here instesd of
> "hcd->state" for checking root hub is in suspend state ?
> I see the EHCI driver do something like this(ehci->rh_state ==
> EHCI_RH_SUSPENDED) before resume the root hub.
It's not this simple, because lx_state only relates to the status of
the one port on the DWC2. That may be suspended even though the root
hub is not.
The USB core differentiates between suspending individual ports, and
suspending the whole root hub (which should automatically suspend all
ports in a host-controller-specific manner). This distinction may seem
silly on DWC2 because there is only one port to suspend, but you still
need to make it so that the USB core doesn't get confused. So the
different things you need to keep track of are:
* is the one port individually suspended (through the
hub_control(SetPortFeature(PORT_SUSPEND)) method)
* is the root hub suspended (through calling bus_suspend())
* if the root hub gets suspended (through bus_suspend()), had the
port already been suspended before that (through a earlier
hub_control())... this is the thing I mentioned in your other patch
You can decide whether you want to bake that all into one variable
somehow or make it three, but we need to be able to tell all of these
things apart. The third bullet point will also require you to prevent
races of hub_control() with bus_suspend() (not sure if the kernel
already guarantees that or not), so I think we may have to rethink the
way the spinlock works (because it currently doesn't cover that).
More information about the Linux-rockchip
mailing list