Re: [PATCH 09/11] regulator: db8500-prcmu: Remove EPOD regulators

[sashiko-bot@kernel.org]

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 <linusw@kernel.org>

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 <linusw@kernel.org>

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ux500-power-domains-v7-1-v1-0-eb5e50b1a588@kernel.org?part=9