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

[Dmitry Baryshkov]

On Tue, Jul 07, 2026 at 04:23:03PM -0700, Elson Serrao wrote:
> 
> 
> 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/

This needs to be explained in the commit message.


-- 
With best wishes
Dmitry