From: Amit Sunil Dhamne <amitsd@google.com>
To: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Badhri Jagan Sridharan <badhri@google.com>,
Sebastian Reichel <sre@kernel.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@kernel.org>,
Kyle Tso <kyletso@google.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, linux-pm@vger.kernel.org,
tudor.ambarus@linaro.org, andre.draszik@linaro.org,
peter.griffin@linaro.org
Subject: Re: [PATCH v2 1/5] dt-bindings: connector: extend ports property to model power connections
Date: Wed, 28 May 2025 11:42:24 -0700 [thread overview]
Message-ID: <9376817c-30f1-4ca1-afde-60ebdfd93f53@google.com> (raw)
In-Reply-To: <b4a22161-8cab-4d76-a4b0-4bfd0d79cdc1@google.com>
Hi,
On 5/20/25 1:10 PM, 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@google.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
I wanted to follow up on my previous responses. Please let me know if
you have any further questions or concerns.
Thanks,
Amit
>
>> Rob
next prev parent reply other threads:[~2025-05-28 18:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 1:00 [PATCH v2 0/5] Add support for Battery Status & Battery Caps AMS in TCPM Amit Sunil Dhamne
2025-05-08 1:00 ` Amit Sunil Dhamne via B4 Relay
2025-05-08 1:00 ` [PATCH v2 1/5] dt-bindings: connector: extend ports property to model power connections Amit Sunil Dhamne
2025-05-08 1:00 ` Amit Sunil Dhamne via B4 Relay
2025-05-08 2:08 ` Rob Herring (Arm)
2025-05-13 5:10 ` Amit Sunil Dhamne
2025-05-14 19:42 ` Rob Herring
2025-05-20 20:10 ` Amit Sunil Dhamne
2025-05-28 18:42 ` Amit Sunil Dhamne [this message]
2025-06-23 22:08 ` Sebastian Reichel
2025-07-08 20:55 ` Amit Sunil Dhamne
2026-01-29 21:50 ` Amit Sunil Dhamne
2025-05-08 1:00 ` [PATCH v2 2/5] power: supply: core: add helper to get power supply given a fwnode Amit Sunil Dhamne
2025-05-08 1:00 ` Amit Sunil Dhamne via B4 Relay
2025-06-23 21:21 ` Sebastian Reichel
2025-07-08 0:53 ` Amit Sunil Dhamne
2025-05-08 1:00 ` [PATCH v2 3/5] usb: typec: tcpm: Add support for Battery Status response message Amit Sunil Dhamne
2025-05-08 1:00 ` Amit Sunil Dhamne via B4 Relay
2025-06-23 21:27 ` Sebastian Reichel
2025-07-08 0:55 ` Amit Sunil Dhamne
2025-05-08 1:00 ` [PATCH v2 4/5] power: supply: core: add vendor and product id properties Amit Sunil Dhamne
2025-05-08 1:00 ` Amit Sunil Dhamne via B4 Relay
2025-06-23 21:44 ` Sebastian Reichel
2025-07-08 1:05 ` Amit Sunil Dhamne
2025-05-08 1:00 ` [PATCH v2 5/5] usb: typec: tcpm: Add support for Battery Cap response message Amit Sunil Dhamne
2025-05-08 1:00 ` Amit Sunil Dhamne via B4 Relay
2025-06-23 21:51 ` Sebastian Reichel
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=9376817c-30f1-4ca1-afde-60ebdfd93f53@google.com \
--to=amitsd@google.com \
--cc=andre.draszik@linaro.org \
--cc=badhri@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=krzk+dt@kernel.org \
--cc=kyletso@google.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=peter.griffin@linaro.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sre@kernel.org \
--cc=tudor.ambarus@linaro.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 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.