From: bui duc phuc <phucduc.bui@gmail.com>

Prevent _regmap_update_bits() from accessing hardware when the register
map is in cache-only mode.

Unlike regmap_raw_read() and _regmap_read(), the volatile
_regmap_update_bits() fast path bypasses the cache_only check. This can
result in unexpected hardware accesses while the device is suspended.

Return -EBUSY to ensure behavior is consistent with other cache-only
access paths.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Compile-tested only.

 drivers/base/regmap/regmap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index b2b26f07f4e3..e6e022b02637 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -3257,6 +3257,9 @@ static int _regmap_update_bits(struct regmap *map, unsigned int reg,
 		*change = false;
 
 	if (regmap_volatile(map, reg) && map->reg_update_bits) {
+		if (map->cache_only)
+			return -EBUSY;
+
 		reg = regmap_reg_addr(map, reg);
 		ret = map->reg_update_bits(map->bus_context, reg, mask, val);
 		if (ret == 0 && change)
-- 
2.43.0

On Thu, 28 May 2026 12:32:04 +0700, phucduc.bui@gmail.com wrote:
> regmap: reject volatile update_bits() in cache-only mode

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-7.1

Thanks!

[1/1] regmap: reject volatile update_bits() in cache-only mode
      https://git.kernel.org/broonie/regmap/c/006c66d1d52f

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Hi all,

Thanks for the review and for applying the patch.

Best regards,
Phuc

On Thu, May 28, 2026 at 12:32:04PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
> 
> Prevent _regmap_update_bits() from accessing hardware when the register
> map is in cache-only mode.
> 
> Unlike regmap_raw_read() and _regmap_read(), the volatile
> _regmap_update_bits() fast path bypasses the cache_only check. This can
> result in unexpected hardware accesses while the device is suspended.
> 
> Return -EBUSY to ensure behavior is consistent with other cache-only
> access paths.
> 
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> 
> Compile-tested only.

So this isn't a real bug that you have found and tested this fix
resolves?  How was this "found"?

Please submit stuff that actually is verified to resolve a real issue.

thanks,

greg k-h

Hi Greg,

Thank you for the feedback.

>
> So this isn't a real bug that you have found and tested this fix
> resolves?  How was this "found"?
>
> Please submit stuff that actually is verified to resolve a real issue.
>

This issue was not triggered by a real hardware failure that I could
reproduce locally.

The investigation started from a previous cleanup patch:
https://lore.kernel.org/all/20260513105003.81880-1-phucduc.bui@gmail.com/

During the review, Sashiko bot pointed out that there could be unsafe
register accesses while the device is runtime-suspended, which could lead
to hangs on some platforms if access occurs before the device is resumed.
The review suggested ensuring the device is runtime-resumed first, for
example by using pm_runtime_get_sync().

Based on that feedback, I prepared this patch:
https://lore.kernel.org/all/20260522095401.72915-3-phucduc.bui@gmail.com/

I then spent some time investigating if there was a better architectural
approach, and summarized my findings in this discussion:
https://lore.kernel.org/all/CAABR9nFdvh9nfa03oxFLgD2WUj4LyHP8T77xKno9wjiQZ48h+Q@mail.gmail.com/

While reviewing how `cache_only` handling is implemented across regmap
accesses, I noticed a logical inconsistency: the volatile fast-path in
_regmap_update_bits() completely bypasses the `cache_only` check, unlike
_regmap_read() and regmap_raw_read().

I submitted this patch to close that loophole and ensure consistent behavior
across the framework. However, I completely understand your point that this
has not been verified against an actual observed failure on real hardware.

Thanks for the clarification.

Best regards,
Phuc