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

[Elson Serrao]

On 7/3/2026 12:45 AM, Krzysztof Kozlowski 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.
> 
> You miss SoC specific compatibles in the patch. Binding describes ONLY
> SC7280 but you claim here it depends on SoC (not sure what is a
> "configuration" of a SoC).
> 
> This should be also restricted per each variant as it depends on number
> of controllers in each SoC.
> 
>>
>> 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>
>> ---
>>  .../bindings/soc/qcom/qcom,eud.yaml           | 55 ++++++++++++++++++-
>>  1 file changed, 54 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
>> index 84218636c0d8..21f75038a81c 100644
>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
>> @@ -45,10 +45,63 @@ properties:
>>          $ref: /schemas/graph.yaml#/properties/port
>>          description: This port is to be attached to the type C connector.
>>  
>> +  '#address-cells':
>> +    const: 1
>> +
>> +  '#size-cells':
>> +    const: 0
>> +
>> +patternProperties:
>> +  "^eud-path@[0-1]$":
>> +    type: object
>> +    description:
>> +      Represents one High-Speed UTMI path that EUD intercepts. Use eud-path nodes
>> +      to associate role-switching behavior with specific port connections, allowing
>> +      EUD to manage role transitions independently for each UTMI path.
>> +
>> +    properties:
>> +      reg:
>> +        maxItems: 1
>> +        description: Path number
>> +
>> +      usb-role-switch:
>> +        type: boolean
>> +        description:
>> +          Indicates that EUD should act as a role switch for this path.
>> +          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.
> 
> role-switch is per entire device, not per path. Either device has role
> switching or not.
> 
The EUD wrapper relays role information across each path, and
role-dependent UTMI routing is performed on a per-path basis. A single
EUD-level usb-role-switch therefore becomes ambiguous once EUD spans
multiple independent paths, as it does not describe which path is
participating in role-relay/role-dependent routing.
>> +
>> +      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 USB connector.
> 
> Add one more example with eud-paths and its dedicated compatible.
> 
Ack

>> +
>> +    required:
>> +      - reg
>> +      - ports
>> +
>> +    additionalProperties: false
>> +
>>  required:
>>    - compatible
>>    - reg
>> -  - ports
>> +
>> +oneOf:
>> +  - required:
>> +      - ports
>> +  - required:
>> +      - eud-path@0
> 
> - eud-path@1
> 
> There is no point to provide eud-path@0 alone. Ports are doing that
> already.
> 
eud-path@1 is not applicable to SC7280 as it doesnt support EUD on
secondary USB port. But eud-path@0 alone is needed even for single-path
SoCs when role-dependent routing is involved.

The existing top-level ports representation only describes endpoint
connectivity. It cannot describe path-specific behavior such as role
relay and role-dependent UTMI routing associated with a UTMI path
through EUD.

The legacy ports representation is retained for compatibility with
existing users (if any). However, the goal is to make the path-based
representation the preferred representation going forward, as it
accurately describes EUD hardware when role switching is involved.

Additionally, like you mentioned above we can restrict paths based on
SoC hardware when we add more compatibles.
Something like below (SM8350 maps EUD over both primary and secondary
USB port)

oneOf:
  - required:
      - ports
  - allOf:
      - if:
          properties:
            compatible:
              contains:
                const: qcom,sc7280-eud
        then:
          required:
            - eud-path@0
      - if:
          properties:
            compatible:
              contains:
                const: qcom,sm8350-eud
        then:
          required:
            - eud-path@0
            - eud-path@1

Thanks
Elson