USB PD request makes gadgets not work with some hosts

[jclark]

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.

[jclark]

I should also mention that I tried a wide variety of USB C cables, both with and without eMarkers.

The PSU_MAX_CURRENT workaround works with iPad Pro M4, MacBook Air M3 and the rear (Thunderbolt 4) ports of the Mac mini M4, but not with the front (USB C) ports of the Mac mini M4. This is all with the Pi 5.

Possibly related to #6289

[jclark]

Here's another report confirming that things don't work on the iPad Pro M4 verxion/RaspberryPi#1

[NumberOneGit]

I’m experiencing the same issue with my CM5 and the official IO board. If you take the same properly set up CM5 module and test it on a CM4 board (assuming you have access to one), could you let me know whether that setup works properly? In my case, the CM5 works perfectly on the CM4 boards that I previously used for ethernet gadgets. I currently only have the IO board for CM5 as few (if any?) other options exist.

[jclark]

This problem can't possibly occur with the CM4 IO board, since it uses a 12V barrel connector for power rather than USB PD, and the connector for the dwc2 is MicroUSB which doesn't have the CC lines used for USB PD negotiation.

There's Waveshare PoE board for the CM5. I haven't tried, but it is highly likely to have the same problem.