[v2,1/3] dt-bindings: connector: usb: add altmodes description
Commit Message
Add description of the USB-C AltModes supported on the particular USB-C
connector. This is required for devices like Qualcomm Robotics RB5,
which have no other way to express alternative modes supported by the
hardware platform.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../bindings/connector/usb-connector.yaml | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
Comments
On Tue, Nov 14, 2023 at 12:13:27AM +0200, Dmitry Baryshkov wrote:
> Add description of the USB-C AltModes supported on the particular USB-C
> connector. This is required for devices like Qualcomm Robotics RB5,
> which have no other way to express alternative modes supported by the
> hardware platform.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> .../bindings/connector/usb-connector.yaml | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 7c8a3e8430d3..1bd51b86906f 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -14,6 +14,31 @@ description:
> of a USB interface controller or a separate node when it is attached to both
> MUX and USB interface controller.
>
> +$defs:
I fail to see why we need to use $defs here.
> + altmode-desc:
> + type: object
> + description:
> + A single USB-C Alternative Mode as supported by the USB-C connector logic.
> + properties:
> + svid:
> + $ref: /schemas/types.yaml#/definitions/uint16
> + description: Unique value assigned by USB-IF to the Vendor / AltMode.
> + vdo:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: VDO returned by Discover Modes USB PD command.
What's VDO?
These names are a bit short. Types for property names are global
(mostly). Though this patch doesn't make it clear these were already in
use.
> +
> + altmodes-list:
> + type: object
> + description: List of Alternative Modes supported by the schematics on the
> + particular device. This is only necessary if there are no other means to
> + discover supported alternative modes (e.g. through the UCSI firmware
> + interface).
> +
> + patternProperties:
> + "^[a-z][a-z0-9]*$":
Are there standard id's and names? Should we define some so we don't get
'dp', 'displayport', etc.
> + $ref: "#/$defs/altmode-desc"
> + unevaluatedProperties: false
> +
> properties:
> compatible:
> oneOf:
> @@ -171,6 +196,10 @@ properties:
> offer the power, Capability Mismatch is set. Required for power sink and
> power dual role.
>
> + altmodes:
> + $ref: "#/$defs/altmodes-list"
> + unevaluatedProperties: false
> +
> port:
> $ref: /schemas/graph.yaml#/properties/port
> description: OF graph bindings modeling a data bus to the connector, e.g.
> @@ -289,6 +318,13 @@ examples:
> compatible = "usb-c-connector";
> label = "USB-C";
>
> + altmodes {
> + displayport {
> + svid = /bits/ 16 <0xff01>;
> + vdo = <0x00001c46>;
> + };
> + };
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.42.0
>
On Thu, 16 Nov 2023 at 20:38, Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Nov 14, 2023 at 12:13:27AM +0200, Dmitry Baryshkov wrote:
> > Add description of the USB-C AltModes supported on the particular USB-C
> > connector. This is required for devices like Qualcomm Robotics RB5,
> > which have no other way to express alternative modes supported by the
> > hardware platform.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> > .../bindings/connector/usb-connector.yaml | 36 +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > index 7c8a3e8430d3..1bd51b86906f 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > @@ -14,6 +14,31 @@ description:
> > of a USB interface controller or a separate node when it is attached to both
> > MUX and USB interface controller.
> >
> > +$defs:
>
> I fail to see why we need to use $defs here.
I had an idea of defining a schema piece that can later be referenced
from any other place. If you think this is an overkill, I can drop
them.
>
> > + altmode-desc:
> > + type: object
> > + description:
> > + A single USB-C Alternative Mode as supported by the USB-C connector logic.
> > + properties:
> > + svid:
> > + $ref: /schemas/types.yaml#/definitions/uint16
> > + description: Unique value assigned by USB-IF to the Vendor / AltMode.
> > + vdo:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: VDO returned by Discover Modes USB PD command.
>
> What's VDO?
Ack, I'll expand it in v3
>
> These names are a bit short. Types for property names are global
> (mostly). Though this patch doesn't make it clear these were already in
> use.
>
> > +
> > + altmodes-list:
> > + type: object
> > + description: List of Alternative Modes supported by the schematics on the
> > + particular device. This is only necessary if there are no other means to
> > + discover supported alternative modes (e.g. through the UCSI firmware
> > + interface).
> > +
> > + patternProperties:
> > + "^[a-z][a-z0-9]*$":
>
> Are there standard id's and names? Should we define some so we don't get
> 'dp', 'displayport', etc.
Indeed it might be better to enumerate them via string enumeration.
>
>
> > + $ref: "#/$defs/altmode-desc"
> > + unevaluatedProperties: false
> > +
> > properties:
> > compatible:
> > oneOf:
> > @@ -171,6 +196,10 @@ properties:
> > offer the power, Capability Mismatch is set. Required for power sink and
> > power dual role.
> >
> > + altmodes:
> > + $ref: "#/$defs/altmodes-list"
> > + unevaluatedProperties: false
> > +
> > port:
> > $ref: /schemas/graph.yaml#/properties/port
> > description: OF graph bindings modeling a data bus to the connector, e.g.
> > @@ -289,6 +318,13 @@ examples:
> > compatible = "usb-c-connector";
> > label = "USB-C";
> >
> > + altmodes {
> > + displayport {
> > + svid = /bits/ 16 <0xff01>;
> > + vdo = <0x00001c46>;
> > + };
> > + };
> > +
> > ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > --
> > 2.42.0
> >
@@ -14,6 +14,31 @@ description:
of a USB interface controller or a separate node when it is attached to both
MUX and USB interface controller.
+$defs:
+ altmode-desc:
+ type: object
+ description:
+ A single USB-C Alternative Mode as supported by the USB-C connector logic.
+ properties:
+ svid:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description: Unique value assigned by USB-IF to the Vendor / AltMode.
+ vdo:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: VDO returned by Discover Modes USB PD command.
+
+ altmodes-list:
+ type: object
+ description: List of Alternative Modes supported by the schematics on the
+ particular device. This is only necessary if there are no other means to
+ discover supported alternative modes (e.g. through the UCSI firmware
+ interface).
+
+ patternProperties:
+ "^[a-z][a-z0-9]*$":
+ $ref: "#/$defs/altmode-desc"
+ unevaluatedProperties: false
+
properties:
compatible:
oneOf:
@@ -171,6 +196,10 @@ properties:
offer the power, Capability Mismatch is set. Required for power sink and
power dual role.
+ altmodes:
+ $ref: "#/$defs/altmodes-list"
+ unevaluatedProperties: false
+
port:
$ref: /schemas/graph.yaml#/properties/port
description: OF graph bindings modeling a data bus to the connector, e.g.
@@ -289,6 +318,13 @@ examples:
compatible = "usb-c-connector";
label = "USB-C";
+ altmodes {
+ displayport {
+ svid = /bits/ 16 <0xff01>;
+ vdo = <0x00001c46>;
+ };
+ };
+
ports {
#address-cells = <1>;
#size-cells = <0>;