Unless someone writes a tool to interrogate the kernel source and compares it with what hardware is installed (via usb-ids and pci-ids, for many of the cases), it is not easy to identify what changed configuration options may be relevant for their hardware.

My problem was that the CONFIG_USB_XHCI_PCI_RENESAS=m option was disabled by default in the 6.12.0-rc? kernels, so building a new kernel with CONFIG_USB_XHCI_PCI_RENESAS=m is required if one has the hardware (and not all users build their own kernels).

The simplest check for those considering installing a new kernel (whether or not they do build their own kernels) would be to compare the kernel .config file for their currently running kernel and for the new kernel (which they may have built themselves or just installed a binary from an upstream repository) and check what was different that might be applicable to their hardware.

However, a pci-ids / usb-ids check from installed hardware and new kernel source would be more complete.

Hardware detection / identification in this case, ie lspci -v did show the Renesas USB 3.0 controller and that kernel module xhci_pci was used on this hardware, but not that kernel module xhci_pci_renesas was needed, since that hadn't been built as CONFIG_USB_XHCI_PCI_RENESAS=m needed to be explicitly enabled.

A new kernel release changelog that lists applicable pci-ids / usb-ids with changed support (new modules needed, removed, changes in configuration options needed to enable/disable hardware support) would also help.

When a new Debian kernel is released to Experimental, I will file a bug report if the xhci_pci_renesas module is not included in the built kernel.

EDIT, according to the following Debian kernel merge request, CONFIG_USB_XHCI_PCI_RENESAS=m should be enabled for the Debian GNU/Linux 6.12 kernels:
https://salsa.debian.org/kernel-team/li … ote_528686

I beg to differ.

I don't think you have wasted your time.
You have spent / invested it. ie: in doing part of the legwork needed to make progress in the testing of the upcoming 6.12 kernel release.
Not the same by any means.

Thank you for that.

Yes.
My box running Devuan Daedalus has a card with one of those  ubiquitous controllers, works properly:

~$ lspci
--- snip ---
04:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
--- snip ---
~$ 

~$ lspci -n
--- snip ---
04:00.0 0c03: 1912:0014 (rev 03)
--- snip ---
~$ 

/boot$ cat config-6.1.0-26-amd64 | grep -i CONFIG_USB_XHCI_PCI_RENESAS
# CONFIG_USB_XHCI_PCI_RENESAS is not set
/boot$ 

Being 6.12 a release candidate (ie: in testing) this glitch will probably be ironed out by the time 6.12 is released, possibly by mid/end of november.

You may want to consider filing a bug report upstream bug report to make both your efforts count and the maintainers aware of the problem.

Best,

A.

The hardware affected was identified as:

lspci output:

02:00.0 USB controller: Renesas Electronics Corp. uPD720201 USB 3.0 Host Controller (rev 03)

lspci -n output:

02:00.0 0c03: 1912:0014 (rev 03)

This hardware had been supported in the Linux kernel for some years with the xhci_pci module enabled by CONFIG_USB_XHCI_PCI=m

Now with 6.12.0-rc? kernels it also requires the xhci_pci_renesas module enabled by CONFIG_USB_XHCI_PCI_RENESAS=m.

The problem is that CONFIG_USB_XHCI_PCI_RENESAS=m is not enabled unless manually selected.

Hope that this saves someone some time.