WIP: STM32 USB Type-C/USB Power Delivery Interface (UCPD)

[timokroeger]

Draft until my hardware for testing arrives.

• [ ] Check for received hard reset in transmit() and receive()
• [ ] Method to send a hard reset
• [ ] Dead-battery resistor disable for other families
• [ ] Testing!

[timokroeger]

hope you don't mind the drive by comments :) had a go at implementing this in the past but got distracted and demotivated by the general cursedness of USB PD and UCPD, so good luck. feel free to pick my brain on this because i've thought a lot about it (some might say too much thinking and not enough coding :D)

Every comment is welcome! You have implemented a lot already, gonna take you code as reference going forward.

[ExplodingWaffle]

some thoughts (some might say overthinking :)) mostly about how dead battery could be handled in the driver I had while writing #2683:

g0 is weird: you need to write a strobe bit in SYSCFG every time you want the CC pin configuation to be applied. don't think this is a big issue but worth keeping in mind.

according to the non-g0 RM: you should initialise UCPD before disabling DB. makes sense. (wonder if this means DB takes precedence over any other config?)

g0 only (reserved on others) has DBATTEN bit in UCPD CR: worth noting that since it is in CR that means it can only be changed while UCPD is enabled, unlike the DBDIS bit hanging out in PWR on the other chips. that said, I this isn't much of a problem, since the strobe bit works while UCPD is disabled: and if you need to re-enable DB, you can but you need to be careful to do it while UCPD is enabled. this is why I made ucpd_init it's own thing in my PR.

I can't think of many scenarios where you would want to re-enable DB: it isn't needed once UCPD is enabled (since you can set the sink pulldowns just fine with ANAMODE=1 and CCENABLE != 0, which is also required when the DBCC pins aren't wired up). maybe re-enabling DB if you disable UCPD (i.e drop the driver)?? probably keep a flag in the driver struct if DBCC pins are passed in. if they aren't, the user could be using them for something else (this is possible with some care: mentioned in this forum post and the linked AN5225, which I had forgotten about) which we should respect by not enabling them on drop.