Re: [PATCH v2 1/1] dt-bindings: connector: Add role‑switch provider phandle

[Dmitry Baryshkov]

On Thu, 26 Mar 2026 at 03:49, Elson Serrao
<elson.serrao@xxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 3/24/2026 10:57 AM, Dmitry Baryshkov wrote:
> > On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> > <elson.serrao@xxxxxxxxxxxxxxxx> wrote:
> >>
> >> Add an optional consumer→provider phandle on USB connectors to reference
> >> the USB role-switch provider when no direct graph link exists. The DRD
> >> controller remains the provider via its 'usb-role-switch' property.
> >>
> >> Signed-off-by: Elson Serrao <elson.serrao@xxxxxxxxxxxxxxxx>
> >> ---
> >>  .../devicetree/bindings/connector/usb-connector.yaml      | 8 ++++++++
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> index 11e40d225b9f..ef8d3d26461b 100644
> >> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> @@ -95,6 +95,14 @@ properties:
> >>        - device
> >>        - dual
> >>
> >> +  usb-role-switch:
> >> +    $ref: /schemas/types.yaml#/definitions/phandle
> >> +    description:
> >> +      A phandle to the USB role-switch provider. The provider is typically
> >> +      a dual-role (DRD) USB controller node that declares the boolean
> >> +      'usb-role-switch' property. Use this when the connector is not
> >> +      directly linked to the provider in the OF graph.
> >
> > This kind of properties has already been discussed at least twice:
> > - First for referencing the DisplayPort controller from the AltMode
> > node (USB-C connector)
> > - Then for referencing the USB-C muxes / orientation switches when
> > there is an intermediate chip
> >
> > In both cases the agreement was to not add such out of band handle
> > references. The solution was on the software side, letting drivers for
> > the intermediate devices in the OF graph translate and resend
> > necessary events.
> >
> > Previously we didn't have such an issue for the usb-role-switch,
> > because there always have been a direct link between the USB connector
> > (be it gpio-usb-b-connector or usb-c-connector) and the USB controller
> > (implementing usb-role-switch). As with the EUD this is no longer a
> > case, my suggestion would be to follow prior art and let EUD receive,
> > interpret and resend usb-role-switch events.
> >
>
> In this topology, the EUD hardware spans more than one independent
> role-switch relationship, as a single EUD node is the direct neighbor of
> multiple connectors. This introduces additional considerations around
> role-switch discovery.
>
> One practical consideration if the EUD registers multiple role-switch
> instances is that fwnode_usb_role_switch_get() ( which relies on
> class_find_device_by_fwnode API), assumes a unique firmware node per
> role-switch instance. If multiple role-switch instances are registered
> against the same firmware node (the EUD fwnode), the lookup will return
> only the first registered instance, making it difficult for a connector to
> reliably bind to its intended role-switch provider.
>
> Supporting multiple role-switch instances in this model would therefore
> require extending the lookup mechanism to allow additional disambiguation
> (for example, associating role-switch instances with connector context).
>
> I want to make sure I clearly understand the intended modeling and whether
> these USB role-switch framework implications are considered acceptable.

As far as I can see, you can register two usb-role-switches, one per
the EUD path. then the connector will still be able to discover
correct switch by following the chain from the connector. On the other
hand, the EUD driver can use fwnode_usb_role_switch_get() passing the
path's fwnode and find the next role-switch connected to the each of
the EUD ports / paths.

Here I am assuming that EUD device structured in a way like:

eud {
  compatible = "qcom,eud";

  path@0 {
    ports {
      port@0 {
        endpoint {
          remote-endpoint = <&usb_con_0_hs>;
        };
      };
      port@1 {
        endpoint {
          remote-endpoint = <&usb0_hs>;
        };
      };
    };
  };

  path@1 {
    ports {
      port@0 {
        endpoint {
          remote-endpoint = <&usb_con_1_hs>;
        };
      };
      port@1 {
        endpoint {
          remote-endpoint = <&usb1_hs>;
        };
      };
    };
  };

};

-- 
With best wishes
Dmitry