Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] accel/ivpu: PM runtime autosuspend loop in FW_TEST mode --
commit e12f731149f041dc1d9f11e61a8bd4c155f14399 Author: Andrzej Kacprowski <[email protected]> accel/ivpu: Improve IVPU_TEST_MODE_FW_TEST handling This commit modifies ivpu_boot() to exit early when IVPU_TEST_MODE_FW_TEST is enabled, bypassing post-boot initialization. This avoids sending an IPC message that was timing out since the firmware boot is not fully waited for in this mode. > diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c > index 0f215392d42de..fee1dde0b7467 100644 > --- a/drivers/accel/ivpu/ivpu_drv.c > +++ b/drivers/accel/ivpu/ivpu_drv.c > @@ -498,6 +498,9 @@ int ivpu_boot(struct ivpu_device *vdev) > ivpu_ipc_enable(vdev); > > if (!ivpu_fw_is_warm_boot(vdev)) { > + if (ivpu_test_mode & IVPU_TEST_MODE_FW_TEST) > + return 0; > + [Severity: High] Does this early return shift the IPC timeout into the runtime PM autosuspend path? If driver probe succeeds because of this early return, PM runtime autosuspend will be enabled. After the autosuspend delay, won't ivpu_pm_runtime_suspend_cb() unconditionally attempt to send an IPC message? drivers/accel/ivpu/ivpu_pm.c:ivpu_pm_runtime_suspend_cb() { ... ret_d0i3 = ivpu_jsm_pwr_d0i3_enter(vdev); if (ret_d0i3) ivpu_err(vdev, "Failed to prepare for d0i3: %d\n", ret_d0i3); ... if (!is_idle || ret_d0i3) { ivpu_err(vdev, "Forcing cold boot due to previous errors\n"); atomic_inc(&vdev->pm->reset_counter); ivpu_dev_coredump(vdev); ivpu_pm_prepare_cold_boot(vdev); } ... } Since the firmware is unresponsive in IVPU_TEST_MODE_FW_TEST mode, this IPC message will inevitably time out. Could this lead to an inescapable background loop of timeouts, coredumps, and resets? > ret = ivpu_pm_dct_init(vdev); > if (ret) > goto err_disable_ipc; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
