Message-ID: <cb0693b2-b9fd-4880-86fa-26fd1259f5b1@oss.qualcomm.com>
Date: Mon, 9 Feb 2026 20:32:34 -0800
From: Elson Serrao <elson.serrao@....qualcomm.com>
To: Rob Herring <robh@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...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 v2 1/9] dt-bindings: soc: qcom: eud: Restructure to model
 multi-path hardware



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 outlined the constraints and rationale in this earlier thread:

https://lore.kernel.org/all/5cec9127-bdc5-49d7-80e1-2ae26f81163c@oss.qualcomm.com/


>> +  '#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.



>> +
>> +      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.
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

Powered by blists - more mailing lists