[PATCH v6 0/2] regmap: Introduce validity info for flat cache

Sander Vanheule posted 2 patches 1 month, 2 weeks ago
drivers/base/regmap/internal.h      |  1 +
drivers/base/regmap/regcache-flat.c | 96 +++++++++++++++++++++++++----
drivers/base/regmap/regcache.c      |  1 +
drivers/base/regmap/regmap-kunit.c  | 22 +++++++
include/linux/regmap.h              | 17 +++--
5 files changed, 120 insertions(+), 17 deletions(-)
[PATCH v6 0/2] regmap: Introduce validity info for flat cache
Posted by Sander Vanheule 1 month, 2 weeks ago
The flat cache behaves differently from the other caches, in that it has
no way of knowing if a cache entry is valid. Initialization has to
happen either by providing defaults, by loading defaults from hardware
(via num_reg_defaults_raw), or by performing the required register
writes. This difference in behavior may be unexpected to the user [1].

To provide feature parity between the different cache types, a new
variant of the flat cache is proposed. This allows user to migrate to
the sparse flat cache (or a different cache type) when possible.

In order to encourage migration, the second patch adds a new warning to
inform the user of their suspicious cache.

[1] https://lore.kernel.org/linux-gpio/e461ca08-ad28-44fe-85f1-afe332c1d43d@topic.nl/
---
Changes since v5:
Link: https://lore.kernel.org/lkml/20251023135032.229511-1-sander@svanheule.net/
- zero-initialize cache for compatibiliy
- Update regcache_type comment to document the difference between the
  flat caches

Changes since v4:
Link: https://lore.kernel.org/lkml/20251022200408.63027-1-sander@svanheule.net/
- Improve formatting of log message
- Reduce logging to not confuse KUnit test result parser
- Add sparse flat cache to all KUnit config lists

Changes since v3:
Link: https://lore.kernel.org/lkml/20250109180256.6269-1-sander@svanheule.net/
- Split changes into two patches to provide a migration path

Changes since v2:
Link: https://lore.kernel.org/all/20250109151106.38645-1-sander@svanheule.net/
- Complete renaming of index variables so regcache-flat.c compiles again

Changes since v1:
Link: https://lore.kernel.org/all/20241231100256.194753-1-sander@svanheule.net/
- Fix off-by-one in length for bitmap_clear()
- Add REGCACHE_FLAT to the list of sparse cache tests

Sander Vanheule (2):
  regmap: add flat cache with sparse validity
  regmap: warn users about uninitialized flat cache

 drivers/base/regmap/internal.h      |  1 +
 drivers/base/regmap/regcache-flat.c | 96 +++++++++++++++++++++++++----
 drivers/base/regmap/regcache.c      |  1 +
 drivers/base/regmap/regmap-kunit.c  | 22 +++++++
 include/linux/regmap.h              | 17 +++--
 5 files changed, 120 insertions(+), 17 deletions(-)

-- 
2.51.0
Re: [PATCH v6 0/2] regmap: Introduce validity info for flat cache
Posted by Mark Brown 1 month, 2 weeks ago
On Wed, 29 Oct 2025 09:12:46 +0100, Sander Vanheule wrote:
> The flat cache behaves differently from the other caches, in that it has
> no way of knowing if a cache entry is valid. Initialization has to
> happen either by providing defaults, by loading defaults from hardware
> (via num_reg_defaults_raw), or by performing the required register
> writes. This difference in behavior may be unexpected to the user [1].
> 
> To provide feature parity between the different cache types, a new
> variant of the flat cache is proposed. This allows user to migrate to
> the sparse flat cache (or a different cache type) when possible.
> 
> [...]

Applied to

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

Thanks!

[1/2] regmap: add flat cache with sparse validity
      commit: 9c7f7262bc1affb9b9acd2ec2fb1f6314d5d474c
[2/2] regmap: warn users about uninitialized flat cache
      commit: e062bdfdd6adbb2dee7751d054c1d8df63ddb8b8

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