Message-ID: <l2gv232wwct4px45rb27eouehx7nmy4b6n6lb4aoa6e3npeun6@dih26d4gzmuo>
Date: Tue, 20 Jan 2026 20:21:31 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Elson Serrao <elson.serrao@....qualcomm.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Souradeep Chowdhury <quic_schowdhu@...cinc.com>, 
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, linux-usb@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/9] dt-bindings: soc: qcom: eud: Restructure to model
 multi-path hardware

On Tue, Jan 20, 2026 at 02:16:17PM -0800, Elson Serrao wrote:
> 
> 
> On 1/19/2026 11:20 PM, Krzysztof Kozlowski wrote:
> > On 19/01/2026 20:58, Bjorn Andersson wrote:
> >> On Sat, Jan 17, 2026 at 12:57:58PM +0100, Krzysztof Kozlowski wrote:
> >>> On Fri, Jan 16, 2026 at 03:20:58PM -0800, Elson Serrao wrote:
> >>>> The Qualcomm Embedded USB Debugger (EUD) hardware can intercept up to
> >>>> two independent High-Speed UTMI data paths, depending on the SoC
> >>>> configuration. Each path operates independently with:
> >>>>
> >>>> - Dedicated PHY interface
> >>>> - Distinct USB connector and controller associations
> >>>> - Role dependent routing
> >>>>
> >>>> Model these hardware paths as separate eud-path nodes to accurately
> >>>> represent the physical topology and add below per-path properties:
> >>>>
> >>>> phys: EUD exposes a High-Speed debug hub that relies on HS-PHY for its
> >>>> operation. This property references the HS-PHY associated with the UTMI
> >>>> path.
> >>>>
> >>>> usb-role-switch: Indicates that the USB port on this UTMI path supports
> >>>> role switching. In device role, debug mode inserts the EUD hub into the
> >>>> UTMI path. In host role, the EUD hub is bypassed and UTMI traffic flows
> >>>> directly between the PHY and the USB controller.
> >>>>
> >>>> This change breaks backwards compatibility, but the previous binding
> >>>> omitted critical resources like PHY and did not describe per-path
> >>>> topology. Without these modifications EUD cannot be guaranteed to
> >>>> function.
> >>>
> >>> It was working for 3 years, so your guarantees are just imprecise. FUD
> >>> is not an argument.
> >>>
> >>> Qualcomm task at 2022 was to post complete bindings. These were posted
> >>> and accepted. Three years later you say that previous posting was
> >>> bollocks and this cannot even work?
> >>>
> >>
> >> That is correct. The description of the hardware that was provided when
> >> this was upstreamed and the binding that was accepted based on this
> >> description is wrong.
> >>
> >> There's absolutely a value in maintainting backwards compatibility in
> >> general, but is this one of those cases?
> >>
> >>> Nah, take responsibility of what you did in the past.
> >>>
> >>
> >> In my view the responsible thing is to accept that we got it wrong and
> >> make sure EUD is enabled end-to-end so people can actually use it.
> > 
> > I would expect to see what is not working. This is in mainline for three
> > years, so the assumption is that it was working for these three years.
> > If it wasn't, this should be described and "cannot be guaranteed to
> > function" is just imprecise.
> > 

I see, that I agree with.

> Thanks, Bjorn and Krzysztof, for the feedback.
> 
> Let me clarify what I meant by “cannot be guaranteed to work”, as I agree
> the phrasing can be improved to more precisely convey the intent.
> 
> The concern is not that EUD did not or could not work historically.
> Rather, the issue is that the hardware description provided by the
> binding does not explicitly describe ownership and control of hardware
> resources that EUD depends on. As a result, correctness of EUD operation
> relies on behavior outside of what is expressed in the description.
> 
> Concretely, the binding does not reference the HS-PHY. In practice,
> EUD may function because the USB controller (e.g. DWC3) keeps the
> PHY powered and configured.
> 
> However, this relationship is not described as a contract in the
> binding. The USB controller may legitimately relinquish PHY control as
> part of its own power-management or low-power transitions. The EUD
> hardware is capable of operating independently, but doing so requires
> EUD to have explicit control of the PHY.
> 
> The hardware specification lists the PHY as a required resource of the
> EUD debug hub. Not modeling it in the binding therefore leaves the
> description incomplete, because EUD resource requirements are being met
> implicitly through another hardware block (USB controller) rather than
> being described directly.
> 
> In addition, the hardware can expose multiple UTMI paths (dual-port
> EUD), which the current binding cannot represent.
> 
> The intent of this patch is therefore to correct and tighten the
> binding so that the hardware resources and topology EUD depends on are
> explicitly modeled, rather than relying on side effects of USB controller.
> 
> I will update the backwards compatibility justification accordingly.
> 

Please try to consolidate this whole explanation a bit and include it in
the commit message.

Regards,
Bjorn

> Thanks
> Elson

Powered by blists - more mailing lists