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

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

On 3/24/2026 10:57 AM, Dmitry Baryshkov wrote:
> On Tue, 24 Mar 2026 at 19:29, Elson Serrao
> <elson.serrao@oss.qualcomm.com> wrote:
>>
>> Add an optional consumer→provider phandle on USB connectors to reference
>> the USB role-switch provider when no direct graph link exists. The DRD
>> controller remains the provider via its 'usb-role-switch' property.
>>
>> Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
>> ---
>>  .../devicetree/bindings/connector/usb-connector.yaml      | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
>> index 11e40d225b9f..ef8d3d26461b 100644
>> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
>> @@ -95,6 +95,14 @@ properties:
>>        - device
>>        - dual
>>
>> +  usb-role-switch:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description:
>> +      A phandle to the USB role-switch provider. The provider is typically
>> +      a dual-role (DRD) USB controller node that declares the boolean
>> +      'usb-role-switch' property. Use this when the connector is not
>> +      directly linked to the provider in the OF graph.
> 
> This kind of properties has already been discussed at least twice:
> - First for referencing the DisplayPort controller from the AltMode
> node (USB-C connector)
> - Then for referencing the USB-C muxes / orientation switches when
> there is an intermediate chip
> 
> In both cases the agreement was to not add such out of band handle
> references. The solution was on the software side, letting drivers for
> the intermediate devices in the OF graph translate and resend
> necessary events.
> 
> Previously we didn't have such an issue for the usb-role-switch,
> because there always have been a direct link between the USB connector
> (be it gpio-usb-b-connector or usb-c-connector) and the USB controller
> (implementing usb-role-switch). As with the EUD this is no longer a
> case, my suggestion would be to follow prior art and let EUD receive,
> interpret and resend usb-role-switch events.
>

In this topology, the EUD hardware spans more than one independent
role-switch relationship, as a single EUD node is the direct neighbor of
multiple connectors. This introduces additional considerations around
role-switch discovery.

One practical consideration if the EUD registers multiple role-switch
instances is that fwnode_usb_role_switch_get() ( which relies on
class_find_device_by_fwnode API), assumes a unique firmware node per
role-switch instance. If multiple role-switch instances are registered
against the same firmware node (the EUD fwnode), the lookup will return
only the first registered instance, making it difficult for a connector to
reliably bind to its intended role-switch provider.

Supporting multiple role-switch instances in this model would therefore
require extending the lookup mechanism to allow additional disambiguation
(for example, associating role-switch instances with connector context).

I want to make sure I clearly understand the intended modeling and whether
these USB role-switch framework implications are considered acceptable.

Thanks,
Elson