linux/drivers/base/regmap/regcache.c, branch v6.4

regmap: regcache: Don't sync read-only registers

2023-06-13T12:15:00Z

regcache_maple_sync() tries to sync all cached values no matter whether it's writable or not. OTOH, regache_sync_val() does care the wrtability and returns -EIO for a read-only register. This results in an error message like: snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2f0009. -5 and the sync loop is aborted incompletely. This patch adds the writable register check to regcache_sync_val() for addressing the bug above. Note that, although we may add the check in the caller side (regcache_maple_sync()), here we put in regcache_sync_val(), so that a similar case like this can be avoided in future. Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache") Link: https://lore.kernel.org/r/877cs7g6f1.wl-tiwai@suse.de Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20230613112240.3361-1-tiwai@suse.de Signed-off-by: Mark Brown

regmap: Add maple tree based register cache

2023-04-03T11:53:44Z

The current state of the art for sparse register maps is the rbtree cache. This works well for most applications but isn't always ideal for sparser register maps since the rbtree can get deep, requiring a lot of walking. Fortunately the kernel has a data structure intended to address this very problem, the maple tree. Provide an initial implementation of a register cache based on the maple tree to start taking advantage of it. The entries stored in the maple tree are arrays of register values, with the maple tree keys holding the register addresses. We store data in host native format rather than device native format as we do for rbtree, this will be a benefit for devices where we don't marshal data within regmap and simplifies the code but will result in additional CPU overhead when syncing the cache on devices where we do marshal data in regmap. This should work well for a lot of devices, though there's some additional areas that could be looked at such as caching the last accessed entry like we do for rbtree and trying to minimise the maple tree level locking. We should also use bulk writes rather than single register writes when resyncing the cache where possible, even if we don't store in device native format. Very small register maps may continue to to better with rbtree longer term. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230325-regcache-maple-v3-2-23e271f93dc7@kernel.org Signed-off-by: Mark Brown

regmap: Factor out single value register syncing

2023-04-03T11:53:43Z

In order to support sparse caches that don't store data in raw format factor out the parts of the raw block sync implementation that deal with writing a single register via _regmap_write(). Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230325-regcache-maple-v3-1-23e271f93dc7@kernel.org Signed-off-by: Mark Brown

regmap: Removed compressed cache support

2023-03-29T11:41:03Z

The compressed register cache support has assumptions that make it hard to cover in testing, mainly that it requires raw registers defaults be provided. Rather than either address these assumptions or leave it untested by the forthcoming KUnit tests let's remove it, the use case is quite thin and there are no current users. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230324-regcache-lzo-v1-1-08c5d63e2a5e@kernel.org

regmap: Clarify error for unknown cache types

2023-03-27T00:42:31Z

The error message printed when we fail to locate the cache type the map requested says it can't find a compress type rather than a cache type, fix that. Since the compressed type is the only one currently compiled conditionally it's likely to be the missing type but that might not always be true and is still unclear. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230324-regcache-unknown-v1-1-80deecbf196b@kernel.org

regmap: Handle sparse caches in the default sync

2023-03-27T00:42:26Z

If there is no cache entry available we will get -ENOENT from the cache implementation, handle this gracefully and skip rather than treating it as an error. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230325-regcache-sparse-sync-v1-1-2a890239d061@kernel.org

regmap: cache: Silence checkpatch warning

2023-03-13T14:09:51Z

checkpatch.pl warned: WARNING: ENOSYS means 'invalid syscall nr' and nothing else Align the return value to regcache_drop_region(). Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20230313071812.13577-2-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown

regmap: cache: Return error in cache sync operations for REGCACHE_NONE

2023-03-13T14:08:53Z

There is no sense in doing a cache sync on REGCACHE_NONE regmaps. Instead of panicking the kernel due to missing cache_ops, return an error to client driver. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20230313071812.13577-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown

regmap: cache: Add extra parameter check in regcache_init

2022-06-30T12:33:21Z

When num_reg_defaults > 0 but reg_defaults is NULL, there will be a NULL pointer exception. Current code has no such usage, but as additional hardening, also check this to prevent any chance of crashing. Signed-off-by: Schspa Shi Link: https://lore.kernel.org/r/20220629130951.63040-1-schspa@gmail.com Signed-off-by: Mark Brown

regmap: Don't warn about cache only mode for devices with no cache

2022-06-27T12:21:59Z

For devices with no cache it can make sense to use cache only mode as a mechanism for trapping writes to hardware which is inaccessible but since no cache is equivalent to cache bypass we force such devices into bypass mode. This means that our check that bypass and cache only mode aren't both enabled simultanously is less sensible for devices without a cache so relax it. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220622171723.1235749-1-broonie@kernel.org Signed-off-by: Mark Brown