configs: Enable Renesas XHCI driver

[nbuchwitz]

Renesas UPD720201/-202 is a popular alternative to the VL805 USB3 phy used in many CM4 based products.

Commit 25f51b7 ("xhci-pci: Make xhci-pci-renesas a proper modular driver") reworked the Renesas XHCI driver, resulting in CONFIG_USB_XHCI_PCI_RENESAS no longer being implicitly enabled.

Explicitly add it to the defconfig to restore USB3 functionality.

[nbuchwitz]

There might be a better way I will try to upstream, but for the moment this is the easiest way to restore usb on affected devices.

For us it isn't such a big deal as we can patch it downstream in our tree, but devices from vendors which rely on pure raspberry pi kernel (like onlogic and others) will break with 6.12

[P33M]

If it was implicitly enabled before, shouldn't it be a builtin (=y)? Booting from a root filesystem connected by one of these would otherwise require every distro to package an initramfs.

[6by9]

Gut feel is that the Kconfig for USB_XHCI_PCI_RENESAS should set

default USB_XHCI_PCI

so that behaviour matches as before.
Upstream seem to vary as to whether having to change Kconfig options is considered a regression or not.

[nbuchwitz]

Imho the complete switch to the renesas driver is pointless for (real) use cases where an external eeprom is attached to the phy holding the firmware. With the external firmware the phy works with the standard xhci-pci driver and does not need the firmware loading boiler plate. It also wont issue the warning message about the missing firmware file, which might confuse users.

I will try to convince upstream that the device ids are only added to pci_device_id pci_ids_reject[] if CONFIG_USB_XHCI_PCI_RENESAS is not set. This will basically restore the old behavior and also enables use cases where the quirky driver is needed (eg. no external eeprom attached). But for now it wont work without enabling CONFIG_USB_XHCI_PCI_RENESAS

[nbuchwitz]

If it was implicitly enabled before, shouldn't it be a builtin (=y)? Booting from a root filesystem connected by one of these would otherwise require every distro to package an initramfs.

You're right. One more reason to keep it simple with just xhci-pci and only enable the other drivers for the (rare) edge cases.

[pelwell]

Just catching up here... If CONFIG_USB_XHCI_PCI_RENESAS was previously implicitly enabled then one would expect to find it in the .config file after the _defconfig was applied. I can't find a combination of our kernel and our defconfig where CONFIG_USB_XHCI_PCI_RENESAS=y (or =m) - what have I missed?

[pelwell]

(I'm happy to add the necessary defconfig values, although built-in support for all the PCI Ethernet devices out there would get painful - that's what initramfs is for.

[nbuchwitz]

Just catching up here... If CONFIG_USB_XHCI_PCI_RENESAS was previously implicitly enabled then one would expect to find it in the .config file after the _defconfig was applied. I can't find a combination of our kernel and our defconfig where CONFIG_USB_XHCI_PCI_RENESAS=y (or =m) - what have I missed?

The commit message is messed up, so let me rephrase it:

In the past the Renesas USB controller was directly supported by the xhci-pci driver. Unfortunately it called into the renesas driver if it was enabled. To fix this and split the dependencies between both driver Ben Hutchings refactored the driver in [1] and blacklisted the renesas vendor / product ids in xhci-pci. This broke support for the renesas phy when CONFIG_USB_XHCI_PCI_RENESAS is not enabled. So imho our best option without it getting fixed mainline is to enable the special driver.

[1] 25f51b7

[pelwell]

Thanks, that's much clearer.