[minetest2048]

Related problem is single-board computers that relies on USB-PD for power. USB-PD sources requires the sink to do power delivery negotiation within 5 seconds, or it will cut its power or do funny things. Because USB-PD negotiation is handled in Linux, by the time Linux boots it will be too late, and power supply will cut the power, so it will be stuck in a boot loop: https://www.spinics.net/lists/linux-usb/msg239175.html

They way they're trying to solve it is very similar to this article, by doing the USB-PD negotiation during U-boot bootloader stage:

- https://gitlab.collabora.com/hardware-enablement/rockchip-35...

- https://lore.kernel.org/u-boot/20241015152719.88678-1-sebast...

[rickdeckard]

Interesting, thanks for sharing. I missed that evolution of "thin" USB-C controllers which delegate the PD handshake elsewhere.

I don't know yet how I feel about the fact that a driver in the OS is supposed to take this role and tell the power-supply how much power to deliver. Not necessarily a novel security concern, but a potential nightmare from a plain B2C customer service perspective (i.e. a faulty driver causing the system to shut down during boot, fry the Motherboard,...)

[gorkish]

It's not, per-se, a driver doing the PD negotiation in software; it's more that the USB chipset isnt initialized and configured for PD negotiation (or anything else for that matter) until the CPU twiddles its PCI configuration space.

I would have imagined that USB controller chipsets would likely offer some nonvolatile means to set the PD configuration (like jumpers or eeprom) precisely because of this issue. It's surprising to me that such a feature isnt common

[rjsw]

Reading the thread, the behaviour seems to depend on the power supply. I have powered a Pinebook Pro via USB-C with a PinePower PSU, didn't even have a FUSB302 driver in the OS then (am currently adding one).

Other boards don't do USB-PD at all and just rely you using a PSU with a USB-C connector that defaults to 5V, e.g. RPi and Orange pi 5 (RK3588).

[rickdeckard]

For 5V output (like used on the Pinebook) you don't need to negotiate anything over USB-PD, that's the default provided by a USB-C PSU to ensure legacy USB compatibility. Support for higher currents can then be "unlocked" with resistors between the Alt Data-Lines (like a USB-A charger would).

Everything beyond 5V requires a handshake between device and PSU, which ensures that the connected device can actual handle higher power output.

[hypercube33]

It kinda blows my mind that the Ethernet or USB phy doesn't have this stored in some tiny nvram and handle all of the negotiations. What if I have a battery to charge while the device is off such as a laptop? How does Android deal with this when it's not booted? Does the bios handle this stuff?

[wolrah]

> What if I have a battery to charge while the device is off such as a laptop? How does Android deal with this when it's not booted? Does the bios handle this stuff?

In my experience, if the device doesn't have enough power to actually boot it will simply slow charge at the default USB rate.

This can be problematic with devices that immediately try to boot when powered on.

[varjag]

Apple solves this by doing all PD negotiation in hardware.

[nyrikki]

Unless you are very price sensitive, using USB Power Delivery ICs is the norm now for most devices, but PD is different than POE. PD is just loose tolerance resistors on USB.

[dezgeg]

Yecchh, 5000+ lines! USB-PD is truly cursed...