From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Richard Fitzgerald <rf@opensource.cirrus.com>
Cc: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
"Pierre-Louis Bossart" <pierre-louis.bossart@linux.dev>,
"Mark Brown" <broonie@kernel.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"David Rhodes" <david.rhodes@cirrus.com>,
"Vlad Karpovich" <vkarpovi@opensource.cirrus.com>,
"Paul Handrigan" <Paul.Handrigan@cirrus.com>,
patches@opensource.cirrus.com, linux-sound@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 0/3] ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables
Date: Wed, 5 Aug 2026 10:52:15 +0100 [thread overview]
Message-ID: <anMHz34y6GMNbLcT@opensource.cirrus.com> (raw)
In-Reply-To: <81391ad1-1097-43ca-8729-ae01c00db3b2@opensource.cirrus.com>
On Wed, Aug 05, 2026 at 10:38:24AM +0100, Richard Fitzgerald wrote:
> On 05/08/2026 10:25 am, Charles Keepax wrote:
> > On Wed, Aug 05, 2026 at 12:10:10PM +0300, Péter Ujfalusi wrote:
> > > On 05/08/2026 12:00, Richard Fitzgerald wrote:
> > > > > > Found by an audit of all reg_defaults tables under sound/, the SoundWire
> > > > > > codec drivers are fixed by a separate series.
> > > > >
> > > > > Wow. Would it make sense to have a regmap helper to double-check the
> > > > > addresses are indeed in-order in those reg_default tables?
> > > > > I am not sure how this requirement can be enforced by just inspection, a
> > > > > warning would help detect this sort of issues on more platforms.
> > > > >
> > > > It does seem probable that anything that relies on people just
> > > > remembering to keep a large table sorted is prone to breaking,
> > > > especially if the addresses are provided by named constant instead of
> > > > a list of hardcoded numbers.
> > > >
> > > > Should regmap check the table when the regmap is first created?
> > > > As it has to search the table during normal use anyway, one extra walk
> > > > when the regmap is created probably isn't a serious overhead.
> > >
> > > But it will be done for _all_ devices which uses regmap on boot, small
> > > things do add up, see my reply to Pierre-Louis.
> >
> > Indeed, if we were to add some sort of auto-checker it should
> > be guarded behind something like perhaps a Kconfig option or the
> > DEBUG define.
> >
> > Thanks,
> > Charles
>
> regcache_init() already walks the defaults table checking the stride
>
> for (i = 0; i < config->num_reg_defaults; i++)
> if (config->reg_defaults[i].reg % map->reg_stride)
> return -EINVAL;
>
> so checking that each entry is larger than previous is trivial extra
> overhead. I think most regmaps are cached.
Hmm... in that case perhaps we should. Also if the regmap isn't
cached then the defaults don't really serve any purpose so should
cover all the cases that matter I think.
Thanks,
Charles
next prev parent reply other threads:[~2026-08-05 9:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 8:24 [PATCH 0/3] ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables Peter Ujfalusi
2026-08-05 8:24 ` [PATCH 1/3] ASoC: cs35l41: sort the register default table Peter Ujfalusi
2026-08-05 9:58 ` Richard Fitzgerald
2026-08-05 8:24 ` [PATCH 2/3] ASoC: cs35l45: " Peter Ujfalusi
2026-08-05 11:35 ` Richard Fitzgerald
2026-08-05 8:24 ` [PATCH 3/3] ASoC: cs4265: " Peter Ujfalusi
2026-08-05 11:31 ` Richard Fitzgerald
2026-08-05 8:40 ` [PATCH 0/3] ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables Pierre-Louis Bossart
2026-08-05 8:52 ` Péter Ujfalusi
2026-08-05 8:59 ` Pierre-Louis Bossart
2026-08-05 9:00 ` Richard Fitzgerald
2026-08-05 9:10 ` Péter Ujfalusi
2026-08-05 9:25 ` Charles Keepax
2026-08-05 9:38 ` Richard Fitzgerald
2026-08-05 9:52 ` Charles Keepax [this message]
2026-08-05 9:52 ` Péter Ujfalusi
2026-08-05 9:56 ` Richard Fitzgerald
2026-08-05 9:59 ` Péter Ujfalusi
2026-08-05 10:10 ` Charles Keepax
2026-08-05 10:17 ` Péter Ujfalusi
2026-08-05 10:36 ` Richard Fitzgerald
2026-08-05 11:25 ` Péter Ujfalusi
2026-08-05 11:31 ` Charles Keepax
2026-08-05 11:38 ` Richard Fitzgerald
2026-08-05 11:38 ` Péter Ujfalusi
2026-08-05 9:25 ` Péter Ujfalusi
2026-08-05 10:38 ` Mark Brown
2026-08-05 8:59 ` Charles Keepax
2026-08-05 12:37 ` 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=anMHz34y6GMNbLcT@opensource.cirrus.com \
--to=ckeepax@opensource.cirrus.com \
--cc=Paul.Handrigan@cirrus.com \
--cc=broonie@kernel.org \
--cc=david.rhodes@cirrus.com \
--cc=lgirdwood@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--cc=rf@opensource.cirrus.com \
--cc=stable@vger.kernel.org \
--cc=vkarpovi@opensource.cirrus.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