On Thu, 16 Nov 2023 at 20:38, Rob Herring <robh@xxxxxxxxxx> 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@xxxxxxxxxx> > > --- > > .../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 > > -- With best wishes Dmitry