Re: [PATCH v4] usb: xhci: quirk for data loss in ISOC transfers

["Michał Pecio" <michal.pecio@gmail.com>]

> >> The root cause of the MSE is attributed to the ISOC OUT endpoint
> >> being omitted from scheduling. This can happen either when an IN
> >> endpoint with a 64ms service interval is pre-scheduled prior to
> >> the ISOC OUT endpoint or when the interval of the ISOC OUT
> >> endpoint is shorter than that of the IN endpoint.

To me this reads like the condition is

(IN ESIT >= 64ms && IN pre-scheduled before OUT) ||
(OUT ESIT < IN ESIT)

but I suspect it really is

(IN ESIT >= 64ms) &&
(IN pre-scheduled before OUT || OUT ESIT < IN ESIT)

because otherwise this workaround wouldn't really help:
ISOC OUT ESIT < INT IN ESIT is almost always true in practice.


Moving "either" later maybe makes it more clear:

This can happen when an IN endpoint with a 64ms service interval either
is pre-scheduled prior to the ISOC OUT endpoint or the interval of the
ISOC OUT endpoint is shorter than that of the IN endpoint.

> > This code limits interval to 32ms for Interrupt endpoints (any
> > speed), should it be isoc instead?
>
> The affected transfer is ISOC. However, due to INT EP service
> interval of 64ms causing the ISO EP to be skipped, the WA is to
> reduce the INT EP service to be less than 64ms (32ms).

What if there is an ISOC IN endpoint with 64ms ESIT? I haven't yet seen
such a slow isoc endpoint, but I think they are allowed by the spec.
Your changelog suggests any periodic IN endpoint can trigger this bug.

> > Are Full-/Low-speed devices really also affected?
> > 
> No, Full-/Low-speed devices are not affected.

The interesting question here is whether LS/FS devices with long
interval IN endpoints can disrupt a HS OUT endpoint or not, because
the patch solves the problem from the IN endpoint's side.

(I assume that SS probably has no effect on HS schedule.)

Regards,
Michal