Re: [PATCH v7 5/8] usb: misc: qcom_eud: improve enable_store API

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The primary hardirq handler sleeps by using `readl_poll_timeout` with a non-zero delay.
--

commit b021d31a749af395e42d221e7a9f69b7a26c01ed
Author: Elson Serrao <elson.serrao@oss.qualcomm.com>

usb: misc: qcom_eud: improve enable_store API

Currently enable_store() allows operations irrespective of the EUD state,
which can result in redundant operations. Avoid this by adding duplicate
state checks to skip requests when EUD is already in the desired state.
Additionally, improve error handling with explicit logging to provide
better feedback.

> diff --git a/drivers/usb/misc/qcom_eud.c b/drivers/usb/misc/qcom_eud.c
> index 45c90d9f3b1f6..07522225a8f89 100644
> --- a/drivers/usb/misc/qcom_eud.c
> +++ b/drivers/usb/misc/qcom_eud.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but can this lead to a panic by sleeping in
a hardirq context?

When the hardware fires an EUD_INT_SAFE_MODE interrupt, the primary
top-half handler handle_eud_irq() calls pet_eud():

drivers/usb/misc/qcom_eud.c:handle_eud_irq() {
	...
	switch (reg & EUD_INT_ALL) {
	case EUD_INT_VBUS:
		usb_attach_detach(chip);
		return IRQ_WAKE_THREAD;
	case EUD_INT_SAFE_MODE:
		pet_eud(chip);
		return IRQ_HANDLED;
	...
}

The function pet_eud() then invokes readl_poll_timeout() with a 1µs delay,
which expands to might_sleep_if(1) and subsequently calls usleep_range():

drivers/usb/misc/qcom_eud.c:pet_eud() {
	...
		/* Detach & Attach pet for EUD */
		writel(0, chip->base + EUD_REG_SW_ATTACH_DET);
		/* Delay to make sure detach pet is done before attach pet */
		ret = readl_poll_timeout(chip->base + EUD_REG_SW_ATTACH_DET,
					reg, (reg == 0), 1, 100);
	...
}

Calling a sleeping function in a hardirq context triggers a
scheduling-while-atomic kernel BUG or panic.

Does this sequence occur when the EUD cable is disconnected in safe mode
and the respective interrupt triggers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831030147.1500616-1-elson.serrao@oss.qualcomm.com?part=5