Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 4/9/26 23:17, Michal Pecio wrote:

> Five seconds later two control URBs are unlinked:
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 00000000122aa5e2, dev 3.1, ep 0x0, starting at offset 0x11e227b40
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: // Ding dong!
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 000000008a55bcd3, dev 3.1, ep 0x0, starting at offset 0x11e227b20
> Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Not queuing Stop Endpoint on slot 18 ep 0 in state 0x44

log continues with:
Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x11e227b40 (dma) in stream 0 URB 00000000122aa5e2
Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x11e227b20 (dma) in stream 0 URB 000000008a55bcd3
Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Set TR Deq ptr 0x11e227b40, cycle 0

One theory could be that xHC control endpoint refuses to restart when its dequeue
pointer is moved to a no-op TD like in this case (second cancelled URB).

xhci spec section 4.8.3 'Endpoint context state' additional Note states that:
"The Default Control Endpoint shall return to the Running state when the
  Doorbell is rung for the next Setup Stage TD sent to the endpoint."

Here the dequeue pointer will still be on the no-op TRB after queuing a new
control transfer after it. Not on a setup stage TRB

This can happen when we cancel two control URBs at the same time.
We turn the second URB TRBs starting at 0x11e227b40 into no-ops,
then move past the first URB TRBs starting at 0x11e227b20 to the second URB no-op TRB
at 0x11e227b40.

It's possible that disabling LPM helps as it reduces the number of control transfers,
so there is a much smaller risk of cancelling two control URBs in one go.

Thanks
Mathias