From: phucduc.bui@gmail.com
To: Mark Brown <broonie@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rafael@kernel.org
Cc: Danilo Krummrich <dakr@kernel.org>,
linux-kernel@vger.kernel.org, driver-core@lists.linux.dev,
bui duc phuc <phucduc.bui@gmail.com>
Subject: [PATCH 0/2] regmap: Improve error handling in regcache_sync()
Date: Mon, 13 Jul 2026 12:03:10 +0700 [thread overview]
Message-ID: <20260713050312.38729-1-phucduc.bui@gmail.com> (raw)
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
While working on a cleanup series converting mutex and spinlock usage
to guard() helpers, I received review feedback that regcache_sync()
still has a goto-based error path.
https://lore.kernel.org/all/95f5d6ec-ecc5-4090-ac04-27cdcdc21b8a@sirena.org.uk/
Since guard() helpers should not be mixed with goto-based cleanup,
I looked into whether the error handling could be simplified.
During that review, I noticed two issues in the current implementation
of regcache_sync():
1. Cache synchronization errors can be overwritten by the result of
selector register updates.
2. cache_dirty is not updated if rewriting a selector register fails,
leaving it inconsistent with the cache and hardware state.
Together, these changes make the failure semantics of regcache_sync()
clearer and eliminate the need for callers to invoke
regcache_mark_dirty() after regcache_sync() fails.
Best regards,
Phuc
bui duc phuc (2):
regcache: Preserve cache synchronization errors in regcache_sync()
regcache: Mark cache dirty if selector register rewrite fails
drivers/base/regmap/regcache.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
--
2.43.0
next reply other threads:[~2026-07-13 5:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 5:03 phucduc.bui [this message]
2026-07-13 5:03 ` [PATCH 1/2] regcache: Preserve cache synchronization errors in regcache_sync() phucduc.bui
2026-07-13 5:03 ` [PATCH 2/2] regcache: Mark cache dirty if selector register rewrite fails phucduc.bui
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=20260713050312.38729-1-phucduc.bui@gmail.com \
--to=phucduc.bui@gmail.com \
--cc=broonie@kernel.org \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
/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.