linux-kernel - Re: [PATCH] usb: dwc3: am62: handle usb2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260210093659.2268056-1-Victoria.Votokina@kaspersky.com>
Date: Tue, 10 Feb 2026 12:36:59 +0300
From: Votokina Victoria <Victoria.Votokina@...persky.com>
To: <thinh.nguyen@...opsys.com>
CC: <Victoria.Votokina@...persky.com>, <gregkh@...uxfoundation.org>,
	<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>,
	<lvc-project@...uxtesting.org>, <rogerq@...nel.org>
Subject: Re: [PATCH] usb: dwc3: am62: handle usb2_refclk enable failures

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