Driver placement for a new STUSB4500 USB-C PD sink controller

Driver placement for a new STUSB4500 USB-C PD sink controller

[Giandomenico Rossi]

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.

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?

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?

Regards,
Giandomenico Rossi
Amel s.r.l.

Re: Driver placement for a new STUSB4500 USB-C PD sink controller

[Ahmad Fatoum]

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?

> 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.

> 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/

Cheers,
Ahmad

> 
> Regards,
> Giandomenico Rossi
> Amel s.r.l.
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: Driver placement for a new STUSB4500 USB-C PD sink controller

[Giandomenico Rossi]

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