Re: [PATCH 1/4] dt-bindings: usb: Document ST UCPD

From: Marek Vasut

Date: Fri Aug 28 2026 - 14:47:51 EST


On 8/26/26 3:24 PM, Fabrice Gasnier wrote:

Hello Fabrice,

I've sent a series for the complete case. Please check and review here:
https://lore.kernel.org/linux-usb/20260821-ucpd-host-fusb340-v7-2-rfc-
v1-0-c5e27cbc0795@xxxxxxxxxxx/

What is the difference between this driver and the ^ driver ?


Hello Marek,

That includes the TCCP I2C driver (and an example on ST boards).

Why is this driver not covering "the complete case" , what is missing
here and not missing there ?

I intended to show a complete case, e.g. UCPD controller driver and
external TCPP I2C protection chip driver. The TCPP is a companion,
complementary, e.g. provider/consumer relationship.

You've pointed some "horribleness" there. I guess you talk about the
straight forward approach e.g. EXPORT_SYMBOL() macros. That's an
on-going work, a prototype. I could have sent as an RFC.

Yes please.

I wanted to be transparent, so the correct level of APIs gets used.

You propose to turn the TCPP into a GPIO chip ?

I think yes, it is after all four flip switches on I2C.

That seems smart, at least for the CC lines switches.
What about Vbus and Vconn, it could also fit regulator API ?

It would, but, aren't those also flip switches ?

It seems to me, that TCPP02/03 can enable/disable Vconn on CC1/CC2 (that sound like two GPIOs), enable/disable gate driver (GPIO?) and enable/disable gate source (GPIO?) .

There are various functions, the bindings should be extensible enough
for later use of additional functions. I'm thinking of:
- Over-current events for Vbus & Vconn
Could be represented as interrupt controller ?
Or could benefit from a regulator notifier (if used) ?
- Vbus sensing

Could extcon cover those ?

My point is that, that can impact the dt-bindings or functionality.
Sending UCPD driver only, without the TCCP binding & driver, I find it
is a bit hard to review or test at my end without having a more complete
view.

I'm not sure which way you'd like to proceed ?
I am wondering whether maybe we should slow down a bit, get USB sorted out and upstream first, and focus on UCPD/TCPP as the second step (not in parallel to USB) ?