Re: [PATCH] remoteproc: mediatek: Break lock dependency to `prepare_lock`

[Tzung-Bi Shih <tzungbi@kernel.org>]

On Sat, Jan 10, 2026 at 01:10:22PM -0600, Bjorn Andersson wrote:
> On Mon, Dec 29, 2025 at 04:31:46AM +0000, Tzung-Bi Shih wrote:
> > `scp_ipi_send` acquires `prepare_lock` via `clk_prepare_enable` while
> 
> Please suffix functions with (), instead of treating it just like any
> other `symbol`, this makes it easier to see what is a function and what
> is an object/variable.
> 
> > the caller often holds `ec_dev->lock` (e.g., `cros_ec_cmd_xfer`).  The
> > reverse dependency exists where `clk_prepare` can trigger operations
> > that eventually take `ec_dev->lock` (e.g., via sysfs/regulator/genpd).
> 
> Can you please expand this explanation slightly. You're hinting that
> there's an ABBA issue, but you're leaving it to the reader to know/guess
> what that issue is.
> 
> I believe you have some concrete case where this is a probelm, please
> include this, if nothing else as an example.
> 
> > 
> > Move clock prepare / unprepare operations to remoteproc prepare() /
> > unprepare() callbacks to break the lock dependency from `ec_dev->lock`
> > to `prepare_lock`.
> 
> Please expand this with an argumentation that the prolonged "prepared
> time" will not have any negative impact.
> 
> > 
> > This breaks the dependency chain in the lockdep report:
> > > WARNING: possible circular locking dependency detected
> > > ...
> > > the existing dependency chain (in reverse order) is:
> > > ...
> > > -> #0 (prepare_lock){+.+.}-{3:3}:
> > >        __lock_acquire
> > >        lock_acquire
> > >        __mutex_lock_common
> > >        mutex_lock_nested
> > >        clk_prepare
> > >        scp_ipi_send [mtk_scp_ipi]
> > >        scp_send_ipi [mtk_scp]
> > >        mtk_rpmsg_send [mtk_rpmsg]
> > >        rpmsg_send [rpmsg_core]
> > >        cros_ec_pkt_xfer_rpmsg [cros_ec_rpmsg]
> 
> If this is the AB case, can you please include a stack for the BA case
> as well in the commit message?
> 
> 
> With these things clarified, I expect that your patch is the correct way
> to solve the problem.

An attempt: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org