Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] kexec: missing hardware quiesce and DMA halt in rocket_shutdown --
commit a41629401e441e7353babe8449ad03dc39082ce0 Author: Igor Paunovic <[email protected]> accel/rocket: restore the NPU clock boot rate before powering the cores down This commit records the initial NPU clock rate at probe and restores it during runtime suspend when the last core goes away. It also introduces a shutdown hook to restore the rate before system reboot or kexec, ensuring the hardware does not fault when the domain is subsequently powered back on. > diff --git a/drivers/accel/rocket/rocket_drv.c > b/drivers/accel/rocket/rocket_drv.c > --- a/drivers/accel/rocket/rocket_drv.c > +++ b/drivers/accel/rocket/rocket_drv.c [ ... ] > +/* > + * A kexec hands the next kernel whatever rate is set here, and that kernel > + * will power the islands up before it looks at the clock. > + */ > +static void rocket_shutdown(struct platform_device *pdev) > +{ > + struct rocket_device *rdev = dev_get_drvdata(&pdev->dev); > + int core; > + > + if (!rdev) > + return; > + > + core = find_core_for_dev(&pdev->dev); > + if (core >= 0) > + rocket_npu_restore_boot_rate(&rdev->cores[core]); [Severity: High] Does this code leave the hardware executing active jobs and performing DMA? If the system reboots or executes a kexec while the NPU is actively executing a job, lowering the clock rate here does not halt the hardware or stop active jobs. Because this is a platform device, there is no automatic bus-master clearing. Can this lead to the NPU continuing to perform asynchronous DMA into memory while the new kernel boots, potentially causing memory corruption or fatal bus faults? Should the driver explicitly halt jobs, mask DMA, and reset the core (for example, via rocket_core_reset) before returning from this shutdown hook? > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8
