From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, driver-core@lists.linux.dev,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>
Subject: Re: [PATCH v3 1/3] regcache: Move HW readback after cache initialisation
Date: Fri, 27 Feb 2026 07:43:59 +0200 [thread overview]
Message-ID: <aaEvH2dk9yTwaUc8@smile.fi.intel.com> (raw)
In-Reply-To: <0c5bdf5a-459b-4ef8-95cb-3d1c0ad867bb@sirena.org.uk>
On Thu, Feb 26, 2026 at 10:14:55PM +0000, Mark Brown wrote:
> On Thu, Feb 26, 2026 at 02:57:09PM +0100, Andy Shevchenko wrote:
> > Make sure that cache is initialised before calling any IO
> > using regmap, this makes sure that we won't access NULL or
> > invalid pointers in the cache which hasn't been initialised.
...
> > @@ -202,14 +210,6 @@ int regcache_init(struct regmap *map, const struct regmap_config *config)
> > count = regcache_count_cacheable_registers(map);
> > if (map->cache_bypass)
> > return 0;
>
> This is in the case where num_reg_defaults_raw != 0 (and we didn't have
> any explicit defaults!), it's the only place where count gets set...
Actually the check in the regmap_hw_init() should be done against count,
indeed.
> > + /*
> > + * Some devices such as PMICs don't have cache defaults,
> > + * we cope with this by reading back the HW registers and
> > + * crafting the cache defaults by hand.
> > + */
> > + ret = regcache_hw_init(map, count);
> > + if (ret)
> > + goto err_exit;
>
> ...and we now pass count off to regcache_hw_init() which will attempt to
> allocate a zero length array and presumably faceplant if that happens.
> I don't *think* we should ever hit that case (at least not for a
> sensible regmap), but I'm having to think far too hard about the whole
> thing to convince myself it's safe. I think we should keep the counting
> of registers to allocate and the decision to call regcache_hw_init()
> more joined up.
Is it possible to allocate something, then count, then reallocate
in the existing caches and in the potential future ones?
I think it's the patter that we first count the size of the allocation,
do the allocation, and only then fill up the allocated area with data.
Otherwise we came back to the chicken-egg issue this patch tries to solve.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-02-27 5:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 13:57 [PATCH v3 0/3] regcache: Avoid accessing non-initialised cache Andy Shevchenko
2026-02-26 13:57 ` [PATCH v3 1/3] regcache: Move HW readback after cache initialisation Andy Shevchenko
2026-02-26 22:14 ` Mark Brown
2026-02-27 5:43 ` Andy Shevchenko [this message]
2026-02-28 13:09 ` Mark Brown
2026-02-28 13:55 ` Andy Shevchenko
2026-02-26 13:57 ` [PATCH v3 2/3] regcache: Define iterator inside for-loop and align their types Andy Shevchenko
2026-02-26 13:57 ` [PATCH v3 3/3] regcache: Amend printf() specifiers when printing registers Andy Shevchenko
2026-03-03 11:20 ` [PATCH v3 0/3] regcache: Avoid accessing non-initialised cache Mark Brown
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=aaEvH2dk9yTwaUc8@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
/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