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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 10/02/2026 05:32, Elson Serrao wrote:
> 
> 
> On 2/6/2026 6:55 AM, Rob Herring wrote:
>> On Mon, Jan 26, 2026 at 03:38:22PM -0800, Elson Serrao wrote:
>>> The Qualcomm Embedded USB Debugger (EUD) can intercept one or two
>>> independent High-Speed UTMI paths, depending on the SoC. Each path is
>>> distinct with its own HS-PHY interface, connector/controller wiring, and
> 
> [...]
> 
>>> +  supported on up to two High-Speed USB ports.
>>>  
>>>  properties:
>>>    compatible:
>>> @@ -29,26 +32,62 @@ properties:
>>>      description: EUD interrupt
>>>      maxItems: 1
>>>  
>>> -  ports:
>>> -    $ref: /schemas/graph.yaml#/properties/ports
>>
>> You are breaking existing users.
>>
> 
> Thanks Rob for your feedback.
> 
> The original motivation for the structural change was to make the binding
> encode resources/topology that were implicit before. Specifically the EUD
> intercept of the UTMI path(s) between the HS-USB PHY and the controller, and
> the need to represent platforms with two independent UTMI paths. That led me
> to introduce per-path nodes and a per-path PHY reference.

I do not see how this answers at all the comment, so no, it's still NAK.

> I outlined the constraints and rationale in this earlier thread:
> 
> https://lore.kernel.org/all/5cec9127-bdc5-49d7-80e1-2ae26f81163c@oss.qualcomm.com/

And you were supposed to keep things backwards compatible. Are they? Not.

Anyway, the reasoning cannot be somewhere else. Must be here in the commit.

> 
> 
>>> +  '#address-cells':
>>> +    const: 1
>>> +
>>> +  '#size-cells':
>>> +    const: 0
>>> +
>>> +patternProperties:
>>> +  "^eud-path@[0-1]$":
>>> +    type: object
>>>      description:
>>> -      These ports is to be attached to the endpoint of the DWC3 controller node
>>> -      and type C connector node. The controller has the "usb-role-switch"
>>> -      property.
>>> +      Represents one High-Speed UTMI path that EUD intercepts. This node models
>>> +      the physical data path intercepted by EUD and provides graph endpoints to
>>> +      link the USB controller and the external connector associated with this path.
>>>  
>>>      properties:
>>> -      port@0:
>>> -        $ref: /schemas/graph.yaml#/properties/port
>>> -        description: This port is to be attached to the DWC3 controller.
>>> +      reg:
>>> +        maxItems: 1
>>> +        description: Path number
>>> +
>>> +      phys:
>>> +        maxItems: 1
>>> +        description: High-Speed USB PHY associated with this data path.
>>
>> Doesn't the DWC3 node have a phys property? You don't need it twice 
>> since you can walk the graph.
>>
> 
> Yes, the DWC3 node does have a `phys` property. I added a PHY reference under
> EUD to make the dependency explicit, since the EUD debug module is independent
> and relies on the HS‑USB PHY for its operation.
> 
> If the preferred pattern is to rely on the controller’s `phys` and discover it
> by walking the graph, I’m happy to drop the duplicate reference. My only
> concern was whether that makes the dependency effectively implicit—i.e., EUD’s
> correctness would depend on a resource not directly referenced in its own
> binding. If my understanding of how this should be expressed in the binding is
> not correct, please let me know and I’ll adjust v3 accordingly.

Binding is not for drivers, so term "implicit" used before and now is
not correct. Does the EUD has dedicated different phy? Yes or not?

> 
> 
> 
>>> +
>>> +      usb-role-switch:
>>> +        type: boolean
>>> +        description:
>>> +          Set this property if the USB port on this path is role switch capable.
>>> +          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.
>>> +
>>> +      ports:
>>> +        $ref: /schemas/graph.yaml#/properties/ports
>>> +        description:
>>> +          These ports are to be attached to the endpoint of the USB controller node
>>> +          and USB connector node.
>>> +
>>> +        properties:
>>> +          port@0:
>>> +            $ref: /schemas/graph.yaml#/properties/port
>>> +            description: This port is to be attached to the USB controller.
>>>  
>>> -      port@1:
>>> -        $ref: /schemas/graph.yaml#/properties/port
>>> -        description: This port is to be attached to the type C connector.
>>> +          port@1:
>>> +            $ref: /schemas/graph.yaml#/properties/port
>>> +            description: This port is to be attached to the USB connector.
>>
>> Both port 0 and 1 are attached to the USB controller?
>>
> 
> No—only port@0 is attached to the USB controller; port@1 is attached to the USB
> connector.
> 
>> Why can't you just add more port nodes to the existing binding?
>>
> 
> Do you mean extending the existing top-level ports like this?
> 
>   - port@0: USB controller0
>   - port@1: USB connector0
>   - port@2: USB controller1
>   - port@3: USB connector1
> 
> My hesitation with a flat ports list is that it doesn’t encode which
> controller/connector pair belongs to which physical path through EUD.

What do you mean? The index defines exactly which path it is.

> A graph walk starting at Conn0 could also reach USB Ctrl1, even though
> these are independent paths and not interchangeable.
> 
> Below is the high‑level topology of EUD connections. In the disabled state,
> EUD is transparent and UTMI traffic flows directly from USB2PHY0/1 to USB
> Ctrl0/1. When EUD is enabled, the debug hub is inserted on the selected path
> by the internal UTMI switch, so UTMI traffic on that path traverses the hub.
> The non‑selected path continues as a direct PHY↔Controller link (EUD can be
> enabled on only one path at a time).
> 
> 
> 
> 					EUD Block
> 			   +------------------------------+  
> 			   |                              |
> [Conn0]-->[USB2PHY0 ]----->|  -------- Path 0 ------------|--> [ USB Ctrl0 ]
> 			   |                              |  
> [Conn1]-->[USB2PHY1 ]----->|  -------- Path 1 ------------|--> [ USB Ctrl1 ]
> 			   |                              |
> 			   |      +------------------+    |
> 			   |      |  EUD Debug Hub   |    |
> 			   |      +------------------+    |
> 			   +------------------------------+
> 
> 
> 
> So to make the connector–controller relationships explicit, I kept the `ports`
> property under the `eud-path@N` child nodes. Please let me know if there is a
> preferable way to model this.
> 
> Thanks
> Elson
> 
> 


Best regards,
Krzysztof