From: Amit Sunil Dhamne <amitsd@google.com>
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'.
ports:
$ref: /schemas/graph.yaml#/properties/ports
- description: OF graph bindings modeling any data bus to the connector
- unless the bus is between parent node and the connector. Since a single
- connector can have multiple data buses every bus has an assigned OF graph
+ description: OF graph bindings to model multiple "port". Since a connector
+ may have multiple logical connections each one has an assigned OF graph
port number as described below.
properties:
@@ -207,6 +207,12 @@ properties:
description: Sideband Use (SBU), present in USB-C. This describes the
alternate mode connection of which SBU is a part.
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: VBUS/VCHGIN present in USB-C connector to model power line
+ going in and/or out of the charger/battery. If there are multiple
+ batteries then this port should contain those many endpoints.
+
required:
- port@0
diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
index 3de4dc40b79192b60443421b557bd2fb18683bf7..730d5c1cc9ddf1ddeff055c00ee172745297633d 100644
--- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
+++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
@@ -75,6 +75,31 @@ examples:
PDO_FIXED(9000, 2000, 0)>;
sink-bc12-completion-time-ms = <500>;
pd-revision = /bits/ 8 <0x03 0x01 0x01 0x08>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_orien_sw: endpoint {
+ remote-endpoint = <&usbdrd31_phy_orien_switch>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_role_sw: endpoint {
+ remote-endpoint = <&usbdrd31_dwc3_role_switch>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ vbus_batt: endpoint {
+ remote-endpoint = <&max17201_fg>;
+ };
+ };
+ };
};
};
};
--
2.49.0.987.g0cc8ee98dc-googOn 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. I'm not sure showing a power connection with the graph is the right approach. We have a binding for that already with the regulator binding. Perhaps the connector needs to be a supply. It's already using that binding in the supplying power to the connector case. Rob
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 > Rob
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@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.
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.
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
>
Hi Sebastian,
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@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.
> 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>;
> };
> ---------------------------------------
The hardware description is unambiguous for single power role Type-C
devices such as Sink only & Source only device (demonstrated by
inverting the relationship given in the above example).
For DRP power role, the above relationship feels semantically incorrect
because the illustrated relationship would not hold if the Type-C device
is Source for a given Type-C connection lifecycle.
I'll add a note somewhere mentioning that for DRP, the relationship can
be demonstrated either like a sink or source to make it less ambiguous.
> 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.
Okay, will follow this approach.
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
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
On Wed, 07 May 2025 18:00:22 -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(-) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250507-batt_ops-v2-1-8d06130bffe6@google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Hi Rob, On 5/7/25 7:08 PM, Rob Herring (Arm) wrote: > On Wed, 07 May 2025 18:00:22 -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(-) >> > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: I ran this and didn't see any errors on my side. > dtschema/dtc warnings/errors: > > > doc reference errors (make refcheckdocs): > > See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250507-batt_ops-v2-1-8d06130bffe6@google.com Even the build logs don't show any error log. > > The base for the series is generally the latest rc1. A different dependency > should be noted in *this* patch. My patchset is based on v6.14-rc6 and I tested it on that. > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit after running the above command yourself. Note > that DT_SCHEMA_FILES can be set to your schema file to speed up checking > your schema. However, it must be unset to test all examples with your schema. > I did all of the above but make dt_binding_check still passes. (.venv) amitsd@amitsd-gti:~/linaro-p6-image/src/linux$ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/connector/usb-connector.yaml SCHEMA Documentation/devicetree/bindings/processed-schema.json /usr/local/google/home/amitsd/linaro-p6-image/src/linux/Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing type definition ^ This is not newly introduced jfyi. CHKDT ./Documentation/devicetree/bindings LINT ./Documentation/devicetree/bindings DTEX Documentation/devicetree/bindings/connector/usb-connector.example.dts DTC [C] Documentation/devicetree/bindings/connector/usb-connector.example.dtb (.venv) amitsd@amitsd-gti:~/linaro-p6-image/src/linux$ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/usb/maxim,max33359.yaml CHKDT ./Documentation/devicetree/bindings LINT ./Documentation/devicetree/bindings DTEX Documentation/devicetree/bindings/usb/maxim,max33359.example.dts DTC [C] Documentation/devicetree/bindings/usb/maxim,max33359.example.dtb Please can you advise on what I may be missing? Thanks, Amit
© 2016 - 2025 Red Hat, Inc.