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

On 05/08/2026 9:40 am, Pierre-Louis Bossart wrote:
> 
>> 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.
> 
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.