USB PD request makes gadgets not work with some hosts

Reproduce the failure using /boot/firmware/config.txt, /boot/firmware/cmdline.txt, dwc2 and g_ether, then compare USB PD captures and kernel logs with a working host. Trace the handling of the PD messages after the 5V3A request; done means the USB ethernet gadget enumerates and usb0 reports carrier and link-local connectivity on the affected Apple hosts.

Describe the bug

When connecting a Raspberry Pi 5 (or CM5) to some hosts (recent Apple devices) using a direct USB C cable connection and configuring the Pi as a USB ethernet gadget, the host does not recognize the ethernet gadget. This happens only in cases where the Pi sends a USB PD request to the host. If the EEPROM is configured not to send a USB PD request, then the host does recognize the gadget. The hosts where this happen include

• iPad Pro M4
• Mac mini M4
• MacBook Air M3

Steps to reproduce the behaviour

1. in /boot/firmware/config.txt, add a line dtoverlay=dwc2,dr_mode=peripheral
2. in /boot/firmware/cmdline.txt, append modules-load=dwc2,g_ether
3. add a link-local NM connection: nmcli con add type ethernet ifname usb0 con-name usb0 ipv4.method link-local
4. override the udev rule that makes gadget interfaces unmanaged: touch /etc/udev/rules.d/85-nm-unmanaged.rules
5. use a USB C cable to connect the USB C port on the Pi 5 to one of the hosts listed above

What I see on the Pi:

• the usb0 interface appears
• od -t u4 --endian=big /proc/device-tree/chosen/power/max_current shows 3000mA current has been negotiated
• ethtool usb0 shows no link detected
• NetworkManager does not activate the usb0 connection
• nmcli dev show usb0 shows carrier off

On the host no ethernet gadget shows up in Settings.

What I expect to see on the Pi:

• NetworkManager does activate the usb0 connection
• ethtool usb0 shows link detected
• usb0 gets a link local address

I also expect that the ethernet gadget shows up on the host and that I can ssh into the Pi using ssh raspberrypi.local

If I use rpi-eeprom-config -e to add PSU_MAX_CURRENT=3000, then I see what I expect to see.

Device (s)

Raspberry Pi 5, Raspberry Pi CM5

System

/etc/rpi-issue

Raspberry Pi reference 2024-07-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 48efb5fc5485fafdc9de8ad481eb5c09e1182656, stage4

Firmware

2024/12/19 11:57:13
Copyright (c) 2012 Broadcom
version ccf64a4f (release) (embedded)

Kernel

Linux raspberrypi 6.6.62+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/Linux

Logs

When things work I see

[    2.595364] dwc2 1000480000.usb: bound driver g_ether
[    2.848187] dwc2 1000480000.usb: new device is high-speed
[    2.898746] dwc2 1000480000.usb: new device is high-speed
[    2.920452] dwc2 1000480000.usb: new address 1

When things don't work, I don't see the last three lines.

Additional context

Everything works OK on:

• iPad Mini Gen 7
• iPad 10th Gen

On these, /proc/device-tree/chosen/power/max_current shows a current of 1500mA. Everything also works if I put a USB PD powered hub between the host and the Pi.

I used a USB tester (a POWER-Z KM003C) with Windows software that allows the USB PD messages to be captured. With the iPad Mini, the iPad advertises some PDOs, but the Raspberry Pi never sends any PD requests (presumably because it is offering less than 5V3A). With the iPad Pro, the Raspberry Pi sends a request for 5V3A, which the iPad accepts. The iPad Pro then sends a whole bunch of messages (e.g. Get Sink Cap, Get Source Cap Extended, Get Sink Cap Extended, Get Revision, Get Source Info), which the Pi does not respond to. None of these messages got sent in the iPad Mini case. This suggests that a possible explanation is that the iPad is expecting a more complete USB PD implementation than the Pi provides.