On 07-Oct-26 12:38 PM, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
to consider:
- [High] accel/ivpu: IRQ disable depth leak in FW_TEST mode due to unbalanced
disable_irq()
--
commit 03c00af9f26af13756e29777951597b1aedc577d
Author: Andrzej Kacprowski <[email protected]>
accel/ivpu: Improve IVPU_TEST_MODE_FW_TEST handling
When driver is operating in IVPU_TEST_MODE_FW_TEST debug mode
it should boot the firmware, but skip communication with
the firmware. There is no need to enable interrupts or send messages.
The output of the firmware test will be available in the
firmware log.
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 647684219e9d3..d66abf645e7b9 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
[ ... ]
@@ -487,6 +484,9 @@ int ivpu_boot(struct ivpu_device *vdev)
return ret;
}
+ if (ivpu_test_mode & IVPU_TEST_MODE_FW_TEST)
+ return 0;
+
[Severity: High]
Does this early return cause an IRQ disable depth leak?
Since ivpu_boot() skips the call to enable_irq() when IVPU_TEST_MODE_FW_TEST
is enabled, it breaks the enable/disable symmetry.
Later, during teardown paths like ivpu_prepare_for_reset(), disable_irq()
is called unconditionally:
drivers/accel/ivpu/ivpu_drv.c:ivpu_prepare_for_reset() {
...
disable_irq(vdev->irq);
...
}
Calling disable_irq() without a matching enable_irq() increments the disable
depth on each suspend/resume cycle. If the user dynamically disables FW_TEST
mode via sysfs, subsequent enable_irq() calls will only decrement the
accumulated depth by 1, leaving the physical interrupt permanently disabled.
ret = ivpu_wait_for_ready(vdev);
if (ret) {
ivpu_err(vdev, "Failed to boot the firmware: %d\n", ret);
Will be addressed in v2 patch.
