Re: [PATCH] regcache: disable cache_only before rewriting paging registers

[Bui Duc Phuc]

Hi Mark,

Thanks for the explanation.

>
> You might not bother setting cache only in the suspend/resume path if
> you know nothing else from the driver will touch the device until resume
> is completed, something else might block anything that would try to
> write.

Going back to the original motivation for this patch, I'm trying to better
understand the intended semantics of regcache_sync().

------------------
if (!map->cache_bypass && !map->defer_caching) {
    ret = regcache_write(map, reg, val);
    if(ret != 0)
           return ret;
    if (map->cache_only) {
           map->cache_dirty = true;
           return 0;
    }
}

ret = map->reg_write(context, reg, val);
----------------------


As described in the commit message, if regcache_sync() is called while
cache_only is still enabled, it can return success even though the cache
and the hardware are still out of sync, with cache_dirty remaining true.

>From the caller's perspective, that seems like a successful synchronization
even though no synchronization actually occurred.

>From your explanation, I understand that some drivers intentionally do
not use cache_only in their suspend/resume paths because another
mechanism guarantees that no register accesses can occur while the
device is suspended.

If that's the case, then it seems that neither of these approaches would
be appropriate:
1. Automatically clearing cache_only before writing the selector register.
2. Making regcache_sync() reject calls when cache_only is still enabled.

Would it then be correct to understand that calling regcache_sync() while
cache_only is still enabled is simply considered incorrect API usage,
and that in such a case the responsibility lies with the caller, rather than
regcache_sync() itself ?
If so, would it make sense to document this requirement explicitly,
or perhaps emit a warning when regcache_sync() is called while
cache_only is still enabled?

Best regards,
Phuc