Re: [PATCH 0/3] ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables

Pierre-Louis Bossart <[email protected]> Wed, 5 Aug 2026 10:40:46 +0200
Newsgroups gmane.linux.kernel.stable,gmane.linux.sound
Message-ID <[email protected]>
> 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.