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

[Marek Vasut <marex@nabladev.com>]

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