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>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
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: [PATCH v2 0/1] dt-bindings: connector: Add role‑switch provider phandle
Date: Tue, 24 Mar 2026 10:29:15 -0700 [thread overview]
Message-ID: <20260324172916.804229-1-elson.serrao@oss.qualcomm.com> (raw)
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
next reply other threads:[~2026-03-24 17:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 17:29 Elson Serrao [this message]
2026-03-24 17:29 ` [PATCH v2 1/1] dt-bindings: connector: Add role‑switch provider phandle Elson Serrao
2026-03-24 17:57 ` Dmitry Baryshkov
2026-03-26 1:49 ` Elson Serrao
2026-03-26 1:57 ` Dmitry Baryshkov
2026-03-26 18:50 ` Elson Serrao
2026-03-29 16:42 ` Dmitry Baryshkov
2026-03-24 17:46 ` [PATCH v2 0/1] " Dmitry Baryshkov
2026-03-26 1:44 ` Elson Serrao
2026-03-29 16:39 ` Dmitry Baryshkov
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=20260324172916.804229-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=heikki.krogerus@linux.intel.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