Thread (9 messages) flat view 9 messages, 3 authors, 19d ago

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

From: Marek Vasut <hidden>
Date: 2026-08-28 18:47:57
Also in: linux-devicetree, linux-usb, lkml

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

Hello Fabrice,
quoted
quoted
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@foss.st.com/
What is the difference between this driver and the ^ driver ?
Hello Marek,

That includes the TCCP I2C driver (and an example on ST boards).
quoted
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) ?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help