On 12.9.2019 17.49, Jan Schmidt wrote:
If an endpoint is encountered that returns USB3_LPM_DEVICE_INITIATED, keep
checking further endpoints, as there might be periodic endpoints later
that return USB3_LPM_DISABLED due to shorter service intervals.
Without this, the code can set too high a maximum-exit-latency and
prevent the use of multiple USB3 cameras that should be able to work.
Signed-off-by: Jan Schmidt <[email protected]>
Tested-by: Philipp Zabel <[email protected]>
---
drivers/usb/host/xhci.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 03d1e552769b..1986b88661fc 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4673,12 +4673,12 @@ static int xhci_update_timeout_for_endpoint(struct
xhci_hcd *xhci,
alt_timeout = xhci_call_host_update_timeout_for_endpoint(xhci, udev,
desc, state, timeout);
- /* If we found we can't enable hub-initiated LPM, or
+ /* If we found we can't enable hub-initiated LPM, and
* the U1 or U2 exit latency was too high to allow
- * device-initiated LPM as well, just stop searching.
+ * device-initiated LPM as well, then we will disable LPM
+ * for this device, so stop searching any further.
*/
- if (alt_timeout == USB3_LPM_DISABLED ||
- alt_timeout == USB3_LPM_DEVICE_INITIATED) {
+ if (alt_timeout == USB3_LPM_DISABLED) {
*timeout = alt_timeout;
return -E2BIG;
}
Thanks, nice catch. Adding to queue.
While looking at this I see we have a similar issue if driver has
"disable_hub_initiated_lpm" flag set.
xhci_get_timeout_no_hub_lpm() might return USB3_LPM_DEVICE_INITIATED
before we check if periodic endpoints would require disabling LPM
completely.
xhci_calculate_lpm_timeout()
...
for (i = 0; i < config->desc.bNumInterfaces; i++) {
...
if (intf->dev.driver) {
...
if (driver && driver->disable_hub_initiated_lpm) {
return xhci_get_timeout_no_hub_lpm(udev, state);
I'll write a patch for that
-Mathias
