From: Elson Serrao <elson.serrao@oss.qualcomm.com>
To: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Konrad Dybcio <konradybcio@kernel.org>,
Wesley Cheng <quic_wcheng@quicinc.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH 0/1] dt-bindings: connector: Add roleâswitch provider phandle
Date: Mon, 23 Feb 2026 11:10:41 -0800 [thread overview]
Message-ID: <20260223191042.825136-1-elson.serrao@oss.qualcomm.com> (raw)
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
next reply other threads:[~2026-02-23 19:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 19:10 Elson Serrao [this message]
2026-02-23 19:10 ` [RFC PATCH 1/1] dt-bindings: connector: Add role‑switch " Elson Serrao
2026-02-24 18:56 ` [RFC PATCH 0/1] " Elson Serrao
2026-03-09 20:41 ` Elson Serrao
2026-03-11 13:23 ` Heikki Krogerus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260223191042.825136-1-elson.serrao@oss.qualcomm.com \
--to=elson.serrao@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_wcheng@quicinc.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®