On 02.05.2016 18:18, Alan Stern wrote:
On Mon, 2 May 2016, Mathias Nyman wrote:
On 29.04.2016 22:25, Alan Stern wrote:
When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward. The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters. This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.
However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary. The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.
It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs. Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.
And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.
Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
Tested-by: Matthew Giassa <matthew@xxxxxxxxxx>
CC: Mathias Nyman <mathias.nyman@xxxxxxxxx>
CC: <stable@xxxxxxxxxxxxxxx>
---
Mathias, can you check that this is right? If the driver's
disable_hub_initiated_lpm flag isn't set then binding or unbinding it
shouldn't require any changes to the LPM parameters. The flag gets
used in only one place, in xhci_calculate_lpm_timeout(), and if it
isn't set then then result would be the same as if the driver weren't
bound.
Thanks.
It looks like xhci driver calculates the u1 and u2 timeout values for
ports based on udev->u1_params.sel * x (where x depends on endpoint type).
It loops through all active interfaces all endpoints, and picks the worst
(longest) timeout as the timeout value.
In this sense if a interface drive disappears or appears it could be possible
that the timeout values change, even if the xhci_calculate_lpm_timeout() is
not set.
I don't understand. The calculation below doesn't care whether the
interface is bound to a driver, does it? It looks at all the endpoints
in all the current altsettings, whether they are bound or not.
Or have I misunderstood something?
No, you're right.
checking for a driver (udev->actconfig->interface[i]->dev.driver) while looping
through the interfaces is only done for the disable_hub_initiated_lpm flag.
The rest of the calculations don't care if a driver is bound of not.
So looks good to me.
-Mathias
--
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
