All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	David Rhodes <david.rhodes@cirrus.com>,
	Richard Fitzgerald <rf@opensource.cirrus.com>
Cc: Charles Keepax <ckeepax@opensource.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:40:46 +0200	[thread overview]
Message-ID: <c8aac762-c1a7-44ab-afff-72610cabe341@linux.dev> (raw)
In-Reply-To: <20260805082413.26174-1-peter.ujfalusi@linux.intel.com>


> reg_defaults must be sorted by ascending register address as
> regcache_lookup_reg() locates the entries in it with bsearch(), see commit
> fd80df352ba1 ("regcache: Add support for sorting defaults arrays").
> 
> These three tables have entries which are out of order, so the binary search
> does not find part of them.  For those registers regcache_reg_needs_sync()
> cannot compare the cached value against the default and reports that a sync
> is needed, so they are written to the device on every regcache_sync() even
> when they were never touched.
> 
> The patches only reorder the existing entries, the text of every entry is
> kept verbatim and no default value is changed.  Each table was verified by
> evaluating the register addresses and replaying lib/bsearch.c on them.
> 
> Entries not reachable by the binary search, per table:
> 
>   cs35l41_reg           2 (of 47)
>   cs35l45_defaults     36 (of 73)
>   cs4265_reg_defaults   3 (of 16)
> 
> For cs35l45 this is nearly half of the table: the DSP1_RX*_RATE and
> DSP1_TX*_RATE registers sit in the middle of it while their addresses are
> far above everything else, which cuts the search off from the whole
> 0x4c40 - 0xf010 range.
> 
> 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.


  parent reply	other threads:[~2026-08-05  8:41 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 ` Pierre-Louis Bossart [this message]
2026-08-05  8:52   ` [PATCH 0/3] ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables 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
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                           ` Péter Ujfalusi
2026-08-05 11:38                           ` Richard Fitzgerald
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=c8aac762-c1a7-44ab-afff-72610cabe341@linux.dev \
    --to=pierre-louis.bossart@linux.dev \
    --cc=Paul.Handrigan@cirrus.com \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.cirrus.com \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.