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.
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
