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

[Elson Serrao <elson.serrao@oss.qualcomm.com>]

+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(+)
>