Re: [PATCH 2/3] dt-bindings: usb: snps,dwc3: describe the two-connector HS data path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: usb: abstraction violation placing usb-role-switch in endpoint
--

commit 91efaa7a371d20cd91b98bff5337b76e3b332667
Author: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>

dt-bindings: usb: snps,dwc3: describe the two-connector HS data path

Some designs wire the High Speed data lines of a single DWC3 controller to
two receptacles and select between them with a GPIO, while the Super Speed
lanes stay per connector. This commit describes the hardware in
snps,dwc3-common.yaml, adding port-select-gpios to select the connector
and placing mux-state and usb-role-switch inside each endpoint.

> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
> index 6609a709c1d7b..a18bb08afbae1 100644
> --- a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
> @@ -13,6 +13,28 @@ description:
>    Defines the properties of the DWC3 core as being embedded in either an
>    vendor-specific implementation or as a standalone component.
>  
> +$defs:
> +  hs-port:
> +    $ref: /schemas/graph.yaml#/$defs/port-base
> +    unevaluatedProperties: false
> +    properties:
> +      endpoint:
> +        $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +        unevaluatedProperties: false
> +        properties:
> +          usb-role-switch:
> +            type: boolean
> +            description: Separate role-switch input for this connector.
> +          mux-state:
> +            $ref: /schemas/types.yaml#/definitions/uint32
> +            enum: [0, 1]
> +            description:
> +              Logical port-select GPIO level for this data path. State 0
> +              takes precedence when both connectors request USB data.

[Severity: Medium]
Does placing usb-role-switch and mux-state inside an OF graph endpoint node
violate Devicetree abstractions?

Endpoints are strictly meant to describe connection links (like
remote-endpoint), while functional device capabilities typically belong to the
device or port node. The generic USB role switch framework also expects this
property on the device node rather than the endpoint. Could this placement
create an ABI breakage risk for the device tree?

> +        dependentRequired:
> +          usb-role-switch: [mux-state]
> +          mux-state: [usb-role-switch]
> +

[ ... ]

>  properties:
> +  usb-psy-name:
> +    description:
> +      Name of the USB power supply accepting the input current limit
> +      requested by the gadget after USB configuration, and during bus
> +      suspend and resume.
> +    $ref: /schemas/types.yaml#/definitions/string
> +
> +  port-select-gpios:
> +    maxItems: 1
> +    description:
> +      Selects between two external connectors sharing the controller's HS
> +      data bus. The port@0 and port@2 endpoints specify distinct mux-state
> +      values and provide independent role-switch inputs. The controller
> +      stops the previous role before changing the data path. With neither
> +      connector requesting data, the last selection is retained.
> +

[Severity: Medium]
Does embedding external board-level hardware mux control directly into the
DWC3 IP block binding bypass the standard generic mux subsystem?

By introducing port-select-gpios directly instead of using a standard mux
node (such as gpio-mux), this creates a non-standard DT ABI that doesn't
integrate natively with the mux framework. Would it be better to model this
using the standard mux bindings?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013102927.1141696-1-xiaqinghuan@mail.ustc.edu.cn?part=2