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

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

[Elson Serrao]

Hi all,

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

Request
=======
Please confirm whether adding an optional connector-side provider
phandle is an acceptable general pattern for these topologies. If there
is a more appropriate DT modeling approach for this scenario, I would
appreciate your guidance.

Thanks for your time and review.

Best regards,
Elson Serrao

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml?h=v6.19

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

[RFC PATCH 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: [RFC PATCH 0/1] dt-bindings: connector: Add role‑switch provider phandle

[Elson Serrao]

+Heikki Krogerus <heikki.krogerus@linux.intel.com>

Adding Heikki since this relates to usb-role-switch provider modeling.

Thanks,
Elson

On 2/23/2026 11:10 AM, Elson Serrao wrote:
> Hi all,
> 
> This RFC 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.
> 
> Request
> =======
> Please confirm whether adding an optional connector-side provider
> phandle is an acceptable general pattern for these topologies. If there
> is a more appropriate DT modeling approach for this scenario, I would
> appreciate your guidance.
> 
> Thanks for your time and review.
> 
> Best regards,
> Elson Serrao
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml?h=v6.19
> 
> Elson Serrao (1):
>   dt-bindings: connector: Add role‑switch provider phandle
> 
>  .../devicetree/bindings/connector/usb-connector.yaml      | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 

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

[Elson Serrao]

On 2/24/2026 10:56 AM, Elson Serrao wrote:
> +Heikki Krogerus <heikki.krogerus@linux.intel.com>
> 
> Adding Heikki since this relates to usb-role-switch provider modeling.
> 
> Thanks,
> Elson
> 
> On 2/23/2026 11:10 AM, Elson Serrao wrote:
>> Hi all,
>>
>> This RFC 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.
>>

[...]

Gentle ping on this RFC.

When you have a moment, I’d appreciate guidance on whether the proposed
modeling direction looks acceptable.

For context only, the following DTS patch illustrates this modeling:
https://lore.kernel.org/all/20260309203337.803986-11-elson.serrao@oss.qualcomm.com/

Thanks!

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

[Heikki Krogerus]

Mon, Mar 09, 2026 at 01:41:20PM -0700, Elson Serrao kirjoitti:
> 
> 
> On 2/24/2026 10:56 AM, Elson Serrao wrote:
> > +Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > 
> > Adding Heikki since this relates to usb-role-switch provider modeling.
> > 
> > Thanks,
> > Elson
> > 
> > On 2/23/2026 11:10 AM, Elson Serrao wrote:
> >> Hi all,
> >>
> >> This RFC 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.
> >>
> 
> [...]
> 
> Gentle ping on this RFC.
> 
> When you have a moment, I’d appreciate guidance on whether the proposed
> modeling direction looks acceptable.
> 
> For context only, the following DTS patch illustrates this modeling:
> https://lore.kernel.org/all/20260309203337.803986-11-elson.serrao@oss.qualcomm.com/

FWIW you proposal is okay by me.

thanks,

-- 
heikki