All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	linux-remoteproc@vger.kernel.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] remoteproc: mediatek: Break lock dependency to `prepare_lock`
Date: Tue, 6 Jan 2026 03:13:22 +0000	[thread overview]
Message-ID: <aVx90sSLgRzSPazF@google.com> (raw)
In-Reply-To: <aVw4QUp6j4vBOrOF@p14s>

On Mon, Jan 05, 2026 at 03:16:33PM -0700, Mathieu Poirier 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
> > 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).
> 
> What operation would that be?  Please be specific so that I can trace the code.

The chain is discovered by lockdep: &ec_dev->lock -> prepare_lock ->
&genpd->mlock -> ... -> kn->active#2 -> &ec_dev->lock.

-> #6 (&ec_dev->lock){+.+.}-{3:3}:
       __mutex_lock_common
       mutex_lock_nested
       cros_ec_cmd_xfer
       cros_ec_cmd_xfer_status
       cros_usbpd_charger_get_port_status
       cros_usbpd_charger_get_prop
       power_supply_get_property
       power_supply_show_property
       power_supply_uevent
       dev_uevent
       uevent_show
       dev_attr_show
       sysfs_kf_seq_show
       kernfs_seq_show
       seq_read_iter
       kernfs_fop_read_iter
       vfs_read
-> #5 (kn->active#2){++++}-{0:0}:
       kernfs_drain
       __kernfs_remove
       kernfs_remove_by_name_ns
       sysfs_remove_file_ns
       device_del
       __device_link_del
       device_links_driver_bound
       driver_bound
-> #4 (device_links_lock){+.+.}-{3:3}:
       __mutex_lock_common
       mutex_lock_nested
       device_link_remove
       _regulator_put
       regulator_put
       devm_regulator_release
...
-> #1 (&genpd->mlock){+.+.}-{3:3}:
       __mutex_lock_common
       mutex_lock_nested
       genpd_lock_mtx
       genpd_runtime_resume
       __rpm_callback
       rpm_callback
       rpm_resume
       __pm_runtime_resume
       clk_core_prepare
       clk_prepare
-> #0 (prepare_lock){+.+.}-{3:3}:
       __lock_acquire
       lock_acquire
       __mutex_lock_common
       mutex_lock_nested
       clk_prepare
       scp_ipi_send
       scp_send_ipi
       mtk_rpmsg_send
       rpmsg_send
       cros_ec_pkt_xfer_rpmsg

> > Move clock prepare / unprepare operations to remoteproc prepare() /
> > unprepare() callbacks to break the lock dependency from `ec_dev->lock`
> > to `prepare_lock`.
> 
> With the information presented to me, I don't see how doing that changes
> anything.  @prepare_lock is simply held for a longer period of time.  

In prepare() callback, the clock becomes prepared and prepare_lock won't be
held after that.


  reply	other threads:[~2026-01-06  3:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-29  4:31 [PATCH] remoteproc: mediatek: Break lock dependency to `prepare_lock` Tzung-Bi Shih
2026-01-05 22:16 ` Mathieu Poirier
2026-01-06  3:13   ` Tzung-Bi Shih [this message]
2026-01-06 17:10     ` Mathieu Poirier
2026-01-07  2:21       ` Tzung-Bi Shih
2026-01-07 15:29         ` Mathieu Poirier
2026-01-10 19:10 ` Bjorn Andersson
2026-01-12 11:13   ` Tzung-Bi Shih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aVx90sSLgRzSPazF@google.com \
    --to=tzungbi@kernel.org \
    --cc=andersson@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=matthias.bgg@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.