On Wed, Jun 22, 2022 at 05:34:30PM +0000, Prashant Malani wrote: > Introduce a binding which represents a component that can control the > routing of USB Type-C data lines as well as address data line > orientation (based on CC lines' orientation). > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx> > Reviewed-by: Nícolas F. R. A. Prado <nfraprado@xxxxxxxxxxxxx> > Tested-by: Nícolas F. R. A. Prado <nfraprado@xxxxxxxxxxxxx> > Signed-off-by: Prashant Malani <pmalani@xxxxxxxxxxxx> > --- > > Changes since v4: > - Added Reviewed-by tags. > - Patch moved to 1/9 position (since Patch v4 1/7 and 2/7 were > applied to usb-next) > > Changes since v3: > - No changes. > > Changes since v2: > - Added Reviewed-by and Tested-by tags. > > Changes since v1: > - Removed "items" from compatible. > - Fixed indentation in example. > > .../devicetree/bindings/usb/typec-switch.yaml | 74 +++++++++++++++++++ > 1 file changed, 74 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/typec-switch.yaml > > diff --git a/Documentation/devicetree/bindings/usb/typec-switch.yaml b/Documentation/devicetree/bindings/usb/typec-switch.yaml > new file mode 100644 > index 000000000000..78b0190c8543 > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/typec-switch.yaml > @@ -0,0 +1,74 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/usb/typec-switch.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: USB Type-C Switch > + > +maintainers: > + - Prashant Malani <pmalani@xxxxxxxxxxxx> > + > +description: > + A USB Type-C switch represents a component which routes USB Type-C data > + lines to various protocol host controllers (e.g USB, VESA DisplayPort, > + Thunderbolt etc.) depending on which mode the Type-C port, port partner > + and cable are operating in. It can also modify lane routing based on > + the orientation of a connected Type-C peripheral. > + > +properties: > + compatible: > + const: typec-switch > + > + mode-switch: > + type: boolean > + description: Specify that this switch can handle alternate mode switching. > + > + orientation-switch: > + type: boolean > + description: Specify that this switch can handle orientation switching. > + > + ports: > + $ref: /schemas/graph.yaml#/properties/ports > + description: OF graph binding modelling data lines to the Type-C switch. > + > + properties: > + port@0: > + $ref: /schemas/graph.yaml#/properties/port > + description: Link between the switch and a Type-C connector. > + > + required: > + - port@0 > + > +required: > + - compatible > + - ports > + > +anyOf: > + - required: > + - mode-switch > + - required: > + - orientation-switch > + > +additionalProperties: true > + > +examples: > + - | > + drm-bridge { > + usb-switch { > + compatible = "typec-switch"; Unless this child is supposed to represent what the parent output is connected to, this is just wrong as, at least for the it6505 chip, it doesn't know anything about Type-C functionality. The bridge is just a protocol converter AFAICT. If the child node represents what the output is connected to (like a bus), then yes that is a pattern we have used. For example, a panel represented as child node of a display controller. However, that only works for simple cases, and is a pattern we have gotten away from in favor of using the graph binding. I think Stephen and I are pretty much saying the same thing. Rob
