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

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

[Elson Serrao]

Hi all,

This patch proposes a generic Devicetree mechanism for a USB connector to
reference the USB role‑switch provider when there is an intermediate,
block between the connector and the controller in the OF graph.

Problem
=======
OF‑graph links are strictly point‑to‑point via remote-endpoint, so a
consumer can only discover its immediate neighbor in the graph. When an
intermediate node sits between the USB connector and the controller, the
connector cannot identify the controller (the role‑switch provider) from
the graph alone.

Example (illustrative only)
===========================
On some Qualcomm SoCs, an Embedded USB Debug (EUD) block sits
electrically between USB‑C connectors and DWC3 controllers. EUD models
HS wiring only .

Below is a simplified diagram of the hardware paths:


				EUD Block
			   +------------------------------+  
			   |                              |
[Conn-0]-->[USB2PHY-0]---->|-------- Path 0 --------------|-->[USBCtrl-0]
			   |                              |  
[Conn-1]-->[USB2PHY-1]---->|-------- Path 1 --------------|-->[USBCtrl-1]
			   |                              |
			   |      +------------------+    |
			   |      |  EUD Debug Hub   |    |
			   |      +------------------+    |
			   +------------------------------+

And the corresponding OF‑graph mapping

# Node: EUD (intermediate; graph-only for HS) (extending [1] to dual port)
EUD (eud@...)
└── ports
    ├─ port@0 (reg = <0>)
    │   └─ endpoint  ── remote-endpoint ──>  USBCtrl-0
    │
    ├─ port@1 (reg = <1>)
    │   └─ endpoint  ── remote-endpoint ──>  Conn-0
    │
    ├─ port@2 (reg = <2>)
    │   └─ endpoint  ── remote-endpoint ──>  USBCtrl-1
    │
    └─ port@3 (reg = <3>)
        └─ endpoint  ── remote-endpoint ──>  Conn-1


# Node: Connector 0
Conn-0: usb-connector
└── port
    └─ port@0: endpoint  --> remote-endpoint -->  EUD:port@1

# Node: USB Controller 0
USBCtrl-0: usb@...  (e.g., DWC3-0)
└── port
    └─ port@0: endpoint  --> remote-endpoint -->  EUD:port@0

# Node: Connector 1
Conn-1: usb-connector
└── port
    └─ port@0: endpoint  --> remote-endpoint -->  EUD:port@3

# Node: USB Controller 1
USBCtrl-1: usb@...  (e.g., DWC3)
└── port
    └─ port@0: endpoint  --> remote-endpoint -->  EUD:port@2


From the OF‑graph structure alone, Conn‑0 cannot determine that
USBCtrl‑0 (and not USBCtrl‑1) is the correct role‑switch provider.

Proposal
========
Add an optional consumer→provider phandle on the connector:

    usb-role-switch = <&controller>;

The provider remains the controller node, which already declares the
boolean 'usb-role-switch;' and registers the role‑switch device.

Thanks,
Elson Serrao

---
Changes in v2:
 - Removed RFC tag following discussion and feedback.
 - Link to v1: https://lore.kernel.org/all/20260223191042.825136-1-elson.serrao@oss.qualcomm.com/
---

Elson Serrao (1):
  dt-bindings: connector: Add role‑switch provider phandle

 .../devicetree/bindings/connector/usb-connector.yaml      | 8 ++++++++
 1 file changed, 8 insertions(+)

-- 
2.34.1

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

[Elson Serrao]

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@oss.qualcomm.com>
---
 .../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.
+
   typec-power-opmode:
     description: Determines the power operation mode that the Type C connector
       will support and will advertise through CC pins when it has no power
-- 
2.34.1

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

[Dmitry Baryshkov]

Hello,

On Tue, 24 Mar 2026 at 19:29, Elson Serrao
<elson.serrao@oss.qualcomm.com> wrote:
>
> Hi all,
>
> This patch proposes a generic Devicetree mechanism for a USB connector to
> reference the USB role‑switch provider when there is an intermediate,
> block between the connector and the controller in the OF graph.

Please, don't describe what the patch or the change does, see
Documentation/processes/submitting-patches.rst.

>
> Problem
> =======
> OF‑graph links are strictly point‑to‑point via remote-endpoint, so a
> consumer can only discover its immediate neighbor in the graph. When an
> intermediate node sits between the USB connector and the controller, the
> connector cannot identify the controller (the role‑switch provider) from
> the graph alone.

DT is a hardware description. Here you are trying to describe the
software behaviour. Please don't mix those.

[skipped diagrams]

>
> From the OF‑graph structure alone, Conn‑0 cannot determine that
> USBCtrl‑0 (and not USBCtrl‑1) is the correct role‑switch provider.
>
> Proposal
> ========
> Add an optional consumer→provider phandle on the connector:
>
>     usb-role-switch = <&controller>;

An alternative proposal: let EUD register as a role-switch and then
retranslate usb-role-switch events. This is how it is handled by the
Type-C-related objects (muxes and orientation switches).

>
> The provider remains the controller node, which already declares the
> boolean 'usb-role-switch;' and registers the role‑switch device.


-- 
With best wishes
Dmitry

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

[Dmitry Baryshkov]

On Tue, 24 Mar 2026 at 19:29, Elson Serrao
<elson.serrao@oss.qualcomm.com> 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@oss.qualcomm.com>
> ---
>  .../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.

> +
>    typec-power-opmode:
>      description: Determines the power operation mode that the Type C connector
>        will support and will advertise through CC pins when it has no power
> --
> 2.34.1
>


-- 
With best wishes
Dmitry

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

[Elson Serrao]

On 3/24/2026 10:46 AM, Dmitry Baryshkov wrote:
> Hello,
> 
> On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> <elson.serrao@oss.qualcomm.com> wrote:
>>
>> Hi all,
>>
>> This patch proposes a generic Devicetree mechanism for a USB connector to
>> reference the USB role‑switch provider when there is an intermediate,
>> block between the connector and the controller in the OF graph.
> 
> Please, don't describe what the patch or the change does, see
> Documentation/processes/submitting-patches.rst.
> 
>>
>> Problem
>> =======
>> OF‑graph links are strictly point‑to‑point via remote-endpoint, so a
>> consumer can only discover its immediate neighbor in the graph. When an
>> intermediate node sits between the USB connector and the controller, the
>> connector cannot identify the controller (the role‑switch provider) from
>> the graph alone.
> 
> DT is a hardware description. Here you are trying to describe the
> software behaviour. Please don't mix those.
> 
> [skipped diagrams]
> 
>>
>> From the OF‑graph structure alone, Conn‑0 cannot determine that
>> USBCtrl‑0 (and not USBCtrl‑1) is the correct role‑switch provider.
>>
>> Proposal
>> ========
>> Add an optional consumer→provider phandle on the connector:
>>
>>     usb-role-switch = <&controller>;
> 
> An alternative proposal: let EUD register as a role-switch and then
> retranslate usb-role-switch events. This is how it is handled by the
> Type-C-related objects (muxes and orientation switches).
> 

Hi Dmitry,

Thank you for the review and suggestions.

To better understand the intended model: are you proposing that the EUD
register a separate usb‑role‑switch instance per connector → controller
relationship, or a single role‑switch instance representing the EUD as a
whole?

I understand the analogy with Type‑C muxes and orientation switches, which
are typically modeled on a per‑connector basis. In contrast, the EUD hardware
block spans multiple connectors and controllers and can carry traffic from
multiple independent USB connections concurrently.
For example:
  - Connector0 operating in host mode (connected to Controller0)
  - Connector1 operating in device mode (connected to Controller1)
  - Both active at the same time

In such a scenario, a single role‑switch instance representing both
connectors appears ambiguous, as different roles may be active
simultaneously on different ports.

Registering multiple role‑switch instances—one per connector/controller
pair—would avoid that ambiguity. However, this would imply a single EUD
device registering multiple role‑switch instances associated with the same
firmware node. As the USB role‑switch framework currently assumes a 1:1
relationship between a firmware node and its role‑switch instance, this
would likely require non‑trivial changes to USB role switch framework on
how role‑switch instances are represented and managed.

Thanks,
Elson

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

[Elson Serrao]

On 3/24/2026 10:57 AM, Dmitry Baryshkov wrote:
> On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> <elson.serrao@oss.qualcomm.com> 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@oss.qualcomm.com>
>> ---
>>  .../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.

Thanks,
Elson
 

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@oss.qualcomm.com> wrote:
>
>
>
> On 3/24/2026 10:57 AM, Dmitry Baryshkov wrote:
> > On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> > <elson.serrao@oss.qualcomm.com> 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@oss.qualcomm.com>
> >> ---
> >>  .../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

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

[Elson Serrao]

On 3/25/2026 6:57 PM, Dmitry Baryshkov wrote:
> On Thu, 26 Mar 2026 at 03:49, Elson Serrao
> <elson.serrao@oss.qualcomm.com> wrote:
>>

[...]

>>>
>>> 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.
> 

My earlier questions were primarily around a flattened ports representation.
I agree that modeling each EUD path as a distinct child node with its own
firmware node addresses those concerns cleanly.

For context, the existing EUD binding [1] models a single controller ↔
connector relationship using a flat top-level ports block. An earlier
attempt [2] to reinterpret that top-level structure to represent
multiple paths ran into DT ABI concerns, as it changed the meaning of
existing bindings.

Based on your example, my understanding is that the intended direction is
to keep the existing top-level `ports` semantics unchanged for backward
compatibility, and model multi-path hardware using explicit child nodes,
each representing one controller ↔ connector relationship and registering
a separate usb-role-switch instance.

Please let me know if this matches the intended direction.

For the purposes of the usb‑role‑switch discussion, the other feedback in
[2] around PHY handling is orthogonal and will be addressed in a follow‑up
revision.

Thanks,
Elson

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml?h=v7.0-rc5
[2] https://lore.kernel.org/all/20260126233830.2193816-2-elson.serrao@oss.qualcomm.com/

> 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>;
>         };
>       };
>     };
>   };
> 
> };
> 

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

[Dmitry Baryshkov]

On Wed, Mar 25, 2026 at 06:44:35PM -0700, Elson Serrao wrote:
> 
> 
> On 3/24/2026 10:46 AM, Dmitry Baryshkov wrote:
> > Hello,
> > 
> > On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> > <elson.serrao@oss.qualcomm.com> wrote:
> >>
> >> Hi all,
> >>
> >> This patch proposes a generic Devicetree mechanism for a USB connector to
> >> reference the USB role‑switch provider when there is an intermediate,
> >> block between the connector and the controller in the OF graph.
> > 
> > Please, don't describe what the patch or the change does, see
> > Documentation/processes/submitting-patches.rst.
> > 
> >>
> >> Problem
> >> =======
> >> OF‑graph links are strictly point‑to‑point via remote-endpoint, so a
> >> consumer can only discover its immediate neighbor in the graph. When an
> >> intermediate node sits between the USB connector and the controller, the
> >> connector cannot identify the controller (the role‑switch provider) from
> >> the graph alone.
> > 
> > DT is a hardware description. Here you are trying to describe the
> > software behaviour. Please don't mix those.
> > 
> > [skipped diagrams]
> > 
> >>
> >> From the OF‑graph structure alone, Conn‑0 cannot determine that
> >> USBCtrl‑0 (and not USBCtrl‑1) is the correct role‑switch provider.
> >>
> >> Proposal
> >> ========
> >> Add an optional consumer→provider phandle on the connector:
> >>
> >>     usb-role-switch = <&controller>;
> > 
> > An alternative proposal: let EUD register as a role-switch and then
> > retranslate usb-role-switch events. This is how it is handled by the
> > Type-C-related objects (muxes and orientation switches).
> > 
> 
> Hi Dmitry,
> 
> Thank you for the review and suggestions.
> 
> To better understand the intended model: are you proposing that the EUD
> register a separate usb‑role‑switch instance per connector → controller
> relationship, or a single role‑switch instance representing the EUD as a
> whole?
> 
> I understand the analogy with Type‑C muxes and orientation switches, which
> are typically modeled on a per‑connector basis. In contrast, the EUD hardware
> block spans multiple connectors and controllers and can carry traffic from
> multiple independent USB connections concurrently.
> For example:
>   - Connector0 operating in host mode (connected to Controller0)
>   - Connector1 operating in device mode (connected to Controller1)
>   - Both active at the same time
> 
> In such a scenario, a single role‑switch instance representing both
> connectors appears ambiguous, as different roles may be active
> simultaneously on different ports.
> 
> Registering multiple role‑switch instances—one per connector/controller
> pair—would avoid that ambiguity. However, this would imply a single EUD
> device registering multiple role‑switch instances associated with the same
> firmware node. As the USB role‑switch framework currently assumes a 1:1
> relationship between a firmware node and its role‑switch instance, this
> would likely require non‑trivial changes to USB role switch framework on
> how role‑switch instances are represented and managed.

It assumes 1:1 between some fwnode and the role-switch. But nothing
implies that it is the device node. It is the parent of the
corresponding OF graph. If EUD has two graphs, then each graph can have
its own usb-role-switch.

-- 
With best wishes
Dmitry

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

[Dmitry Baryshkov]

On Thu, Mar 26, 2026 at 11:50:26AM -0700, Elson Serrao wrote:
> 
> 
> On 3/25/2026 6:57 PM, Dmitry Baryshkov wrote:
> > On Thu, 26 Mar 2026 at 03:49, Elson Serrao
> > <elson.serrao@oss.qualcomm.com> wrote:
> >>
> 
> [...]
> 
> >>>
> >>> 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.
> > 
> 
> My earlier questions were primarily around a flattened ports representation.
> I agree that modeling each EUD path as a distinct child node with its own
> firmware node addresses those concerns cleanly.
> 
> For context, the existing EUD binding [1] models a single controller ↔
> connector relationship using a flat top-level ports block. An earlier
> attempt [2] to reinterpret that top-level structure to represent
> multiple paths ran into DT ABI concerns, as it changed the meaning of
> existing bindings.
> 
> Based on your example, my understanding is that the intended direction is
> to keep the existing top-level `ports` semantics unchanged for backward
> compatibility, and model multi-path hardware using explicit child nodes,
> each representing one controller ↔ connector relationship and registering
> a separate usb-role-switch instance.

I'd say, it is a good idea. This matches the port / ports case, where we
don't create ports node if we know that there will be only ports@0 node.
Likewise you can have only one OF graph if there is only one path (for
backwards compatibility) and add subnodes if there is more than one.

> 
> Please let me know if this matches the intended direction.
> 
> For the purposes of the usb‑role‑switch discussion, the other feedback in
> [2] around PHY handling is orthogonal and will be addressed in a follow‑up
> revision.
> 
> Thanks,
> Elson
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml?h=v7.0-rc5
> [2] https://lore.kernel.org/all/20260126233830.2193816-2-elson.serrao@oss.qualcomm.com/
> 
> > 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