Message-ID: <b4a22161-8cab-4d76-a4b0-4bfd0d79cdc1@google.com>
Date: Tue, 20 May 2025 13:10:25 -0700
From: Amit Sunil Dhamne <amitsd@...gle.com>
To: Rob Herring <robh@...nel.org>
Cc: Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Badhri Jagan Sridharan <badhri@...gle.com>,
 Sebastian Reichel <sre@...nel.org>,
 Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <len.brown@...el.com>,
 Pavel Machek <pavel@...nel.org>, Kyle Tso <kyletso@...gle.com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 1/5] dt-bindings: connector: extend ports property to
 model power connections

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@...gle.com>
>> ---
>>  .../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.


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

Powered by blists - more mailing lists