From: Sander Vanheule <sander@svanheule.net>
To: "Sheetal ." <sheetal@nvidia.com>, Mark Brown <broonie@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-kernel@vger.kernel.org, linux-sound@vger.kernel.org,
linux-tegra@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] regmap: Add cache_default_is_zero flag for flat cache
Date: Tue, 06 Jan 2026 22:19:42 +0100 [thread overview]
Message-ID: <f5dfb4e77fc9b59aaf5c35ed14cede549894b7c5.camel@svanheule.net> (raw)
In-Reply-To: <20260106140827.3771375-2-sheetal@nvidia.com>
Hi Sheetal,
On Tue, 2026-01-06 at 19:38 +0530, Sheetal . wrote:
> From: Sheetal <sheetal@nvidia.com>
>
> Commit e062bdfdd6ad ("regmap: warn users about uninitialized flat
> cache") added a warning for drivers using REGCACHE_FLAT when reading
> registers not present in reg_defaults.
>
> For hardware where registers have a power-on-reset value of zero
> or drivers that wish to treat zero as a valid cache default, adding
> all such registers to reg_defaults has drawbacks:
>
> 1. Maintenance burden: Drivers must list every readable register
> regardless of its reset value.
>
> 2. No functional benefit: Entries like { REG, 0x0 } only set the
> validity bit; the cache value is already zero.
This is only true because REGCACHE_FLAT just so happens to zero-initialize its
cache, which IMHO should be considered an implementation detail. If you were to
switch to another cache type, you would also need these defaults to maintain the
current behavior.
> 3. Code bloat: Large reg_defaults arrays increase driver size.
> Add a cache_default_is_zero flag to struct regmap_config. When set,
> the flat cache marks registers as valid on first read instead of
> warning. This ensures only accessed registers are marked valid,
> keeping sync scope minimal and avoiding writes to unused registers
> or holes.
A special flag only used in the flat cache is exactly the type of config I think
is non-intuitive and should be avoided. It needs an explanation, which implies
documentation that may go out of sync.
If your device has a single contiguous register space that you want to
initialize to zero, all you really need to provide is something like the ranges
used for readable/writable/... registers:
(struct regcache_defaults_range) {
.range_min = REG_MIN,
.range_max = REG_MAX,
.value = 0,
}
Instead of a bool, you could add a pointer to a defaults table in the config
(which can be loaded together with the current flat list), just like how
rd_table works.
This would allow others to use the same table for multiple contiguous block,
with zero or non-zero default values. It would work the same for all cache
types, thus avoiding potential confusion, and limit the size increase of your
drivers. Then you could even safely switch to REGCACHE_FLAT_S.
Best,
Sander
next prev parent reply other threads:[~2026-01-06 21:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-06 14:08 [RFC PATCH 0/2] regmap: Add cache_default_is_zero flag for flat cache Sheetal .
2026-01-06 14:08 ` [RFC PATCH 1/2] " Sheetal .
2026-01-06 15:12 ` Mark Brown
2026-01-07 6:55 ` Sheetal .
2026-01-07 11:20 ` Mark Brown
2026-01-06 21:19 ` Sander Vanheule [this message]
2026-01-07 7:30 ` Sheetal .
2026-01-06 14:08 ` [RFC PATCH 2/2] ASoC: tegra: Enable cache_default_is_zero for audio drivers Sheetal .
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f5dfb4e77fc9b59aaf5c35ed14cede549894b7c5.camel@svanheule.net \
--to=sander@svanheule.net \
--cc=broonie@kernel.org \
--cc=dakr@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=perex@perex.cz \
--cc=rafael@kernel.org \
--cc=sheetal@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox