mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v4 0/2] reset: Serialize shared resets whose ops may sleep
@ 2026-10-23  7:16 shengjiu.wang
  2026-10-23  7:16 ` [PATCH v4 1/2] reset: core: Serialize concurrent deassert/reset of shared resets shengjiu.wang
  2026-10-23  7:16 ` [PATCH v4 2/2] reset: gpio: Set can_sleep for the shared reset serialization shengjiu.wang
  0 siblings, 2 replies; 5+ messages in thread
From: shengjiu.wang @ 2026-10-23  7:16 UTC (permalink / raw)
  To: p.zabel, krzk, hansg, linux-kernel, broonie, alvin.sipraga

From: Shengjiu Wang <shengjiu.wang@nxp.com>

For a shared reset only the first caller runs the hardware op; the others
bump the refcount and return. When the op can sleep, a concurrent caller can
return before the first caller's op has finished and then touch hardware
still in reset.

Serialize the shared refcount update and the hardware op under a new
per-control mutex, but only for providers that opt in via a new
reset_controller_dev::can_sleep flag. Providers that leave it clear keep the
lockless path, so atomic callers are unaffected. reset-gpio is the first
provider to set the flag.

Changes in v4:
- Move the can_sleep/mutex description to the top of the core commit message.
- Also serialize reset_control_assert() under shared_lock.
- Split the reset-gpio can_sleep assignment into its own patch (2/2).
- Fix a kerneldoc typo; drop the Assisted-by trailer.
- Drop the Fixes: tag, present as a correctness improvement.

Changes in v3:
- Drop the reset_control_reset_atomic()/reset_control_deassert_atomic()
  variants and their reset.h declarations/stubs; gate the mutex on
  rcdev->can_sleep instead, so non-sleeping controllers keep the lockless
  path and need no new API.
- Use a dedicated rstc->shared_lock taken inside the SRCU read-side section
  instead of reusing rstc->lock before SRCU.
- Set can_sleep in reset-gpio; no other provider is converted.
- Drop the lockdep_assert_not_held() additions and the reset.rst / kerneldoc
  text about sleeping-vs-atomic variants.
  
Changes in v2:
- Serialize only the shared may-sleep path under rstc->lock (taken before
  SRCU to match reset_control_acquire()'s order); exclusive path stays
  lockless, and reset_control_assert() is left unchanged.
- Add lockless reset_control_reset_atomic()/reset_control_deassert_atomic()
  for atomic callers; gate the mutex on can_sleep so no shared consumer is
  regressed and so it works on all configs.
- Factor the body into __reset_control_*()/__reset_control_*_locked()
  helpers, and lockdep_assert_not_held() at each lock site to catch a
  controller op re-entering the API on the same control.
- Declare the new variants and stubs in reset.h, and document the sleeping
  vs atomic variants in the kerneldoc and reset.rst.

Shengjiu Wang (2):
  reset: core: Serialize concurrent deassert/reset of shared resets
  reset: gpio: Set can_sleep for the shared reset serialization

 drivers/reset/core.c             | 205 ++++++++++++++++++++-----------
 drivers/reset/reset-gpio.c       |   1 +
 include/linux/reset-controller.h |   4 +
 3 files changed, 139 insertions(+), 71 deletions(-)

-- 
2.34.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-10-23  8:44 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-23  7:16 [PATCH v4 0/2] reset: Serialize shared resets whose ops may sleep shengjiu.wang
2026-10-23  7:16 ` [PATCH v4 1/2] reset: core: Serialize concurrent deassert/reset of shared resets shengjiu.wang
2026-10-23  8:42   ` Alvin Šipraga
2026-10-23  7:16 ` [PATCH v4 2/2] reset: gpio: Set can_sleep for the shared reset serialization shengjiu.wang
2026-10-23  8:43   ` Alvin Šipraga

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®