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

[Thinh Nguyen]

On Tue, Feb 10, 2026, Votokina Victoria wrote:
> 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)

Can clk_prepare_enable() actually return -EPROBE_DEFER in this context?
Have you verified the AM62 platform implementation to determine if there
are any dependencies that could cause deferral even after successfully
obtaining the refclk handle? What other error codes might be returned?

> 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.

Suspicion alone is insufficient justification. I need you to provide a
definitive analysis of the possible error conditions by auditing the
AM62 platform's clk_prepare_enable() implementation.

> 
> 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.
> 

For submissions based solely on compilation testing, I cannot accept
changes founded on incomplete analysis, especially patches carrying a
"Fixes" tag, which require thorough investigation and concrete evidence
of the issue being addressed.

BR,
Thinh