Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Hardware interrupts are unmasked before the OS interrupt handler is successfully registered, risking an unhandled IRQ storm. -- commit 4e867b9890a5ecc61feefa09f80bbc3aaddcd675 Author: Boris Brezillon <[email protected]> drm/panthor: Replace the panthor_irq macro machinery by inline helpers This commit removes the panthor_irq macro generation logic and replaces it with inline helpers to rely on compiler optimization. It also refactors the prototype of IRQ handlers to take struct panthor_irq instead of struct panthor_device. > diff --git a/drivers/gpu/drm/panthor/panthor_device.h > b/drivers/gpu/drm/panthor/panthor_device.h > --- a/drivers/gpu/drm/panthor/panthor_device.h > +++ b/drivers/gpu/drm/panthor/panthor_device.h [ ... ] > +static inline int > +panthor_irq_request(struct panthor_device *ptdev, struct panthor_irq *pirq, > + int irq, u32 mask, void __iomem *iomem, const char *name, > + irqreturn_t (*threaded_handler)(int, void *data)) > +{ [ ... ] > + panthor_irq_resume(pirq); > + return devm_request_threaded_irq(ptdev->base.dev, irq, > + panthor_irq_default_raw_handler, > + threaded_handler, > + IRQF_SHARED, full_name, pirq); > } [Severity: High] This is a pre-existing issue, but by calling panthor_irq_resume() before devm_request_threaded_irq(), does this leave a window where the hardware interrupt is unmasked before the OS handler is successfully registered? If the device asserts an interrupt before the handler is fully registered, or if devm_request_threaded_irq() fails entirely and returns without subsequently masking the hardware interrupt, could this unhandled interrupt trigger an IRQ storm? This might cause the kernel's irq core to permanently disable the shared interrupt line. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
