Re: [PATCH v4 1/9] dt-bindings: soc: qcom: eud: Add per-path child nodes for UTMI routing
From: Elson Serrao
Date: Tue Jul 07 2026 - 19:23:18 EST
On 7/6/2026 2:27 AM, Konrad Dybcio wrote:
> 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)
>
For additional context, the rationale for the path-based topology was
previously discussed here:
https://lore.kernel.org/all/CAO9ioeW7O+arR2VdAZboty_cAdtYm--ppMx9RT3nTQpJbTGccg@xxxxxxxxxxxxxx/
Thanks
Elson