Re: [PATCH 1/9] dt-bindings: soc: qcom: eud: Restructure to model multi-path hardware

[Krzysztof Kozlowski <krzk@kernel.org>]

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.

Best regards,
Krzysztof