Re: [PATCH v6 7/9] usb: misc: qcom_eud: fix virtual attach/detach event handling

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The top-half interrupt handler attempts to sleep by calling `readl_poll_timeout()`, which relies on `usleep_range()` and will trigger a scheduling-while-atomic BUG.
- [High] The hardirq handler silently ignores concurrent interrupts because it uses a `switch` statement on a bitmask, falling through to `default` when multiple bits are set.
--

--- Patch [7]: [PATCH v6 7/9] usb: misc: qcom_eud: fix virtual attach/detach event handling ---
Note: The format of this report has been altered to provide a free-form summary of the findings due to recitation restrictions. The inline quoting style has been omitted.

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

usb: misc: qcom_eud: Fix virtual detach USB role
    
This commit fixes the EUD virtual detach handling by setting the USB role
to NONE instead of HOST. This correctly represents the disconnected state
when a virtual detach event occurs.

[Severity: High]
This isn't a bug introduced by this patch, but looking at the top-half
interrupt handler handle_eud_irq() in drivers/usb/misc/qcom_eud.c, it
calls pet_eud() for the EUD_INT_SAFE_MODE case. The pet_eud() function uses
readl_poll_timeout() with a delay of 1us, which relies on usleep_range()
and might sleep. Is it safe to call this sleeping function from a hardirq
context, or should it use readl_poll_timeout_atomic() instead to avoid a
scheduling-while-atomic BUG?

[Severity: High]
This is also a pre-existing issue, but does the switch statement in
handle_eud_irq() in drivers/usb/misc/qcom_eud.c correctly handle concurrent
interrupts? It switches on the bitmask (reg & EUD_INT_ALL). If both
EUD_INT_VBUS and EUD_INT_SAFE_MODE are asserted simultaneously, the value
won't match either case, falling through to the default label and returning
IRQ_NONE without clearing the device interrupt. Could this leave the
interrupts unhandled and potentially lead to an interrupt storm where the
kernel disables the IRQ line?

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