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@xxxxxxxxxxxxxxxx> 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