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

Calling regcache_sync() while cache_only is enabled is invalid API
usage, since writes are intentionally kept in the cache and cannot
be synchronized to hardware.
Document that callers must disable cache_only before calling
regcache_sync(), and reject incorrect usage with a WARN_ON() and
-EINVAL.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 drivers/base/regmap/regcache.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index 96cdae25b9c4..d786cc8bf4d8 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -397,6 +397,10 @@ static int rbtree_all(const void *key, const struct rb_node *node)
  * volatile.  In general drivers can choose not to use the provided
  * syncing functionality if they so require.
  *
+ * This pushes cached changes made while cache_only (e.g. suspend) down
+ * to hardware. The caller must clear cache_only first, or writes will
+ * only update the cache.
+ *
  * Return a negative value on failure, 0 on success.
  */
 int regcache_sync(struct regmap *map)
@@ -411,6 +415,9 @@ int regcache_sync(struct regmap *map)
 	if (WARN_ON(map->cache_type == REGCACHE_NONE))
 		return -EINVAL;
 
+	if (WARN_ON(map->cache_only))
+		return -EINVAL;
+
 	BUG_ON(!map->cache_ops);
 
 	map->lock(map->lock_arg);
-- 
2.43.0

On Wed, Jul 15, 2026 at 12:21:00PM +0700, phucduc.bui@gmail.com wrote:

> @@ -411,6 +415,9 @@ int regcache_sync(struct regmap *map)
>  	if (WARN_ON(map->cache_type == REGCACHE_NONE))
>  		return -EINVAL;
>  
> +	if (WARN_ON(map->cache_only))
> +		return -EINVAL;
> +
>  	BUG_ON(!map->cache_ops);
>  
>  	map->lock(map->lock_arg);

The check needs to be done under lock otherwise some other thread could
come in and put the regmap into cache only mode between the check and
when we take the lock.

We also need a similar check in regcache_sync_region().

Hi Mark,

Thank you for your review.

>
> The check needs to be done under lock otherwise some other thread could
> come in and put the regmap into cache only mode between the check and
> when we take the lock.
>
> We also need a similar check in regcache_sync_region().

I'll move the check under the lock for v2, and add the same check to
regcache_sync_region() as well.

On top of that, I'd like to ask about a design question:
Should regcache_sync() set map->cache_only = true again if it fails
partway through,
or should we leave it to the caller to call regcache_cache_only() themselves?

If we leave it to the caller, should we also update the function's
documentation
to make clear that after a failed sync, the state of the registers is no longer
guaranteed to match the cache, and that further register access should be
done carefully , and that calling regcache_cache_only() is recommended to
keep the device in a safe/consistent state?

Best regards,
Phuc

On Thu, Jul 16, 2026 at 05:06:12PM +0700, Bui Duc Phuc wrote:

> On top of that, I'd like to ask about a design question:
> Should regcache_sync() set map->cache_only = true again if it fails
> partway through,
> or should we leave it to the caller to call regcache_cache_only() themselves?

That's for the caller.

> If we leave it to the caller, should we also update the function's
> documentation
> to make clear that after a failed sync, the state of the registers is no longer
> guaranteed to match the cache, and that further register access should be
> done carefully , and that calling regcache_cache_only() is recommended to
> keep the device in a safe/consistent state?

I'd have hoped it'd be fairly obvious that the device is in an
indeterminate state after a failed sync, TBH if I/O isn't working
recovery options are going to be *super* limited.

Hi Mark,

Thanks for the clarification.

>
> That's for the caller.
>

Understood. I'll keep the current behavior and leave the error
handling to the caller.

> I'd have hoped it'd be fairly obvious that the device is in an
> indeterminate state after a failed sync, TBH if I/O isn't working
> recovery options are going to be *super* limited.

I won't make any documentation changes.

Best regards,
Phuc