Re: [PATCH] xhci: Fix HIK camera control timeout on Etron hosts

[Kuangyi Chiang]

Hi,

Thanks for your feedback.

Michal Pecio <michal.pecio@xxxxxxxxx> 於 2026年10月29日週四 下午1:03寫道：
>
> On Thu, 29 Oct 2026 10:25:17 +0800, Kuangyi Chiang wrote:
> > We did some more testing.
> >
> > We don't see this issue during device enumeration.
> >
> > We also found that the timeout is not limited to UVC control
> > transfers. In one failure case, the first timeout was observed in
> > a UAC control transfer, followed by UVC control transfer timeouts:
> >
> > [  961.127402] usb 2-3: 5:2: failed to get current value for ch 0 (-110)
> > [  971.367443] uvcvideo 2-3:1.0: Failed to query (GET_DEF) UVC control
> > 2 on unit 2: -110 (exp. 2).
> > [  976.487473] uvcvideo 2-3:1.0: Failed to query (GET_DEF) UVC control
> > 3 on unit 2: -110 (exp. 2).
>
> But that's the same device and the same control pipe, right?

Yes, that's correct. Both UAC and UVC share EP0.

>
> So it just failed and we don't know why or whether it was the host or
> the device. And this is all during UVC/UAC probe, before any userspace
> begins using the device? Or could userspace be involved?

We launch a camera application during testing, so userspace
could be involved.

>
> The UVC driver has some aggressive PM; for every userspace ioctl, it
> calls usb_autopm_get_interface(), submits an interrupt URB which almost
> never completes and unlinks the URB before usb_autopm_put_interface().
> Repeated periodic unlinks is a known problem case for many xHCI chips.
>
> FYI, I found that 7c0c31c66a7f9 in v7.3 reduced occurrences of periodic
> unlink failures on other junk HW like ASMedia and VIA. Some of those
> failures, on ASMedia, resulted in control transfer breakage too.
>
> Have you tried 7.3 yet?

Not yet. Our tests were based on kernel 7.2.4.
Thanks for pointing out commit 7c0c31c66a7f9.

> Do you see any interrupt URBs there, using usbmon for example?

We haven't checked interrupt URBs with usbmon yet.

However, we captured USB traces using a protocol analyzer and
observed different behavior between the failing and successful
cases.

In the failing case, the device ACKed the DATA stage but kept
NAKing the STATUS stage until the transfer timed out.

In the successful case, the device initially NAKed the DATA stage,
then ACKed it, and the STATUS stage completed successfully.

We haven't determined the root cause yet.

In our tests, adding a 1 ms delay to both the UAC and UVC
control request paths prevented the timeouts.

When the delay was added to only one driver, we still observed
control transfer timeouts (-110) in the other driver.

>
> > So far, we have reproduced the issue with these xHCI hosts:
> >
> > ASMedia ASM1142 (1b21:1242)
> > Etron EJ168 (1b6f:7023)
> > Etron EJ188 (1b6f:7052)
> > Intel xHCI (8086:8d31)
>
> I don't know that Intel chip, but the others are quite buggy.
>
> Have you tried other HCs? Any successes?
> IME, chips from NEC, Fresco, Renesas are more reliable.

In our recent tests without the delay patches, we did not
observe any timeouts on the following HCs:

AMD EHCI (1002:4396)
AMD xHCI (1022:149c)
ASMedia ASM1042A (1b21:1142)
NEC xHCI (1033:0194)

Regards,
Kuangyi

>
> > The camera works with the EHCI host we tested without any additional
> > delay.
>
> That's a little suspicious, it may still be an xHCI bug.
>
> Regards,
> Michal