Re: [PATCH] arm64: dts: qcom: lemans: Enable eud support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] EUD OF graph insertion breaks Type-C dual-role discovery and creates uncoordinated role switch contention.
- [Medium] Missing `status = "disabled";` for the `eud` node in the SoC `.dtsi`.
- [Low] Missing SoC-specific compatible string for SA8775P.
- [Low] Incorrect Device Tree indentation in the `eud` ports block.
--

commit eb22943ea779d0aae264ce0f40299849c69660cb
Author: Akash Kumar <akash.kumar@oss.qualcomm.com>

arm64: dts: qcom: lemans: Enable eud support

This commit adds the EUD controller node in lemans.dtsi and updates the USB
HS endpoint routing on lemans-evk to pass through EUD instead of linking
the connector directly to the DWC3 HS controller.

> --- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts

[ ... ]

> @@ -54,7 +54,7 @@ port@0 {
>  				reg = <0>;
>  
>  				usb0_con_hs_ep: endpoint {
> -					remote-endpoint = <&usb_0_dwc3_hs>;
> +					remote-endpoint = <&eud_con>;
>  				};

By inserting the EUD node between the Type-C connector's High-Speed
endpoint and the DWC3 controller, the DWC3 controller is no longer an
immediate neighbor of the connector.

Standard Type-C role switch discovery (e.g., via
fwnode_usb_role_switch_get()) only checks immediate remote parents. Because
the EUD driver does not register a proxy role switch, does this cause
discovery via the HS path to fail?

While the Type-C Port Controller (hd3ss3220) on the EVK bypasses this failure
by finding the DWC3 role switch via the directly-connected SuperSpeed
endpoint, both the EUD driver and the Type-C controller will independently
acquire and attempt to control the same DWC3 role switch.

Since the EUD driver unconditionally requests its interrupt handlers during
probe, will an EUD disconnect event force the role switch to USB_ROLE_HOST,
clobbering the Type-C controller's state without synchronization and
breaking standard OTG functionality?

> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi

[ ... ]

> @@ -4003,6 +4003,32 @@ opp-384000000 {
>  			};
>  		};
>  
> +		eud: eud@88e1000 {
> +			compatible = "qcom,sc7280-eud", "qcom,eud";

Device Tree binding rules for Qualcomm platforms strongly require providing
the exact SoC-specific compatible string first.

Should this include "qcom,sa8775p-eud" before the fallback compatibles to
allow for future SoC-specific driver quirks?

> +			reg = <0 0x88e1000 0 0x2000>,
> +				<0 0x88e3000 0 0x1000>;
> +			interrupts-extended = <&pdc 11 IRQ_TYPE_LEVEL_HIGH>;

Hardware controllers that depend on board-level physical routing (such as
the EUD, which requires Type-C connector OF graph wiring) are typically
disabled by default in the SoC .dtsi file.

Leaving the eud node globally enabled in lemans.dtsi means the qcom_eud
driver will unnecessarily probe on all downstream SA8775P boards, consuming
resources for unwired hardware.

Should this default to status = "disabled"; here and be explicitly overridden
in lemans-evk.dts?

> +
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +			port@0 {
> +					reg = <0>;
> +
> +					eud_ep: endpoint {
> +					};
> +			};

This isn't a bug, but there is irregular indentation here. The port@0
block and its closing brace use 3 tabs, while the reg assignment uses 5 tabs,
misaligning it with the correctly formatted port@1 block below.

> +
> +				port@1 {
> +					reg = <1>;
> +
> +					eud_con: endpoint {
> +					};
> +				};
> +			};
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512091422.1395490-1-akash.kumar@oss.qualcomm.com?part=1