On Thu, Jun 23, 2022 at 11:30 AM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > Quoting Prashant Malani (2022-06-22 10:34:30) > > 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. > > Is there an update to the usb-c-connector binding to accept this port > connection? Not at this time. I don't think we should enforce that either. (Type-C data-lines could theoretically be routed through intermediate hardware like retimers/repeaters) > > > + > > + required: > > + - port@0 > > + > > +required: > > + - compatible > > + - ports > > + > > +anyOf: > > + - required: > > + - mode-switch > > + - required: > > + - orientation-switch > > + > > +additionalProperties: true > > + > > +examples: > > + - | > > + drm-bridge { > > + usb-switch { > > + compatible = "typec-switch"; > > I still don't understand the subnode design here. usb-switch as a > container node indicates to me that this is a bus, but in earlier rounds > of this series it was stated this isn't a bus. I am not aware of this as a requirement. Can you please point me to the documentation that states this needs to be the case? > Why doesn't it work to > merge everything inside usb-switch directly into the drm-bridge node? I attempted to explain the rationale in the previous version [1], but using a dedicated sub-node means the driver doesn't haven't to inspect individual ports to determine which of them need switches registered for them. If it sees a `typec-switch`, it registers a mode-switch and/or orientation-switch. IMO it simplifies the hardware device binding too. It also maps with the internal block diagram for these hardware components (for ex. the anx7625 crosspoint switch is a separate sub-block within anx7625). [1] https://lore.kernel.org/linux-usb/CACeCKaeH6qTTdG_huC4yw0xxG8TYEOtfPW3tiVNwYs=P4QVPXg@xxxxxxxxxxxxxx/ > > > + mode-switch; > > + orientation-switch; > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + port@0 { > > + reg = <0>; > > + anx_ep: endpoint { > > + remote-endpoint = <&typec_controller>; > > + }; > > + }; > > + }; > > + };
