lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48d62d49-9fa5-4423-b08f-b138d9f7330a@nvidia.com>
Date: Wed, 7 Jan 2026 13:00:55 +0530
From: "Sheetal ." <sheetal@...dia.com>
To: Sander Vanheule <sander@...nheule.net>, Mark Brown <broonie@...nel.org>
Cc: 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 07-01-2026 02:49, Sander Vanheule wrote:
> External email: Use caution opening links or attachments
> 
> 
> Hi Sheetal,
> 
> On Tue, 2026-01-06 at 19:38 +0530, Sheetal . wrote:
>> From: Sheetal <sheetal@...dia.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.


The warning itself only exists in REGCACHE_FLAT not in other cache 
types. So this fix addresses a REGCACHE_FLAT specific warning with a 
REGCACHE_FLAT-specific flag.

I feel that perhaps we could avoid warning the user when they have
explicitly indicated that zero is a valid default for their hardware.
Since the driver author understands their device requirements, this
flag would allow them to opt out of the warning for cases where it
may not be helpful.

> 
>> 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.
> 

The range-based approach is a good idea for contiguous register
blocks. However, if registers with zero defaults are not contiguous
(scattered across the address space), it would need multiple range
entries or multiple reg default entries.


> Best,
> Sander


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ