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
UTMI routing behavior. The EUD hardware sits between the USB2 PHY and
the USB controller on each path.
The existing binding models only a single UTMI path and does not provide
a way to associate the required High-Speed USB PHY. EUD relies on the
HS-PHY on the selected UTMI path for link signalling and correct operation
of the hardware.
Historically, EUD has worked on platforms that use a single UTMI path
because the USB controller maintains ownership of the PHY during
enumeration and normal operation. This implicit relationship allowed
EUD to function even though the dependency on the PHY was not described
in the binding. However, this behavior is not guaranteed by hardware.
The current binding description is not sufficient for SoCs that expose
two independent UTMI paths, where the PHY association and port wiring
must be explicitly described.
Introduce per-path eud-path child nodes so each UTMI path can describe
its HS-PHY, port connections, and the role‑switching capability of its
associated USB port.
Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
---
.../bindings/soc/qcom/qcom,eud.yaml | 100 +++++++++++++-----
1 file changed, 74 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
index 84218636c0d8..0507252dbf27 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
@@ -10,8 +10,11 @@ maintainers:
- Souradeep Chowdhury <quic_schowdhu@quicinc.com>
description:
- This binding is used to describe the Qualcomm Embedded USB Debugger, which is
- mini USB-hub implemented on chip to support USB-based debug capabilities.
+ This binding describes the Qualcomm Embedded USB Debugger (EUD), an on-chip
+ mini USB hub that enables USB-based debug capabilities. The EUD block is
+ positioned between the High-Speed USB PHY and the USB controller, where it
+ intercepts the UTMI interface to support debug and bypass modes. EUD can be
+ 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
+ '#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.
+
+ 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.
+
+ required:
+ - reg
+ - phys
+ - ports
+
+ additionalProperties: false
required:
- compatible
- reg
- - ports
additionalProperties: false
@@ -58,21 +97,30 @@ examples:
compatible = "qcom,sc7280-eud", "qcom,eud";
reg = <0x88e0000 0x2000>,
<0x88e2000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eud-path@0 {
+ reg = <0>;
+ phys = <&usb_1_hsphy>;
+ usb-role-switch;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- eud_ep: endpoint {
- remote-endpoint = <&usb2_role_switch>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ eud_ep: endpoint {
+ remote-endpoint = <&usb2_role_switch>;
+ };
};
- };
- port@1 {
- reg = <1>;
- eud_con: endpoint {
- remote-endpoint = <&con_eud>;
+ port@1 {
+ reg = <1>;
+ eud_con: endpoint {
+ remote-endpoint = <&con_eud>;
+ };
};
};
};
--
2.34.1
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 > UTMI routing behavior. The EUD hardware sits between the USB2 PHY and > the USB controller on each path. > > The existing binding models only a single UTMI path and does not provide > a way to associate the required High-Speed USB PHY. EUD relies on the > HS-PHY on the selected UTMI path for link signalling and correct operation > of the hardware. > > Historically, EUD has worked on platforms that use a single UTMI path > because the USB controller maintains ownership of the PHY during > enumeration and normal operation. This implicit relationship allowed > EUD to function even though the dependency on the PHY was not described > in the binding. However, this behavior is not guaranteed by hardware. > The current binding description is not sufficient for SoCs that expose > two independent UTMI paths, where the PHY association and port wiring > must be explicitly described. > > Introduce per-path eud-path child nodes so each UTMI path can describe > its HS-PHY, port connections, and the role‑switching capability of its > associated USB port. > > Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> > --- > .../bindings/soc/qcom/qcom,eud.yaml | 100 +++++++++++++----- > 1 file changed, 74 insertions(+), 26 deletions(-) > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml > index 84218636c0d8..0507252dbf27 100644 > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml > @@ -10,8 +10,11 @@ maintainers: > - Souradeep Chowdhury <quic_schowdhu@quicinc.com> > > description: > - This binding is used to describe the Qualcomm Embedded USB Debugger, which is > - mini USB-hub implemented on chip to support USB-based debug capabilities. > + This binding describes the Qualcomm Embedded USB Debugger (EUD), an on-chip > + mini USB hub that enables USB-based debug capabilities. The EUD block is > + positioned between the High-Speed USB PHY and the USB controller, where it > + intercepts the UTMI interface to support debug and bypass modes. EUD can be > + 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. > + '#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. > + > + 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? Why can't you just add more port nodes to the existing binding? Rob
On 1/27/26 12:38 AM, 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 > UTMI routing behavior. The EUD hardware sits between the USB2 PHY and > the USB controller on each path. > > The existing binding models only a single UTMI path and does not provide > a way to associate the required High-Speed USB PHY. EUD relies on the > HS-PHY on the selected UTMI path for link signalling and correct operation > of the hardware. > > Historically, EUD has worked on platforms that use a single UTMI path > because the USB controller maintains ownership of the PHY during > enumeration and normal operation. This implicit relationship allowed > EUD to function even though the dependency on the PHY was not described > in the binding. However, this behavior is not guaranteed by hardware. > The current binding description is not sufficient for SoCs that expose > two independent UTMI paths, where the PHY association and port wiring > must be explicitly described. > > Introduce per-path eud-path child nodes so each UTMI path can describe > its HS-PHY, port connections, and the role‑switching capability of its > associated USB port. > > Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> > --- [...] > +patternProperties: > + "^eud-path@[0-1]$": At least a since instance of this should be 'required' Konrad
On 1/27/26 12:38 AM, 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 > UTMI routing behavior. The EUD hardware sits between the USB2 PHY and > the USB controller on each path. > > The existing binding models only a single UTMI path and does not provide > a way to associate the required High-Speed USB PHY. EUD relies on the > HS-PHY on the selected UTMI path for link signalling and correct operation > of the hardware. > > Historically, EUD has worked on platforms that use a single UTMI path > because the USB controller maintains ownership of the PHY during > enumeration and normal operation. This implicit relationship allowed > EUD to function even though the dependency on the PHY was not described > in the binding. However, this behavior is not guaranteed by hardware. > The current binding description is not sufficient for SoCs that expose > two independent UTMI paths, where the PHY association and port wiring > must be explicitly described. > > Introduce per-path eud-path child nodes so each UTMI path can describe > its HS-PHY, port connections, and the role‑switching capability of its > associated USB port. > > Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> > --- [...] > +patternProperties: > + "^eud-path@[0-1]$": I can't quite put it into words why I don't like this name, but I don't like this name.. That said I don't really have any clever ideas for a better one, so I'm not going to object, suppose I just needed to vent my ramblings > + 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. > + > + usb-role-switch: > + type: boolean > + description: > + Set this property if the USB port on this path is role switch capable. This doesn't quite sound right. The EUD acts/can act as a rolesw no matter what's connected to it. > + 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. The rest of this paragraph is good stuff, explaining the reasoning > + > + 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. nit: "Type-C" Konrad
© 2016 - 2026 Red Hat, Inc.