The Qualcomm Embedded USB Debugger (EUD) hardware can intercept up to
two independent High-Speed UTMI data paths, depending on the SoC
configuration. Each path operates independently with:
- Dedicated PHY interface
- Distinct USB connector and controller associations
- Role dependent routing
Model these hardware paths as separate eud-path nodes to accurately
represent the physical topology and add below per-path properties:
phys: EUD exposes a High-Speed debug hub that relies on HS-PHY for its
operation. This property references the HS-PHY associated with the UTMI
path.
usb-role-switch: Indicates that the USB port on this UTMI path supports
role switching. 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.
This change breaks backwards compatibility, but the previous binding
omitted critical resources like PHY and did not describe per-path
topology. Without these modifications EUD cannot be guaranteed to
function.
Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
---
.../bindings/soc/qcom/qcom,eud.yaml | 97 ++++++++++++++-----
1 file changed, 71 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..a7162560c323 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,59 @@ 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.
+
+ 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 +94,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.1On Fri, Jan 16, 2026 at 03:20:58PM -0800, Elson Serrao wrote: > The Qualcomm Embedded USB Debugger (EUD) hardware can intercept up to > two independent High-Speed UTMI data paths, depending on the SoC > configuration. Each path operates independently with: > > - Dedicated PHY interface > - Distinct USB connector and controller associations > - Role dependent routing > > Model these hardware paths as separate eud-path nodes to accurately > represent the physical topology and add below per-path properties: > > phys: EUD exposes a High-Speed debug hub that relies on HS-PHY for its > operation. This property references the HS-PHY associated with the UTMI > path. > > usb-role-switch: Indicates that the USB port on this UTMI path supports > role switching. 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. > > This change breaks backwards compatibility, but the previous binding > omitted critical resources like PHY and did not describe per-path > topology. Without these modifications EUD cannot be guaranteed to > function. It was working for 3 years, so your guarantees are just imprecise. FUD is not an argument. Qualcomm task at 2022 was to post complete bindings. These were posted and accepted. Three years later you say that previous posting was bollocks and this cannot even work? Nah, take responsibility of what you did in the past. Best regards, Krzysztof
On Sat, Jan 17, 2026 at 12:57:58PM +0100, Krzysztof Kozlowski wrote: > On Fri, Jan 16, 2026 at 03:20:58PM -0800, Elson Serrao wrote: > > The Qualcomm Embedded USB Debugger (EUD) hardware can intercept up to > > two independent High-Speed UTMI data paths, depending on the SoC > > configuration. Each path operates independently with: > > > > - Dedicated PHY interface > > - Distinct USB connector and controller associations > > - Role dependent routing > > > > Model these hardware paths as separate eud-path nodes to accurately > > represent the physical topology and add below per-path properties: > > > > phys: EUD exposes a High-Speed debug hub that relies on HS-PHY for its > > operation. This property references the HS-PHY associated with the UTMI > > path. > > > > usb-role-switch: Indicates that the USB port on this UTMI path supports > > role switching. 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. > > > > This change breaks backwards compatibility, but the previous binding > > omitted critical resources like PHY and did not describe per-path > > topology. Without these modifications EUD cannot be guaranteed to > > function. > > It was working for 3 years, so your guarantees are just imprecise. FUD > is not an argument. > > Qualcomm task at 2022 was to post complete bindings. These were posted > and accepted. Three years later you say that previous posting was > bollocks and this cannot even work? > That is correct. The description of the hardware that was provided when this was upstreamed and the binding that was accepted based on this description is wrong. There's absolutely a value in maintainting backwards compatibility in general, but is this one of those cases? > Nah, take responsibility of what you did in the past. > In my view the responsible thing is to accept that we got it wrong and make sure EUD is enabled end-to-end so people can actually use it. Regards, Bjorn
On 19/01/2026 20:58, Bjorn Andersson wrote: > On Sat, Jan 17, 2026 at 12:57:58PM +0100, Krzysztof Kozlowski wrote: >> On Fri, Jan 16, 2026 at 03:20:58PM -0800, Elson Serrao wrote: >>> The Qualcomm Embedded USB Debugger (EUD) hardware can intercept up to >>> two independent High-Speed UTMI data paths, depending on the SoC >>> configuration. Each path operates independently with: >>> >>> - Dedicated PHY interface >>> - Distinct USB connector and controller associations >>> - Role dependent routing >>> >>> Model these hardware paths as separate eud-path nodes to accurately >>> represent the physical topology and add below per-path properties: >>> >>> phys: EUD exposes a High-Speed debug hub that relies on HS-PHY for its >>> operation. This property references the HS-PHY associated with the UTMI >>> path. >>> >>> usb-role-switch: Indicates that the USB port on this UTMI path supports >>> role switching. 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. >>> >>> This change breaks backwards compatibility, but the previous binding >>> omitted critical resources like PHY and did not describe per-path >>> topology. Without these modifications EUD cannot be guaranteed to >>> function. >> >> It was working for 3 years, so your guarantees are just imprecise. FUD >> is not an argument. >> >> Qualcomm task at 2022 was to post complete bindings. These were posted >> and accepted. Three years later you say that previous posting was >> bollocks and this cannot even work? >> > > That is correct. The description of the hardware that was provided when > this was upstreamed and the binding that was accepted based on this > description is wrong. > > There's absolutely a value in maintainting backwards compatibility in > general, but is this one of those cases? > >> Nah, take responsibility of what you did in the past. >> > > In my view the responsible thing is to accept that we got it wrong and > make sure EUD is enabled end-to-end so people can actually use it. I would expect to see what is not working. This is in mainline for three years, so the assumption is that it was working for these three years. If it wasn't, this should be described and "cannot be guaranteed to function" is just imprecise. Best regards, Krzysztof
On 1/19/2026 11:20 PM, Krzysztof Kozlowski wrote: > On 19/01/2026 20:58, Bjorn Andersson wrote: >> On Sat, Jan 17, 2026 at 12:57:58PM +0100, Krzysztof Kozlowski wrote: >>> On Fri, Jan 16, 2026 at 03:20:58PM -0800, Elson Serrao wrote: >>>> The Qualcomm Embedded USB Debugger (EUD) hardware can intercept up to >>>> two independent High-Speed UTMI data paths, depending on the SoC >>>> configuration. Each path operates independently with: >>>> >>>> - Dedicated PHY interface >>>> - Distinct USB connector and controller associations >>>> - Role dependent routing >>>> >>>> Model these hardware paths as separate eud-path nodes to accurately >>>> represent the physical topology and add below per-path properties: >>>> >>>> phys: EUD exposes a High-Speed debug hub that relies on HS-PHY for its >>>> operation. This property references the HS-PHY associated with the UTMI >>>> path. >>>> >>>> usb-role-switch: Indicates that the USB port on this UTMI path supports >>>> role switching. 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. >>>> >>>> This change breaks backwards compatibility, but the previous binding >>>> omitted critical resources like PHY and did not describe per-path >>>> topology. Without these modifications EUD cannot be guaranteed to >>>> function. >>> >>> It was working for 3 years, so your guarantees are just imprecise. FUD >>> is not an argument. >>> >>> Qualcomm task at 2022 was to post complete bindings. These were posted >>> and accepted. Three years later you say that previous posting was >>> bollocks and this cannot even work? >>> >> >> That is correct. The description of the hardware that was provided when >> this was upstreamed and the binding that was accepted based on this >> description is wrong. >> >> There's absolutely a value in maintainting backwards compatibility in >> general, but is this one of those cases? >> >>> Nah, take responsibility of what you did in the past. >>> >> >> In my view the responsible thing is to accept that we got it wrong and >> make sure EUD is enabled end-to-end so people can actually use it. > > I would expect to see what is not working. This is in mainline for three > years, so the assumption is that it was working for these three years. > If it wasn't, this should be described and "cannot be guaranteed to > function" is just imprecise. > Thanks, Bjorn and Krzysztof, for the feedback. Let me clarify what I meant by “cannot be guaranteed to work”, as I agree the phrasing can be improved to more precisely convey the intent. The concern is not that EUD did not or could not work historically. Rather, the issue is that the hardware description provided by the binding does not explicitly describe ownership and control of hardware resources that EUD depends on. As a result, correctness of EUD operation relies on behavior outside of what is expressed in the description. Concretely, the binding does not reference the HS-PHY. In practice, EUD may function because the USB controller (e.g. DWC3) keeps the PHY powered and configured. However, this relationship is not described as a contract in the binding. The USB controller may legitimately relinquish PHY control as part of its own power-management or low-power transitions. The EUD hardware is capable of operating independently, but doing so requires EUD to have explicit control of the PHY. The hardware specification lists the PHY as a required resource of the EUD debug hub. Not modeling it in the binding therefore leaves the description incomplete, because EUD resource requirements are being met implicitly through another hardware block (USB controller) rather than being described directly. In addition, the hardware can expose multiple UTMI paths (dual-port EUD), which the current binding cannot represent. The intent of this patch is therefore to correct and tighten the binding so that the hardware resources and topology EUD depends on are explicitly modeled, rather than relying on side effects of USB controller. I will update the backwards compatibility justification accordingly. Thanks Elson
On Tue, Jan 20, 2026 at 02:16:17PM -0800, Elson Serrao wrote: > > > On 1/19/2026 11:20 PM, Krzysztof Kozlowski wrote: > > On 19/01/2026 20:58, Bjorn Andersson wrote: > >> On Sat, Jan 17, 2026 at 12:57:58PM +0100, Krzysztof Kozlowski wrote: > >>> On Fri, Jan 16, 2026 at 03:20:58PM -0800, Elson Serrao wrote: > >>>> The Qualcomm Embedded USB Debugger (EUD) hardware can intercept up to > >>>> two independent High-Speed UTMI data paths, depending on the SoC > >>>> configuration. Each path operates independently with: > >>>> > >>>> - Dedicated PHY interface > >>>> - Distinct USB connector and controller associations > >>>> - Role dependent routing > >>>> > >>>> Model these hardware paths as separate eud-path nodes to accurately > >>>> represent the physical topology and add below per-path properties: > >>>> > >>>> phys: EUD exposes a High-Speed debug hub that relies on HS-PHY for its > >>>> operation. This property references the HS-PHY associated with the UTMI > >>>> path. > >>>> > >>>> usb-role-switch: Indicates that the USB port on this UTMI path supports > >>>> role switching. 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. > >>>> > >>>> This change breaks backwards compatibility, but the previous binding > >>>> omitted critical resources like PHY and did not describe per-path > >>>> topology. Without these modifications EUD cannot be guaranteed to > >>>> function. > >>> > >>> It was working for 3 years, so your guarantees are just imprecise. FUD > >>> is not an argument. > >>> > >>> Qualcomm task at 2022 was to post complete bindings. These were posted > >>> and accepted. Three years later you say that previous posting was > >>> bollocks and this cannot even work? > >>> > >> > >> That is correct. The description of the hardware that was provided when > >> this was upstreamed and the binding that was accepted based on this > >> description is wrong. > >> > >> There's absolutely a value in maintainting backwards compatibility in > >> general, but is this one of those cases? > >> > >>> Nah, take responsibility of what you did in the past. > >>> > >> > >> In my view the responsible thing is to accept that we got it wrong and > >> make sure EUD is enabled end-to-end so people can actually use it. > > > > I would expect to see what is not working. This is in mainline for three > > years, so the assumption is that it was working for these three years. > > If it wasn't, this should be described and "cannot be guaranteed to > > function" is just imprecise. > > I see, that I agree with. > Thanks, Bjorn and Krzysztof, for the feedback. > > Let me clarify what I meant by “cannot be guaranteed to work”, as I agree > the phrasing can be improved to more precisely convey the intent. > > The concern is not that EUD did not or could not work historically. > Rather, the issue is that the hardware description provided by the > binding does not explicitly describe ownership and control of hardware > resources that EUD depends on. As a result, correctness of EUD operation > relies on behavior outside of what is expressed in the description. > > Concretely, the binding does not reference the HS-PHY. In practice, > EUD may function because the USB controller (e.g. DWC3) keeps the > PHY powered and configured. > > However, this relationship is not described as a contract in the > binding. The USB controller may legitimately relinquish PHY control as > part of its own power-management or low-power transitions. The EUD > hardware is capable of operating independently, but doing so requires > EUD to have explicit control of the PHY. > > The hardware specification lists the PHY as a required resource of the > EUD debug hub. Not modeling it in the binding therefore leaves the > description incomplete, because EUD resource requirements are being met > implicitly through another hardware block (USB controller) rather than > being described directly. > > In addition, the hardware can expose multiple UTMI paths (dual-port > EUD), which the current binding cannot represent. > > The intent of this patch is therefore to correct and tighten the > binding so that the hardware resources and topology EUD depends on are > explicitly modeled, rather than relying on side effects of USB controller. > > I will update the backwards compatibility justification accordingly. > Please try to consolidate this whole explanation a bit and include it in the commit message. Regards, Bjorn > Thanks > Elson
© 2016 - 2026 Red Hat, Inc.