configs: arm64: Make USB_DWC2 built-in

[pelwell]

It has been decided that we should drop DWC_OTG support on the 64-bit kernels. Its raison-d'etre on ARCH=arm is the FIQ FSM, which significantly reduces the overheads of running the hardware in host mode. Unfortunately, upstream Linux uses the DWC2 driver, which has had a lot of attention over the years. In particular, there are a number of situations where DWC_OTG fails where DWC2 works, despite the reduced throughput.

In the ARMv8 kernel, FIQ support was missing, and is now just different in an awkward way. It is possible to use DWC_OTG in the v8 kernel, but only when the FIQ support is disabled, removing its advantage.

It therefore makes sense to transition to using the DWC2 driver in the 64-bit kernels, deprecating DWC_OTG. The first cautious step is to make the DWC2 driver a built-in, so that either driver can be used for booting. Unfortunately this increases the size of the kernel by ~200kB, but the intention is later to demote DWC_OTG to a module or drop it altogether.

[P33M]

There are three ARCH=arm kernels with CONFIG_USB_DWC2=m -

bcm2709_defconfig
bcm2711_defconfig
bcmrpi_defconfig

2709 is the 32-bit "Pi 3" variant
2711 is the 32-and-some-bits LPAE kernel which is effectively deprecated
bcmrpi is the v6 kernel - using dwc2 is somewhat painful on bcm2835. But bcm2835_defconfig (upstream) does define CONFIG_USB_DWC2=y as they've got no other choice.

I'd argue for ARCH=arm bcm2709_defconfig to include dwc2 as built-in, as that removes one vector by which Pi 3 users with "remote" root filesystems can fail to boot.

[timg236]

The ARCH=arm bcm2709_defconfig has dwc_otg built-in.

Are there circumstances where we would recommend dwc2 over dwc_otg on 32-bit platforms, or should we assume that on a 32-bit kernel, dwc_otg should be the default for USB and network boot?

[P33M]

Usually, use of dwc2 on 32-bit platforms is limited to a diagnostic aid to troubleshoot dwc_otg deficiencies, or if you want USB gadget. Very few users want "session" OTG.

[nbuchwitz]

Ack from the customers perspective: we have implemented the same in our downstream tree for all armv8 capable compute modules (eg everything besides first cm). The are some penalties (compatible issues with some weird devices or complex setups). For everything since cm4(s) this has been worked around be enabling the xhci controller by default in our overlays.

Thus removing dwc_otg for armv8 is resonable (and also makes even less sense with the preempt rt, which always requires the osadl patch set). For armv6 / armv7 the dwc_otg still makes sense and improves compatibility

Maybe worth to considering, that dwc2 in host mode is enabled in 32bit devicetrees and xhci for cm4(s). The bootloader does the magic if xhci is enabled in dt since a while now

[P33M]

I was talking about dwc2 - and arguing this should be the sole 32-bit exception

https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/configs/bcm2709_defconfig#L1194

[timg236]

I was talking about dwc2 - and arguing this should be the sole 32-bit exception

https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/configs/bcm2709_defconfig#L1194

My question was whether 32-bit kernels need to build in dwc2 when they already have DWCOTG (probably not). Presumably, to fall into the missing dwc2 module error on 2709 32-bit the user would have to have added the dtoverlay to config.txt and that has never worked.

[nbuchwitz]

32bit kernels would need dwc2 for gadget mode

[pelwell]

Given that 32-bit users wanting gadget support have been managing up to now, making DWC2 built-in for them seems unnecessary, but we certainly won't be removing it.