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) ?