[lvc-project] [PATCH] usb: dwc3: am62: handle usb2_refclk enable failures

Votokina Victoria Victoria.Votokina at kaspersky.com
Tue Feb 10 12:36:59 MSK 2026


Thinh,

This was reported by static analysis (SVACE), not from a runtime
failure I could reproduce. The analyzer flagged that
clk_prepare_enable() return value is ignored in dwc3_ti_init().
Since clk_prepare_enable() can legitimately fail (incl. -EPROBE_DEFER)
and the driver continues to touch controller/PHY registers afterwards,
this can lead to operating the IP in an undefined state.
Many drivers treat “enable clock failed” as a hard error/deferral
and bail out; that’s why the checker considers the pattern suspicious.

Regarding dwc3_ti_resume_common(): you’re right — returning
dwc3_ti_init() directly changes the current logic and is not correct
as-is. The intent was only to check and propagate the error from
dwc3_ti_init() when power/context was lost, while keeping the remaining
resume steps (e.g. wakeup handling) intact. 
I’ll respin this so it becomes:

ret = dwc3_ti_init(am62); if (ret) return ret; 
and then continue with the existing flow.

I also suggest enabling usb2_refclk before touching USBSS_DEBUG_CFG.
Accessing USBSS/DWC3 registers assumes the refclk is active;
if clk_prepare_enable() fails (e.g. -EPROBE_DEFER), returning early
avoids partially programming the block while clocks are off.
This follows the usual “clock first, registers second” ordering used
across drivers.

I tested compile/build only; I don’t have AM62 hardware to validate
runtime behavior. If you prefer, I can drop any changes beyond 
return-value checking and keep the patch minimal.

Thanks,
Victoria



More information about the lvc-project mailing list