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

[Kuangyi Chiang]

Hi,

Thanks for the explanation.

Michal Pecio <michal.pecio@xxxxxxxxx> 於 2026年11月3日週二 下午2:28寫道：
>
> On Tue, 3 Nov 2026 09:01:50 +0800, Kuangyi Chiang wrote:
> > 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.
>
> Could it be a device bug triggered by timing? Some xHCI controllers
> perform control transfers faster than others - we have seen anything
> (IIRC) from complete transfer in a microframe, through one stage per
> microframe, up to one stage per frame even for high-speed devices.
> We are not aware of any way to influence this, besides delaying URB
> submissions. I don't know how fast EHCI controllers are.

Hans de Goede also suggested that EHCI naturally spaces consecutive
control requests about 1 ms apart, while xHCI can issue them
back-to-back, and some older devices may need extra time between
control requests.

That could explain why a 1 ms delay helps in our tests, although we
have not confirmed the root cause yet.

For reference:
https://lore.kernel.org/linux-media/CAHN5xi1_T=C1v=hDqoHxLtc9uuZO5Evsv2hS2-ZSGd3_mo=qSA@xxxxxxxxxxxxxx/T/#m99c67eb54d5b60bad94d2643f4c28068e1653894

>
> > > > 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)
>
> ASM1042A surprises me, because ASMedia in general are among the fastest
> ones, except AMD Promontory chipsets which are extremely slow. NEC was
> slightly slower than the fastest chips IIRC. I'm not familiar with AMD
> Matisse and have no idea what xHCI IP they put inside.
>
> Purely out of curiosity, could you connect a USB 3.0 NIC like RTL8153
> or AX88197 to Matisse and see if it breaks after a minute of:
>
>   while :; do ifconfig <xxx> up ; ifconfig <xxx> down ; echo -n . ; done
>
> I found this to be a 100% reliable way to detect ASMedia controllers,
> including those in AMD Promontory chipsets. This is the periodic unlink
> bug I mentioned, which is mostly mitigated by 7c0c31c66a7f9 in 7.3,
> so the test is more effective on 7.2.

Unfortunately, we don't have either of those USB 3.0 network adapters
available for testing.

Regards,
Kuangyi