Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Calling pm_runtime_get_sync() and pm_runtime_put_sync_suspend() on `lcla_dev` from the DMA hardirq handler causes a 'sleeping in atomic context' bug. -- commit faf19ae1be6f68a94634761ce6a55206f7f124da Author: Linus Walleij <[email protected]> regulator: db8500-prcmu: Remove EPOD regulators Remove the obsolete DB8500 PRCMU regulator drivers. > Drop the regulator build hooks now that EPODs are power domains. [Severity: High] This isn't a bug introduced by this patch, but since the EPODs are now power domains, is it safe to use them from atomic contexts? An earlier patch in this series transitioned the LCLA SRAM to use power domains, but the DMA interrupt handler d40_handle_interrupt() acquires spinlocks (base->interrupt_lock and d40c->lock) before taking this path: d40_handle_interrupt() dma_tc_handle() d40_queue_start() d40_transfer_runtime_get() pm_runtime_get_sync(base->lcla_dev) d40_transfer_runtime_put() pm_runtime_put_sync_suspend(base->lcla_dev) Because base->lcla_dev is tied to the ESRAM34 generic PM domain and is not marked IRQ-safe (GENPD_FLAG_IRQ_SAFE), its callbacks are invoked, leading to sleeping operations while holding spinlocks: pd_power_off() guard(mutex)(&ux500_pd_lock) db8500_prcmu_set_epod() mutex_lock(&mb2_transfer.lock) Could this lead to scheduling while atomic bugs and deadlocks? > Keep the MFD cell around because a later patch reuses it for a > small compatibility regulator driver. > > Assisted-by: Codex:gpt-5-5 > Signed-off-by: Linus Walleij <[email protected]> [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=9
