All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.