[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0032054-4eea-44f4-bf70-204fa414f297@nvidia.com>
Date: Wed, 7 Jan 2026 12:25:01 +0530
From: "Sheetal ." <sheetal@...dia.com>
To: Mark Brown <broonie@...nel.org>
Cc: Sander Vanheule <sander@...nheule.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>, Danilo Krummrich
<dakr@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>, linux-kernel@...r.kernel.org,
linux-sound@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] regmap: Add cache_default_is_zero flag for flat
cache
On 06-01-2026 20:42, Mark Brown wrote:
> On Tue, Jan 06, 2026 at 07:38:26PM +0530, Sheetal . wrote:
>
>> 2. No functional benefit: Entries like { REG, 0x0 } only set the
>> validity bit; the cache value is already zero.
>
> For sparse caches specifying the register also allocates the cache
> entry.
ACK
>
>> 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,
>
> Why do this on first read rather than than just fill the valid flags
> during initialisation?
>
Setting valid bits on first read rather than bitmap_fill() at init ensures:
- Only accessed registers are marked valid
- regcache_sync() only syncs registers that were actually used
- Avoids writes to holes or unused registers during sync
- Safer for drivers without writeable_reg callback
>> index b0b9be750d93..bf918f88bfd3 100644
>> --- a/include/linux/regmap.h
>> +++ b/include/linux/regmap.h
>> @@ -452,6 +452,7 @@ struct regmap_config {
>> enum regcache_type cache_type;
>> const void *reg_defaults_raw;
>> unsigned int num_reg_defaults_raw;
>> + bool cache_default_is_zero;
>
> It would be better if this were something specific to the flat cache
> since otherwise we have to consider what this means for the other cache
> types.
I can address this by rename to flat_cache_default_is_zero.
Powered by blists - more mailing lists