Re: [PATCH v4 1/9] dt-bindings: soc: qcom: eud: Add per-path child nodes for UTMI routing

[Konrad Dybcio]

On 7/4/26 2:05 AM, Dmitry Baryshkov wrote:
> On Fri, May 01, 2026 at 10:06:27AM -0700, Elson Serrao wrote:
>> The Qualcomm Embedded USB Debugger (EUD) can intercept one or two
>> independent High-Speed UTMI paths, depending on the SoC configuration.
>> Each path is distinct, with its own connector/controller connection
>> and role-dependent UTMI routing.
>>
>> Because the EUD sits between the USB connector and the USB controller,
>> it must relay role changes across the UTMI path. In device role, the
>> EUD inserts its internal hub into the path to enable debug
>> functionality. In host role, the path remains directly connected
>> between the PHY and the USB controller, bypassing the EUD hub. These
>> hardware constraints require per-path role awareness, as UTMI path
>> roles may differ.
>>
>> The existing binding models only a single UTMI path and assumes a
>> uniform routing model. While sufficient for simple device-role-only
>> configurations, this representation does not accurately describe EUD
>> hardware when role switching and/or multiple UTMI paths are involved.
>>
>> To address this limitation, per-path child nodes are introduced to
>> describe individual UTMI paths through the EUD. Each path includes its
>> own ports description, allowing controller and connector associations,
>> as well as role-aware routing.
>>
>> Signed-off-by: Elson Serrao <elson.serrao@xxxxxxxxxxxxxxxx>
>> ---

[...]

>> +oneOf:
>> +  - required:
>> +      - ports
>> +  - required:
>> +      - eud-path@0
> 
> Do we really need a separate eud-path node? It doesn't represent any
> particular part of the EUD device. Can we simply add more ports to the
> ports list?
> 
> For example:
> 
> ports {
> 	port@0 { endpoint { remote-endpoint = <&usb0_host>; }; };
> 	port@1 { endpoint { remote-endpoint = <&connector0; }; };
> 	port@2 { endpoint { remote-endpoint = <&usb1_host>; }; };
> 	port@3 { endpoint { remote-endpoint = <&connector1; }; };
> };

I think this was originally born out of the role switch framework being
strongly tied to a single OF node (because the way they're found is via
graph traversal and not via a phandle)

Konrad