| Message ID | 20231113221528.749481-2-dmitry.baryshkov@linaro.org |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | dt-bindings: connector: usb: provide bindings for altmodes | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
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 > >
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: + 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>;
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(+)