On Fri, Jul 06, 2012 at 12:16:45PM -0400, Alan Stern wrote:
> On Thu, 5 Jul 2012, Sarah Sharp wrote:
>
> > The USB 3.0 specification says that sending a Set Feature or Clear
> > Feature for U1/U2 Enable is not a valid request when the device is in
> > the Default or Addressed state. It is only valid when the device is in
> > the Configured state.
> >
> > The original LPM patch attempted to disable LPM after the device had
> > been reset by hub_port_init(), before it had the configuration
> > reinstalled. The TI hub I tested with did not fail the Clear Feature
> > U1/U2 Enable request that khubd sent while it was in the addressed
> > state, which is why I didn't catch it.
> >
> > Move the LPM disable before the device reset, so that we can send the
> > Clear Feature U1/U2 Enable successfully, and balance the LPM disable
> > count.
> >
> > Also delete any calls to usb_enable_lpm() on error paths that lead to
> > re-enumeration. The calls will fail because the device isn't
> > configured, and it's not useful to balance the LPM disable count because
> > the usb_device is about to be destroyed before re-enumeration.
> >
> > Fix the early exit path ("done" label) to call usb_enable_lpm() to
> > balance the LPM disable count.
> >
> > Note that calling usb_reset_and_verify_device() with an unconfigured
> > device may fail on the first call to usb_disable_lpm(). That's because
> > the LPM disable count is initialized to 0 (LPM enabled), and
> > usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to
> > a device in the Addressed state. The next patch will fix that.
> >
> > This commit should be backported to kernels as old as 3.5, that contain
> > the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB: Disable USB
> > 3.0 LPM in critical sections."
>
> What about the LPM-related calls in usb_port_suspend and
> usb_port_resume? A device can be suspended even when it's not
> configured.
Before the device is unconfigured, the LPM disable count will be
incremented, and the control messages to disable LPM will be sent. When
we suspend the device, we'll increment the LPM disable count further.
However, udev->u1_params.timeout and udev->u2_params.timeout will be
zero, so we won't send the control transfers again. When we resume the
device, usb_lpm_enable will be called, and the LPM disable count will be
decremented, but it will remain non-zero, so we won't renable LPM.
With LTM, we'll see that udev->actconfig is NULL, and not send the
command to disable LTM on suspend. Similarly, when the device is
resumed, we'll see udev->actconfig is NULL and won't enable LTM.
Sarah Sharp
--
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
