Re: [PATCH] regmap: reject volatile update_bits() in cache-only mode

[Bui Duc Phuc]

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@xxxxxxxxx/

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@xxxxxxxxx/

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@xxxxxxxxxxxxxx/

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