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

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

[Peter Ujfalusi]

Hi,

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.

Regards,
Peter

Peter Ujfalusi (3):
  ASoC: cs35l41: sort the register default table
  ASoC: cs35l45: sort the register default table
  ASoC: cs4265: sort the register default table

 sound/soc/codecs/cs35l41-lib.c    |  2 +-
 sound/soc/codecs/cs35l45-tables.c | 32 +++++++++++++++----------------
 sound/soc/codecs/cs4265.c         |  4 ++--
 3 files changed, 19 insertions(+), 19 deletions(-)


base-commit: 05eebef3c7b2e8595fdd1bd46912aac9c1de8587
-- 
2.55.0

[PATCH 1/3] ASoC: cs35l41: sort the register default table

[Peter Ujfalusi]

reg_defaults must be sorted by ascending register address, as
regcache_lookup_reg() locates entries in it with bsearch().  See commit
fd80df352ba1 ("regcache: Add support for sorting defaults arrays").

cs35l41_reg[] lists CS35L41_BSTCVRT_PEAK_CUR (0x3808) after
CS35L41_BSTCVRT_COEFF (0x3810) and CS35L41_BSTCVRT_SLOPE_LBST (0x3814), so
the binary search does not find those two entries.
regcache_reg_needs_sync() then cannot compare them against their 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.

Sort the table by register address.

Fixes: 5f2f539901b0 ("ASoC: cs35l41: Correct handling of some registers in the cache")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
 sound/soc/codecs/cs35l41-lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/cs35l41-lib.c b/sound/soc/codecs/cs35l41-lib.c
index 1702f26049d3..b0fa80705be7 100644
--- a/sound/soc/codecs/cs35l41-lib.c
+++ b/sound/soc/codecs/cs35l41-lib.c
@@ -25,9 +25,9 @@ static const struct reg_default cs35l41_reg[] = {
 	{ CS35L41_GPIO_PAD_CONTROL,		0x00000000 },
 	{ CS35L41_GLOBAL_CLK_CTRL,		0x00000003 },
 	{ CS35L41_TST_FS_MON0,			0x00020016 },
+	{ CS35L41_BSTCVRT_PEAK_CUR,		0x0000004A },
 	{ CS35L41_BSTCVRT_COEFF,		0x00002424 },
 	{ CS35L41_BSTCVRT_SLOPE_LBST,		0x00007500 },
-	{ CS35L41_BSTCVRT_PEAK_CUR,		0x0000004A },
 	{ CS35L41_SP_ENABLES,			0x00000000 },
 	{ CS35L41_SP_RATE_CTRL,			0x00000028 },
 	{ CS35L41_SP_FORMAT,			0x18180200 },
-- 
2.55.0

Re: [PATCH 1/3] ASoC: cs35l41: sort the register default table

[Richard Fitzgerald]

On 05/08/2026 9:24 am, Peter Ujfalusi wrote:
> reg_defaults must be sorted by ascending register address, as
> regcache_lookup_reg() locates entries in it with bsearch().  See commit
> fd80df352ba1 ("regcache: Add support for sorting defaults arrays").
> 
> cs35l41_reg[] lists CS35L41_BSTCVRT_PEAK_CUR (0x3808) after
> CS35L41_BSTCVRT_COEFF (0x3810) and CS35L41_BSTCVRT_SLOPE_LBST (0x3814), so
> the binary search does not find those two entries.
> regcache_reg_needs_sync() then cannot compare them against their 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.
> 
> Sort the table by register address.
> 
> Fixes: 5f2f539901b0 ("ASoC: cs35l41: Correct handling of some registers in the cache")
> Cc: stable@vger.kernel.org
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>

[PATCH 2/3] ASoC: cs35l45: sort the register default table

[Peter Ujfalusi]

reg_defaults must be sorted by ascending register address, as
regcache_lookup_reg() locates entries in it with bsearch().  See commit
fd80df352ba1 ("regcache: Add support for sorting defaults arrays").

cs35l45_defaults[] lists the DSP1_RX*_RATE and DSP1_TX*_RATE registers
(0x02b80080 - 0x02b802b8) in the middle of the table, ahead of entries with
much lower addresses, so the binary search does not find 36 of its 73
entries.  regcache_reg_needs_sync() then cannot compare those against their
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.

Sort the table by register address.

Fixes: 74b14e2850a3 ("ASoC: cs35l45: DSP Support")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
 sound/soc/codecs/cs35l45-tables.c | 32 +++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/sound/soc/codecs/cs35l45-tables.c b/sound/soc/codecs/cs35l45-tables.c
index d2ecc7b3f619..764dbaa35042 100644
--- a/sound/soc/codecs/cs35l45-tables.c
+++ b/sound/soc/codecs/cs35l45-tables.c
@@ -66,22 +66,6 @@ static const struct reg_default cs35l45_defaults[] = {
 	{ CS35L45_ASPTX3_INPUT,			0x00000020 },
 	{ CS35L45_ASPTX4_INPUT,			0x00000028 },
 	{ CS35L45_ASPTX5_INPUT,			0x00000048 },
-	{ CS35L45_DSP1_RX1_RATE,		0x00000001 },
-	{ CS35L45_DSP1_RX2_RATE,		0x00000001 },
-	{ CS35L45_DSP1_RX3_RATE,		0x00000001 },
-	{ CS35L45_DSP1_RX4_RATE,		0x00000001 },
-	{ CS35L45_DSP1_RX5_RATE,		0x00000001 },
-	{ CS35L45_DSP1_RX6_RATE,		0x00000001 },
-	{ CS35L45_DSP1_RX7_RATE,		0x00000001 },
-	{ CS35L45_DSP1_RX8_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX1_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX2_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX3_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX4_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX5_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX6_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX7_RATE,		0x00000001 },
-	{ CS35L45_DSP1_TX8_RATE,		0x00000001 },
 	{ CS35L45_DSP1RX1_INPUT,		0x00000008 },
 	{ CS35L45_DSP1RX2_INPUT,		0x00000009 },
 	{ CS35L45_DSP1RX3_INPUT,		0x00000018 },
@@ -114,6 +98,22 @@ static const struct reg_default cs35l45_defaults[] = {
 	{ CS35L45_GPIO1_CTRL1,			0x81000001 },
 	{ CS35L45_GPIO2_CTRL1,			0x81000001 },
 	{ CS35L45_GPIO3_CTRL1,			0x81000001 },
+	{ CS35L45_DSP1_RX1_RATE,		0x00000001 },
+	{ CS35L45_DSP1_RX2_RATE,		0x00000001 },
+	{ CS35L45_DSP1_RX3_RATE,		0x00000001 },
+	{ CS35L45_DSP1_RX4_RATE,		0x00000001 },
+	{ CS35L45_DSP1_RX5_RATE,		0x00000001 },
+	{ CS35L45_DSP1_RX6_RATE,		0x00000001 },
+	{ CS35L45_DSP1_RX7_RATE,		0x00000001 },
+	{ CS35L45_DSP1_RX8_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX1_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX2_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX3_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX4_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX5_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX6_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX7_RATE,		0x00000001 },
+	{ CS35L45_DSP1_TX8_RATE,		0x00000001 },
 };
 
 static bool cs35l45_readable_reg(struct device *dev, unsigned int reg)
-- 
2.55.0

Re: [PATCH 2/3] ASoC: cs35l45: sort the register default table

[Richard Fitzgerald]

On 05/08/2026 9:24 am, Peter Ujfalusi wrote:
> reg_defaults must be sorted by ascending register address, as
> regcache_lookup_reg() locates entries in it with bsearch().  See commit
> fd80df352ba1 ("regcache: Add support for sorting defaults arrays").
> 
> cs35l45_defaults[] lists the DSP1_RX*_RATE and DSP1_TX*_RATE registers
> (0x02b80080 - 0x02b802b8) in the middle of the table, ahead of entries with
> much lower addresses, so the binary search does not find 36 of its 73
> entries.  regcache_reg_needs_sync() then cannot compare those against their
> 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.
> 
> Sort the table by register address.

Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>

[PATCH 3/3] ASoC: cs4265: sort the register default table

[Peter Ujfalusi]

reg_defaults must be sorted by ascending register address, as
regcache_lookup_reg() locates entries in it with bsearch().  See commit
fd80df352ba1 ("regcache: Add support for sorting defaults arrays").

cs4265_reg_defaults[] lists CS4265_INT_MASK (0x0e),
CS4265_STATUS_MODE_MSB (0x0f) and CS4265_STATUS_MODE_LSB (0x10) after
CS4265_SPDIF_CTL1 (0x11) and CS4265_SPDIF_CTL2 (0x12), so the binary search
does not find those three entries.  regcache_reg_needs_sync() then cannot
compare them against their 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.

Sort the table by register address.

Fixes: fb6f806967f6 ("ASoC: Add support for the CS4265 CODEC")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
 sound/soc/codecs/cs4265.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/cs4265.c b/sound/soc/codecs/cs4265.c
index 286d5ca29854..0b7d6826f4e9 100644
--- a/sound/soc/codecs/cs4265.c
+++ b/sound/soc/codecs/cs4265.c
@@ -46,11 +46,11 @@ static const struct reg_default cs4265_reg_defaults[] = {
 	{ CS4265_DAC_CHA_VOL, 0x00 },
 	{ CS4265_DAC_CHB_VOL, 0x00 },
 	{ CS4265_DAC_CTL2, 0xC0 },
-	{ CS4265_SPDIF_CTL1, 0x00 },
-	{ CS4265_SPDIF_CTL2, 0x00 },
 	{ CS4265_INT_MASK, 0x00 },
 	{ CS4265_STATUS_MODE_MSB, 0x00 },
 	{ CS4265_STATUS_MODE_LSB, 0x00 },
+	{ CS4265_SPDIF_CTL1, 0x00 },
+	{ CS4265_SPDIF_CTL2, 0x00 },
 };
 
 static bool cs4265_readable_register(struct device *dev, unsigned int reg)
-- 
2.55.0

Re: [PATCH 3/3] ASoC: cs4265: sort the register default table

[Richard Fitzgerald]

On 05/08/2026 9:24 am, Peter Ujfalusi wrote:
> reg_defaults must be sorted by ascending register address, as
> regcache_lookup_reg() locates entries in it with bsearch().  See commit
> fd80df352ba1 ("regcache: Add support for sorting defaults arrays").
> 
> cs4265_reg_defaults[] lists CS4265_INT_MASK (0x0e),
> CS4265_STATUS_MODE_MSB (0x0f) and CS4265_STATUS_MODE_LSB (0x10) after
> CS4265_SPDIF_CTL1 (0x11) and CS4265_SPDIF_CTL2 (0x12), so the binary search
> does not find those three entries.  regcache_reg_needs_sync() then cannot
> compare them against their 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.
> 
> Sort the table by register address.

Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>

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

[Pierre-Louis Bossart]

> 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.

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

[Péter Ujfalusi]

On 05/08/2026 11:40, 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.


I had this first:
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index be167ee6f57c..7d2f74494645 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -187,6 +187,9 @@ int regcache_init(struct regmap *map, const struct
regmap_config *config)
 		if (!tmp_buf)
 			return -ENOMEM;
 		map->reg_defaults = tmp_buf;
+
+		/* regcache_lookup_reg() bsearch()es this array */
+		regcache_sort_defaults(tmp_buf, map->num_reg_defaults);
 	} else if (map->num_reg_defaults_raw) {
 		count = regcache_count_cacheable_registers(map);
 		if (!count)


But it would run for all regmap on boot and I think that would be a big
hit on boot time.
I guess, a debug kernel option could enable ordering check for defaults
in regmap and warn if it finds such?

-- 
Péter

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

[Pierre-Louis Bossart]

On 8/5/26 10:52, Péter Ujfalusi wrote:
> 
> 
> On 05/08/2026 11:40, 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.
> 
> 
> I had this first:
> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
> index be167ee6f57c..7d2f74494645 100644
> --- a/drivers/base/regmap/regcache.c
> +++ b/drivers/base/regmap/regcache.c
> @@ -187,6 +187,9 @@ int regcache_init(struct regmap *map, const struct
> regmap_config *config)
>  		if (!tmp_buf)
>  			return -ENOMEM;
>  		map->reg_defaults = tmp_buf;
> +
> +		/* regcache_lookup_reg() bsearch()es this array */
> +		regcache_sort_defaults(tmp_buf, map->num_reg_defaults);
>  	} else if (map->num_reg_defaults_raw) {
>  		count = regcache_count_cacheable_registers(map);
>  		if (!count)
> 
> 
> But it would run for all regmap on boot and I think that would be a big
> hit on boot time.
> I guess, a debug kernel option could enable ordering check for defaults
> in regmap and warn if it finds such?

reordering the tables could take time even on a perfectly ordered case,
I was only thinking of throwing a warning with a simple loop on the table.
Maybe also something for kernel tests? A warning would require user
feedback whereas a formal test could check for hundreds of regmap defaults.

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

[Richard Fitzgerald]

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.

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

[Péter Ujfalusi]

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.

-- 
Péter

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

[Charles Keepax]

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

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

[Richard Fitzgerald]

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.

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

[Charles Keepax]

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

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

[Péter Ujfalusi]

On 05/08/2026 12:38, 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.

Right, I think this should work:

diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index aa8f2efed779..ce4b11d8a758 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -123,6 +123,7 @@ static void regcache_hw_exit(struct regmap *map)
 
 int regcache_init(struct regmap *map, const struct regmap_config *config)
 {
+	bool sort_defaults = false;
 	int count = 0;
 	int ret;
 	int i;
@@ -149,10 +150,15 @@ int regcache_init(struct regmap *map, const struct regmap_config *config)
 		return -EINVAL;
 	}
 
-	for (i = 0; i < config->num_reg_defaults; i++)
+	for (i = 0; i < config->num_reg_defaults; i++) {
 		if (config->reg_defaults[i].reg % map->reg_stride)
 			return -EINVAL;
 
+		if (i && config->reg_defaults[i - 1].reg >
+		    config->reg_defaults[i].reg)
+			sort_defaults = true;
+	}
+
 	for (i = 0; i < ARRAY_SIZE(cache_types); i++)
 		if (cache_types[i]->type == map->cache_type)
 			break;
@@ -186,6 +192,16 @@ int regcache_init(struct regmap *map, const struct regmap_config *config)
 					sizeof(*map->reg_defaults), GFP_KERNEL);
 		if (!tmp_buf)
 			return -ENOMEM;
+
+		/*
+		 * regcache_lookup_reg() bsearch()es this array, sort the local
+		 * copy if it is not ordered
+		 */
+		if (sort_defaults) {
+			dev_dbg(map->dev,
+				"Register defaults are not ordered, sorting the local copy\n");
+			regcache_sort_defaults(tmp_buf, map->num_reg_defaults);
+		}
 		map->reg_defaults = tmp_buf;
 	} else if (map->num_reg_defaults_raw) {
 		count = regcache_count_cacheable_registers(map);


-- 
Péter

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

[Richard Fitzgerald]

On 05/08/2026 10:52 am, Péter Ujfalusi wrote:
> 
> 
> On 05/08/2026 12:38, 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.
> 
> Right, I think this should work:
> 
> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
> index aa8f2efed779..ce4b11d8a758 100644
> --- a/drivers/base/regmap/regcache.c
> +++ b/drivers/base/regmap/regcache.c
> @@ -123,6 +123,7 @@ static void regcache_hw_exit(struct regmap *map)
>   
>   int regcache_init(struct regmap *map, const struct regmap_config *config)
>   {
> +	bool sort_defaults = false;
>   	int count = 0;
>   	int ret;
>   	int i;
> @@ -149,10 +150,15 @@ int regcache_init(struct regmap *map, const struct regmap_config *config)
>   		return -EINVAL;
>   	}
>   
> -	for (i = 0; i < config->num_reg_defaults; i++)
> +	for (i = 0; i < config->num_reg_defaults; i++) {
>   		if (config->reg_defaults[i].reg % map->reg_stride)
>   			return -EINVAL;
>   
> +		if (i && config->reg_defaults[i - 1].reg >

You could test the stride of defaults[0] first before the loop, and
start the loop at i = 1. Then on each loop you can test [i] against
[i - 1] without the need to check i != 0 every time.

I don't think we need to sort them. Just fail, so that an unsorted table
must be fixed.

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

[Péter Ujfalusi]

On 05/08/2026 12:56, Richard Fitzgerald wrote:
> On 05/08/2026 10:52 am, Péter Ujfalusi wrote:
>>
>>
>> On 05/08/2026 12:38, 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.
>>
>> Right, I think this should work:
>>
>> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/
>> regcache.c
>> index aa8f2efed779..ce4b11d8a758 100644
>> --- a/drivers/base/regmap/regcache.c
>> +++ b/drivers/base/regmap/regcache.c
>> @@ -123,6 +123,7 @@ static void regcache_hw_exit(struct regmap *map)
>>     int regcache_init(struct regmap *map, const struct regmap_config
>> *config)
>>   {
>> +    bool sort_defaults = false;
>>       int count = 0;
>>       int ret;
>>       int i;
>> @@ -149,10 +150,15 @@ int regcache_init(struct regmap *map, const
>> struct regmap_config *config)
>>           return -EINVAL;
>>       }
>>   -    for (i = 0; i < config->num_reg_defaults; i++)
>> +    for (i = 0; i < config->num_reg_defaults; i++) {
>>           if (config->reg_defaults[i].reg % map->reg_stride)
>>               return -EINVAL;
>>   +        if (i && config->reg_defaults[i - 1].reg >
> 
> You could test the stride of defaults[0] first before the loop, and
> start the loop at i = 1. Then on each loop you can test [i] against
> [i - 1] without the need to check i != 0 every time.

OK, should be better like that

> I don't think we need to sort them. Just fail, so that an unsorted table
> must be fixed.

That would be a big regression all around the place, ordering w/ the
debug message if developer is interested is much better.

-- 
Péter

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

[Charles Keepax]

On Wed, Aug 05, 2026 at 12:59:30PM +0300, Péter Ujfalusi wrote:
> On 05/08/2026 12:56, Richard Fitzgerald wrote:
> > On 05/08/2026 10:52 am, Péter Ujfalusi wrote:
> >> On 05/08/2026 12:38, 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:
> >> diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/
> >> regcache.c
> >> index aa8f2efed779..ce4b11d8a758 100644
> >> --- a/drivers/base/regmap/regcache.c
> >> +++ b/drivers/base/regmap/regcache.c
> >> @@ -123,6 +123,7 @@ static void regcache_hw_exit(struct regmap *map)
> >>     int regcache_init(struct regmap *map, const struct regmap_config
> >> *config)
> >>   {
> >> +    bool sort_defaults = false;
> >>       int count = 0;
> >>       int ret;
> >>       int i;
> >> @@ -149,10 +150,15 @@ int regcache_init(struct regmap *map, const
> >> struct regmap_config *config)
> >>           return -EINVAL;
> >>       }
> >>   -    for (i = 0; i < config->num_reg_defaults; i++)
> >> +    for (i = 0; i < config->num_reg_defaults; i++) {
> >>           if (config->reg_defaults[i].reg % map->reg_stride)
> >>               return -EINVAL;
> >>   +        if (i && config->reg_defaults[i - 1].reg >
> 
> > I don't think we need to sort them. Just fail, so that an unsorted table
> > must be fixed.
> 
> That would be a big regression all around the place, ordering w/ the
> debug message if developer is interested is much better.

I think I would come down between the two of you. I definitely
agree with Richard on don't sort them, just encourages drivers to
be wrong. But I also agree with you, don't hard fail. I would
vote for just print an error message and carry on. That way no
regressions, but also a nice big warning message to let people
know what is wrong when they see problems.

Thanks,
Charles

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

[Péter Ujfalusi]

On 05/08/2026 13:10, Charles Keepax wrote:
>>> I don't think we need to sort them. Just fail, so that an unsorted table
>>> must be fixed.
>>
>> That would be a big regression all around the place, ordering w/ the
>> debug message if developer is interested is much better.
> 
> I think I would come down between the two of you. I definitely
> agree with Richard on don't sort them, just encourages drivers to
> be wrong. But I also agree with you, don't hard fail. I would
> vote for just print an error message and carry on. That way no
> regressions, but also a nice big warning message to let people
> know what is wrong when they see problems.

I usually try to avoid alarming/annoying users with error messages, on
the other hand I agree that w/o some pressure, these will never be
corrected at root either ;)

On the yet another hand, if the regcache have means to fix this, it
might be put into use as well.
A dev_warn at max to get attention or info level perhaps and fixing it up?

-- 
Péter

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

[Richard Fitzgerald]

On 05/08/2026 11:17 am, Péter Ujfalusi wrote:
> 
> 
> On 05/08/2026 13:10, Charles Keepax wrote:
>>>> I don't think we need to sort them. Just fail, so that an unsorted table
>>>> must be fixed.
>>>
>>> That would be a big regression all around the place, ordering w/ the
>>> debug message if developer is interested is much better.
>>
>> I think I would come down between the two of you. I definitely
>> agree with Richard on don't sort them, just encourages drivers to
>> be wrong. But I also agree with you, don't hard fail. I would
>> vote for just print an error message and carry on. That way no
>> regressions, but also a nice big warning message to let people
>> know what is wrong when they see problems.
> 
> I usually try to avoid alarming/annoying users with error messages, on
> the other hand I agree that w/o some pressure, these will never be
> corrected at root either ;)
> 
> On the yet another hand, if the regcache have means to fix this, it
> might be put into use as well.
> A dev_warn at max to get attention or info level perhaps and fixing it up?
> 
I asked Codex (GPT5) to search for all reg_default tables with out-of
order entries or duplicate entries, looking only at those assigned to
struct regmap_config.reg_defaults (some reg_defaults tables are used for
patching - those are allowed to be out-of-order).

It came up with this:

Restricting results to tables referenced by struct
regmap_config.reg_defaults, 39 files violate the rule:

   drivers/firmware/cirrus/test/cs_dsp_mock_regmap.c
   drivers/leds/leds-lp50xx.c
   drivers/mfd/cs42l43.c
   drivers/platform/mellanox/mlx-platform.c
   drivers/power/supply/bq25980_charger.c
   sound/soc/codecs/ad1836.c
   sound/soc/codecs/adau1373.c
   sound/soc/codecs/adau1761.c
   sound/soc/codecs/adau1781.c
   sound/soc/codecs/cs35l41-lib.c
   sound/soc/codecs/cs35l45-tables.c
   sound/soc/codecs/cs4265.c
   sound/soc/codecs/cx2072x.c
   sound/soc/codecs/lm49453.c
   sound/soc/codecs/max9860.c
   sound/soc/codecs/ml26124.c
   sound/soc/codecs/msm8916-wcd-analog.c
   sound/soc/codecs/pcm512x.c
   sound/soc/codecs/pm4125-sdw.c
   sound/soc/codecs/rt1019.c
   sound/soc/codecs/rt1318.c
   sound/soc/codecs/rt274.c
   sound/soc/codecs/rt286.c
   sound/soc/codecs/rt298.c
   sound/soc/codecs/rt700-sdw.h
   sound/soc/codecs/rt711-sdw.h
   sound/soc/codecs/rt715-sdw.h
   sound/soc/codecs/sgtl5000.c
   sound/soc/codecs/sti-sas.c
   sound/soc/codecs/tas2552.c
   sound/soc/codecs/tas2764.c
   sound/soc/codecs/tas2780.c
   sound/soc/codecs/tas675x.c
   sound/soc/codecs/wm8996.c
   sound/soc/fsl/fsl_easrc.c
   sound/soc/tegra/tegra210_admaif.c
   sound/soc/tegra/tegra210_i2s.c
   sound/soc/tegra/tegra210_mbdrc.c
   sound/soc/tegra/tegra210_mixer.c

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

[Péter Ujfalusi]

On 05/08/2026 13:36, Richard Fitzgerald wrote:
> On 05/08/2026 11:17 am, Péter Ujfalusi wrote:
>>
>>
>> On 05/08/2026 13:10, Charles Keepax wrote:
>>>>> I don't think we need to sort them. Just fail, so that an unsorted
>>>>> table
>>>>> must be fixed.
>>>>
>>>> That would be a big regression all around the place, ordering w/ the
>>>> debug message if developer is interested is much better.
>>>
>>> I think I would come down between the two of you. I definitely
>>> agree with Richard on don't sort them, just encourages drivers to
>>> be wrong. But I also agree with you, don't hard fail. I would
>>> vote for just print an error message and carry on. That way no
>>> regressions, but also a nice big warning message to let people
>>> know what is wrong when they see problems.
>>
>> I usually try to avoid alarming/annoying users with error messages, on
>> the other hand I agree that w/o some pressure, these will never be
>> corrected at root either ;)
>>
>> On the yet another hand, if the regcache have means to fix this, it
>> might be put into use as well.
>> A dev_warn at max to get attention or info level perhaps and fixing it
>> up?
>>
> I asked Codex (GPT5) to search for all reg_default tables with out-of
> order entries or duplicate entries, looking only at those assigned to
> struct regmap_config.reg_defaults (some reg_defaults tables are used for
> patching - those are allowed to be out-of-order).
> 
> It came up with this:
> 
> Restricting results to tables referenced by struct
> regmap_config.reg_defaults, 39 files violate the rule:

and some of these have duplicate addresses with different default values.

I can send more fixes while I'm at this for the clear cases, for Cirrus,
Realtek and TI I have sent few patches.

> 
>   drivers/firmware/cirrus/test/cs_dsp_mock_regmap.c
>   drivers/leds/leds-lp50xx.c
>   drivers/mfd/cs42l43.c
>   drivers/platform/mellanox/mlx-platform.c
>   drivers/power/supply/bq25980_charger.c
>   sound/soc/codecs/ad1836.c
>   sound/soc/codecs/adau1373.c
>   sound/soc/codecs/adau1761.c
>   sound/soc/codecs/adau1781.c
>   sound/soc/codecs/cs35l41-lib.c
>   sound/soc/codecs/cs35l45-tables.c
>   sound/soc/codecs/cs4265.c
>   sound/soc/codecs/cx2072x.c
>   sound/soc/codecs/lm49453.c
>   sound/soc/codecs/max9860.c
>   sound/soc/codecs/ml26124.c
>   sound/soc/codecs/msm8916-wcd-analog.c
>   sound/soc/codecs/pcm512x.c
>   sound/soc/codecs/pm4125-sdw.c
>   sound/soc/codecs/rt1019.c
>   sound/soc/codecs/rt1318.c
>   sound/soc/codecs/rt274.c
>   sound/soc/codecs/rt286.c
>   sound/soc/codecs/rt298.c
>   sound/soc/codecs/rt700-sdw.h
>   sound/soc/codecs/rt711-sdw.h
>   sound/soc/codecs/rt715-sdw.h
>   sound/soc/codecs/sgtl5000.c
>   sound/soc/codecs/sti-sas.c
>   sound/soc/codecs/tas2552.c
>   sound/soc/codecs/tas2764.c
>   sound/soc/codecs/tas2780.c
>   sound/soc/codecs/tas675x.c
>   sound/soc/codecs/wm8996.c
>   sound/soc/fsl/fsl_easrc.c
>   sound/soc/tegra/tegra210_admaif.c
>   sound/soc/tegra/tegra210_i2s.c
>   sound/soc/tegra/tegra210_mbdrc.c
>   sound/soc/tegra/tegra210_mixer.c
> 

-- 
Péter

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

[Charles Keepax]

On Wed, Aug 05, 2026 at 02:25:52PM +0300, Péter Ujfalusi wrote:
> 
> 
> On 05/08/2026 13:36, Richard Fitzgerald wrote:
> > On 05/08/2026 11:17 am, Péter Ujfalusi wrote:
> >>
> >>
> >> On 05/08/2026 13:10, Charles Keepax wrote:
> >>>>> I don't think we need to sort them. Just fail, so that an unsorted
> >>>>> table
> >>>>> must be fixed.
> >>>>
> >>>> That would be a big regression all around the place, ordering w/ the
> >>>> debug message if developer is interested is much better.
> >>>
> >>> I think I would come down between the two of you. I definitely
> >>> agree with Richard on don't sort them, just encourages drivers to
> >>> be wrong. But I also agree with you, don't hard fail. I would
> >>> vote for just print an error message and carry on. That way no
> >>> regressions, but also a nice big warning message to let people
> >>> know what is wrong when they see problems.
> >>
> >> I usually try to avoid alarming/annoying users with error messages, on
> >> the other hand I agree that w/o some pressure, these will never be
> >> corrected at root either ;)
> >>
> >> On the yet another hand, if the regcache have means to fix this, it
> >> might be put into use as well.
> >> A dev_warn at max to get attention or info level perhaps and fixing it
> >> up?
> >>
> > I asked Codex (GPT5) to search for all reg_default tables with out-of
> > order entries or duplicate entries, looking only at those assigned to
> > struct regmap_config.reg_defaults (some reg_defaults tables are used for
> > patching - those are allowed to be out-of-order).
> > 
> > It came up with this:
> > 
> > Restricting results to tables referenced by struct
> > regmap_config.reg_defaults, 39 files violate the rule:
> 
> and some of these have duplicate addresses with different default values.
> 
> I can send more fixes while I'm at this for the clear cases, for Cirrus,
> Realtek and TI I have sent few patches.
> 

I was just having a look at cs42l43 so you can skip that one
unless you already fixed it up.

Thanks,
Charles

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

[Péter Ujfalusi]

On 05/08/2026 14:31, Charles Keepax wrote:
>> I can send more fixes while I'm at this for the clear cases, for Cirrus,
>> Realtek and TI I have sent few patches.
>>
> 
> I was just having a look at cs42l43 so you can skip that one
> unless you already fixed it up.

Thanks, I will leave that out from my side.

-- 
Péter

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

[Richard Fitzgerald]

On 05/08/2026 12:31 pm, Charles Keepax wrote:
> On Wed, Aug 05, 2026 at 02:25:52PM +0300, Péter Ujfalusi wrote:
>>
>>
>> On 05/08/2026 13:36, Richard Fitzgerald wrote:
>>> On 05/08/2026 11:17 am, Péter Ujfalusi wrote:
>>>>
>>>>
>>>> On 05/08/2026 13:10, Charles Keepax wrote:
>>>>>>> I don't think we need to sort them. Just fail, so that an unsorted
>>>>>>> table
>>>>>>> must be fixed.
>>>>>>
>>>>>> That would be a big regression all around the place, ordering w/ the
>>>>>> debug message if developer is interested is much better.
>>>>>
>>>>> I think I would come down between the two of you. I definitely
>>>>> agree with Richard on don't sort them, just encourages drivers to
>>>>> be wrong. But I also agree with you, don't hard fail. I would
>>>>> vote for just print an error message and carry on. That way no
>>>>> regressions, but also a nice big warning message to let people
>>>>> know what is wrong when they see problems.
>>>>
>>>> I usually try to avoid alarming/annoying users with error messages, on
>>>> the other hand I agree that w/o some pressure, these will never be
>>>> corrected at root either ;)
>>>>
>>>> On the yet another hand, if the regcache have means to fix this, it
>>>> might be put into use as well.
>>>> A dev_warn at max to get attention or info level perhaps and fixing it
>>>> up?
>>>>
>>> I asked Codex (GPT5) to search for all reg_default tables with out-of
>>> order entries or duplicate entries, looking only at those assigned to
>>> struct regmap_config.reg_defaults (some reg_defaults tables are used for
>>> patching - those are allowed to be out-of-order).
>>>
>>> It came up with this:
>>>
>>> Restricting results to tables referenced by struct
>>> regmap_config.reg_defaults, 39 files violate the rule:
>>
>> and some of these have duplicate addresses with different default values.
>>
>> I can send more fixes while I'm at this for the clear cases, for Cirrus,
>> Realtek and TI I have sent few patches.
>>
> 
> I was just having a look at cs42l43 so you can skip that one
> unless you already fixed it up.
> 
> Thanks,
> Charles

And I've sent a patch to fix cs_dsp_mock_regmap.c. That one was actually
defining the table in order but had a typo in one of the addresses.

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

[Péter Ujfalusi]

On 05/08/2026 12:00, Richard Fitzgerald wrote:
>> 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.

We have seen these 'soundwire_intel.link.0: Msg ignored for Slave 6'
type off messages in random cases, but with a series which check the
regcache_sync return value some codec's resume started to fail.
"*: Propagate regcache_sync() errors"

So, yes, register values generated by magic macros are hard to keep in
order, I completely agree.

-- 
Péter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Wed, Aug 05, 2026 at 10:40:46AM +0200, Pierre-Louis Bossart wrote:

> 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.

We could also sort when we copy the defaults during device init rather
than warning, at the moment we just kmemdup() the defaults array which
we later do binary searches on.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Charles Keepax]

On Wed, Aug 05, 2026 at 11:24:10AM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> 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.
> 
> Regards,
> Peter
> 
> Peter Ujfalusi (3):
>   ASoC: cs35l41: sort the register default table
>   ASoC: cs35l45: sort the register default table
>   ASoC: cs4265: sort the register default table
> 
>  sound/soc/codecs/cs35l41-lib.c    |  2 +-
>  sound/soc/codecs/cs35l45-tables.c | 32 +++++++++++++++----------------
>  sound/soc/codecs/cs4265.c         |  4 ++--
>  3 files changed, 19 insertions(+), 19 deletions(-)

Good spot.

Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>

Thanks,
Charles

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

[Mark Brown]

On Wed, 05 Aug 2026 11:24:10 +0300, Peter Ujfalusi wrote:
> ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables
> 
> Hi,
> 
> 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").
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2

Thanks!

[1/3] ASoC: cs35l41: sort the register default table
      https://git.kernel.org/broonie/sound/c/d74aac116cfb
[2/3] ASoC: cs35l45: sort the register default table
      https://git.kernel.org/broonie/sound/c/f39a68ed08bb
[3/3] ASoC: cs4265: sort the register default table
      https://git.kernel.org/broonie/sound/c/e4fe3e046524

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark