Re: [PATCH v2 1/5] dt-bindings: connector: extend ports property to model power connections

[Amit Sunil Dhamne]

Hi Sebastian,

I hope you're doing well!

On 6/23/25 3:08 PM, Sebastian Reichel wrote:
> Hi,
>
> On Tue, May 20, 2025 at 01:10:25PM -0700, Amit Sunil Dhamne wrote:
> > Hi Rob,
> >
> > Thanks for your response!
> >
> > On 5/14/25 12:42 PM, Rob Herring wrote:
> > > On Wed, May 07, 2025 at 06:00:22PM -0700, Amit Sunil Dhamne wrote:
> > > > Extend ports property to model power lines going between connector to
> > > > charger or battery/batteries. As an example, connector VBUS can supply
> > > > power in & out of the battery for a DRP.
> > > >
> > > > Additionally, add ports property to maxim,max33359 controller example.
> > > >
> > > > Signed-off-by: Amit Sunil Dhamne<amitsd@xxxxxxxxxx>
> > > > ---
> > > >   .../bindings/connector/usb-connector.yaml          | 20 +++++++++++------
> > > >   .../devicetree/bindings/usb/maxim,max33359.yaml    | 25 ++++++++++++++++++++++
> > > >   2 files changed, 38 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > index 11e40d225b9f3a0d0aeea7bf764f1c00a719d615..706094f890026d324e6ece8b0c1e831d04d51eb7 100644
> > > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > @@ -181,16 +181,16 @@ properties:
> > > >   
> > > >     port:
> > > >       $ref: /schemas/graph.yaml#/properties/port
> > > > -    description: OF graph bindings modeling a data bus to the connector, e.g.
> > > > -      there is a single High Speed (HS) port present in this connector. If there
> > > > -      is more than one bus (several port, with 'reg' property), they can be grouped
> > > > -      under 'ports'.
> > > > +    description: OF graph binding to model a logical connection between a device
> > > > +      and connector. This connection may represent a data bus or power line. For
> > > > +      e.g. a High Speed (HS) data port present in this connector or VBUS line.
> > > > +      If there is more than one connection (several port, with 'reg' property),
> > > > +      they can be grouped under 'ports'.
> > > 'port' and 'port@0' are equivalent. So you can't be changing its
> > > definition.
> > Noted!
> >
> >
> > > I'm not sure showing a power connection with the graph is the right
> > > approach.
> > I want to provide some more context and rationale behind using this design.
> >
> >  From a hardware perspective:
> >
> > The max77759/max33359 IC has Type-C port controller, charger, fuel gauge
> > (FG) ICs. The Vbus from the connector goes to/from the TCPC and connects
> > with the charger IP via circuitry & from there on to the battery. The FG
> > is connected to the battery in parallel. As it can be seen that while
> > these IPs are interconnected, there's no direct connection of the fuel
> > gauge & the connector.
> >
> > For this feature, I am interested in getting the reference to the FG. As
> > per graph description: "...These common bindings do not contain any
> > information about the direction or type of the connections, they just
> > map their existence." This works for my case because I just want the
> > connector to be aware of the Fuel gauge device without imposing a
> > specific directionality in terms of power supplier/supplied. This is
> > also the reason why I didn't use
> > "/schemas/power/supply/power-supply.yaml#power-supplies" binding.
> >
> > > We have a binding for that already with the regulator binding.
> > I haven't explored the option of using regulator bindings. But in my
> > case I am interested in fuel gauge and unfortunately, they're modeled as
> > power_supply devices.
>  From hardware point of view there is no direct connection at all
> between the fuel gauge and the connector. The usual hardware
> connection is
>
> connector -> charger -> battery
>
> With the charger potentially supporting reverse operation to provide
> energy from the battery to the connector (with "battery" I assume
> a "smart" battery, so the raw cells and some kind of fuel gauge).
>
> Thus the following example should properly document the hardware
> connections:
>
> ---------------------------------------
> typec-connector {
>      /* ... */
> };
>
> charger {
>      /* ... */
>      power-supplies = <&connector>;
> };
>
> fuel-gauge {
>      /* ... */
>      power-supplies = <&charger>;
> };
> ---------------------------------------
>
> It means instead of the direct graph lookup for the fuel gauge,
> you would need a function walking through the graph build by the
> power-supplies phandles. But it also means that the DT properly
> describes the hardware instead of adding random graph connections.

I would like to revisit this thread.

I have tested the hierarchical power-supplies approach you suggested 
while working with the charger [1] and fuel gauge [2] drivers currently 
being upstreamed. Unfortunately, this approach introduces two blockers 
for USB PD compliance (with the first one being the most critical and 
relevant to bindings):


Issue #1: Deterministic Probe Ordering and Feature Deferral
Early in the boot cycle, the TCPM is the first to probe (based on the 
power-supplies hierarchy). Without a direct phandle in the connector 
node to the fg devices, the TCPM is "blind" to the system's battery 
topology. If a power adapter initiates a Battery Status/Battery Caps AMS 
before the FG driver has registered its power_supply object, the TCPM 
response indicates no batteries as the TCPM doesn't have a complete view 
of the FGs in the system at that time.

Issue #2: Violating Sender Response Timeout
Iteratively traversing the power supply tree to resolve the hierarchy 
(Connector -> Charger -> FG) is computationally expensive in the context 
of USB PD. In testing, this traversal frequently exceeds the Sender 
Response Timeout (27-33 ms). While caching psy references helps 
subsequent requests, the failure of the initial request triggers a soft 
reset by the adapter. This results in an inconsistent and unreliable 
charging experience upon first plug-in.

While I have thought about how we can mitigate these issues if we still 
must have to go with the above approach, I strongly believe that TCPM 
having actual references to the fg/charger phandles seems to be the 
appropriate way here. Are there alternative methods you would suggest 
that allow the TCPM to (1) know a priori that an FG device exists to 
manage deferral, and (2) meet the <30 ms response window without direct 
phandles?


[1]
https://lore.kernel.org/all/20260121-max77759-charger-v4-0-694234c8ded1@xxxxxxxxxx/

[2]
https://lore.kernel.org/all/20250915-b4-gs101_max77759_fg-v6-0-31d08581500f@xxxxxxxxxxxx/


Thanks,

Amit

> Greetings,
>
> -- Sebastian
>
> > > Perhaps the connector needs to be a supply. It's already using that
> > > binding in the supplying power to the connector case.
> > Want to clarify, in this case you mean
> > /schemas/regulator/regulator.yaml#*-supply$ right?
> >
> > Adding to my response above, the reason I don't want to impose a
> > directionality in terms of supplier/supplied is that in case of USB Dual
> > Role Port they're dynamic i.e., when USB is source, the power is
> > supplied out of the battery (battery/FG will be supplier) and in case
> > USB is sink, battery is supplied power. Whether the connector port is in
> > source or sink role is determined on a connection to connection basis.
> > Also, the knowledge of the supply direction is of no consequence for
> > this feature.
> >
> >
> > Please let me know what you think.
> >
> > Thanks,
> >
> > Amit
> >
> >
> > > Rob