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

[Rangoju, Raju]

On 3/27/2025 3:04 PM, Michał Pecio wrote:
> On Thu, 27 Mar 2025 12:08:53 +0530, Rangoju, Raju wrote:
> > > 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.
> >
> > If such an endpoint is implemented, it could theoretically contribute
> > to scheduling conflicts similar to those caused by INT endpoints in
> > this context. However, our observations and testing on affected
> > platforms primarily involved periodic IN endpoints with service
> > intervals greater than 32ms interfering with ISOC OUT endpoints.
>
> In such case it would make sense to drop the check for
> usb_endpoint_xfer_int(&ep->desc)
> and rely on existing (xfer_int || xfer_isoc) in the outer 'if'.

Got it. I'll address this in subsequent patch.

> > I'm not completely sure about this corner case if HS OUT endpoints
> > can inadvertently get affected when co-existing with long-interval
> > LS/FS IN endpoints. Our IP vendor confirmed that LS/FS devices are
> > not affected.
>
> There is also a third case of a FS device behind an external HS hub.
> The device will look like FS to this code here, but the xHC will need
> to schedule HS transactions to service it.

In that case, the original code I provided in this patch doesn't include 
a check for 'udev->speed' and is applicable to FS devices as well. I 
think this code should remain unchanged to properly address the third 
scenario you mentioned.

> Regards,
> Michal