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

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

On 3/24/2026 10:46 AM, Dmitry Baryshkov wrote:
> Hello,
> 
> On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> <elson.serrao@oss.qualcomm.com> 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.

Thanks,
Elson