[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

[jdndnxnd]

Having persistent state between components is a nightmare in embedded world

Nevertheless I'm surprised USB controller initialization is done by the OS instead of the motherboard chipset

[mrheosuper]

it would be the role of embedded controller instead of SOC to handle PD negotiation. But on SBC, EC may not available.