Re: USB regression in kernel 6.2.2

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

On 14.3.2023 16.00, Brian Morrison wrote:
> On Mon, 13 Mar 2023 12:06:59 +0200
> Mathias Nyman <mathias.nyman@linux.intel.com> wrote:
>>
>>
>> In your v6.2 logs the usb bus numbers are interleaved, in the v6.1
>> they are not. xhci driver registers two usb buses per host, one
>> High-Speed and one SuperSpeed.
>>
>> This change could be due to 6.2 commit:
>>
>> 4c2604a9a689 usb: xhci-pci: Set PROBE_PREFER_ASYNCHRONOUS
>>
>> Not sure why it would cause this regression, but worth testing it.
> 
> I have now reverted the above commit, it's only the one line in
> xhci-pci.c and it took a couple of hours to rebuild my kernel rpms which
> wasn't too bad.
> 
> With this change all of my USB devices are present again and the 3
> /dev/ttyUSB* nodes are all present and usable.
> 

Thanks for testing.
So setting PROBE_PREFER_ASYNCHRONOUS does trigger this issue for Renesas xHCI.

Was it so that with the devices connected to the Intel host everything worked
on 6.2 kernel?

Just to make sure that this is a vendor specific host issue and not generic xhci
driver issue.

If we can't quickly figure out the real reason for this then we just have to
revert that patch.

> I found this in the linux-usb list archives:
> 
> https://www.spinics.net/lists/kernel/msg4569289.html
> 
> and the first part of this patch series here:
> 
> https://www.spinics.net/lists/kernel/msg4569288.html
> 
> Should both of these patches be reverted? I assume so but I don't think
> I have anything that uses an ehci device to test it.
> 

Probably just the xhci one. I haven't heard of any ehci issues.

Alan (cc) would know better if there are any new odd ehci issues that can
be traced back to the async probe change.

> I know nothing about how this all works other than finding this:
> 
> "Note that the end goal is to switch the kernel to use asynchronous
> probing by default, so annotating drivers with
> PROBE_PREFER_ASYNCHRONOUS is a temporary measure that allows us to
> speed up boot process while we are validating the rest of the drivers."
> 
> which is at:
> 
> https://www.kernel.org/doc/html/v4.14/driver-api/infrastructure.html
> 
> so by the looks of it either this driver needs to initialise
> synchronously or there is a further problem which causes the bus
> ordering to be wrong but it also seems to be a work in progress so I
> don't know how this will eventually play out.
> 
  
Adding several persons who worked on xhci-pci-renesas.c in hope of figuring
this out.

Thanks
Mathias