From: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
To: Marek Vasut <marex@nabladev.com>, <linux-usb@vger.kernel.org>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>,
Conor Dooley <conor+dt@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
"Rob Herring" <robh@kernel.org>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
<devicetree@vger.kernel.org>, <kernel@dh-electronics.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>
Subject: Re: [PATCH 1/4] dt-bindings: usb: Document ST UCPD
Date: Wed, 26 Aug 2026 15:24:36 +0200 [thread overview]
Message-ID: <42bb4c3c-1dbd-4902-9765-01687b74cb39@foss.st.com> (raw)
In-Reply-To: <225f1704-399d-47d0-8bca-73a27a59bbd4@nabladev.com>
On 8/22/26 06:51, Marek Vasut wrote:
> On 8/21/26 6:27 PM, Fabrice Gasnier wrote:
>> On 8/19/26 18:33, Marek Vasut wrote:
>>> Document ST UCPD Type-C block. The UCPD integrates the physical
>>> layer of the Power Delivery (PD), with CC signaling method, for
>>> operation with Type-C cables. Vbus and Vconn control is performed
>>> using an external chip, usually ST TCPP01/TCPP02/TCPP03 or similar.
>>
>> Hi Marek, All,
>>
>> 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.
I wanted to be transparent, so the correct level of APIs gets used.
You propose to turn the TCPP into a GPIO chip ?
That seems smart, at least for the CC lines switches.
What about Vbus and Vconn, it could also fit regulator API ?
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
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 ?
Best Regards,
Fabrice
next prev parent reply other threads:[~2026-08-26 13:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 16:33 [PATCH 1/4] dt-bindings: usb: Document ST UCPD Marek Vasut
2026-08-19 16:33 ` [PATCH 2/4] usb: typec: ucpd: Add ST UCPD driver Marek Vasut
2026-08-19 16:47 ` sashiko-bot
2026-08-19 16:33 ` [PATCH 3/4] arm64: dts: st: Add UCPD node on stm32mp231 Marek Vasut
2026-08-19 16:42 ` sashiko-bot
2026-08-19 16:33 ` [PATCH 4/4] arm64: dts: st: Add UCPD node on stm32mp251 Marek Vasut
2026-08-19 16:44 ` [PATCH 1/4] dt-bindings: usb: Document ST UCPD sashiko-bot
2026-08-21 16:27 ` Fabrice Gasnier
2026-08-22 4:51 ` Marek Vasut
2026-08-26 13:24 ` Fabrice Gasnier [this message]
2026-08-27 9:39 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42bb4c3c-1dbd-4902-9765-01687b74cb39@foss.st.com \
--to=fabrice.gasnier@foss.st.com \
--cc=alexandre.torgue@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=kernel@dh-electronics.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-usb@vger.kernel.org \
--cc=marex@nabladev.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.