From: Giandomenico Rossi <rossi@amelchem.com>
To: barebox <barebox@lists.infradead.org>
Subject: Re: Driver placement for a new STUSB4500 USB-C PD sink controller
Date: Tue, 25 Aug 2026 14:14:38 +0200 [thread overview]
Message-ID: <010a0855cdd5268ab8e47ed5b5e43a7bbfc539f6.camel@amelchem.com> (raw)
In-Reply-To: <2d747fac-3c27-45d1-9f6c-95e8579c75a2@pengutronix.de>
On Tue, 2026-08-25 at 12:08 +0200, Ahmad Fatoum wrote:
> Hello Giandomenico,
>
> On 8/25/26 11:38 AM, Giandomenico Rossi wrote:
> > Hi,
> >
> > I'm writing a Barebox driver for the STMicroelectronics STUSB4500,
> > an
> > autonomous USB Type-C Power Delivery sink controller (I2C).
> > It can trigger a renegotiation, and reports the resulting contract.
> > Target platform is an STM32MP151-based board.
>
> Cool. What information should this driver make available?
1. it configures the sink PDOs defined in the device tree ("sink-
pdos").
2. It also provides a small C API for board code to:
2.a. read the current contract;
2.b. force a renegotiation;
2.c. see the negotiated voltage and current, and separately
whether the source flagged a capability mismatch.
Points (2.c) covers two distinct things.
The capability-mismatch flag which is a PD-protocol flag the chip
reports (the source couldn't fully satisfy the request) and whether the
voltage/current are the ones the board actually wants.
For example, our board requires 20 V, so it isn't enough to know that
"a contract was accepted", since a fallback to 5 V is also a valid,
contract. The board has to look at the actual negotiated voltage.
The API therefore returns the values and the flag, and leaves the
policy to the board.
On top of this, the binding defines an optional boolean property,
st,renegotiate-on-probe. It's meant for users who want to set their
PDOs from the device tree but have no board-specific C file, and would
rather let the driver do the renegotiation itself at probe.
It can be dropped if it doesn't fit barebox's philosophy.
>
> > I'd like to agree on where the files should live, so I don't have
> > to
> > reshuffle everything later.
> >
> > Driver source: at the moment I have the driver under
> > drivers/usb/misc/,
> > but since it's a USB Type-C PD sink controller it might fit better
> > under drivers/usb/typec/ (which Barebox doesn't have yet, so it
> > would
> > mean creating it). Would you prefer that, or somewhere else?
>
> We have had a drivers/usb/typec directory since v2023.07.0.
> If you missed it you may also want to check the basic USB Type-C
> framework that was added there and see how well it fits your driver.
I need holidays!!
Thanks, I'll go through it.
My initial question is whether it fits a part like this: the
STUSB4500 runs the whole PD negotiation autonomously in hardware, but
I'll check how it's structured and follow up.
>
> > DT binding: I've written the binding as a YAML schema
> > (st,stusb4500.yaml), matching the Linux dt-schema format and
> > reusing
> > the common usb-connector.yaml for the connector sub-node.
> > Where should it go in the Barebox tree?
>
> I am unsure why you need a custom schema if there's already one
> upstream? Anyways, barebox-specific schemas are collected in
> Documentation/devicetree/bindings/. Upstream bindings are imported to
> dts/Bindings/
Sorry, I was unclear, by "matching the Linux dt-schema" I meant I
followed the dt-schema format (the YAML meta-schema style), not that
I'm copying an existing upstream schema. There's no STUSB4500 binding
upstream (remember I need holidays, but I am quite sure!), so this is a
new one.
Thanks for the pointer on placement, I'll put it in
Documentation/devicetree/bindings/ since it's barebox-specific.
Regards,
Giandomenico
prev parent reply other threads:[~2026-08-25 12:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 9:38 Giandomenico Rossi
2026-08-25 10:08 ` Ahmad Fatoum
2026-08-25 12:14 ` Giandomenico Rossi [this message]
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=010a0855cdd5268ab8e47ed5b5e43a7bbfc539f6.camel@amelchem.com \
--to=rossi@amelchem.com \
--cc=barebox@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox