[PATCH 0/2] ASoC: NXP/Freescale: sort the reg_defaults tables

[PATCH 0/2] ASoC: NXP/Freescale: sort the reg_defaults tables

[Peter Ujfalusi]

reg_defaults must be sorted by ascending register address, since
regcache_lookup_reg() locates entries in it with bsearch().  When a table is
not sorted, bsearch() cannot find the entries which follow a descending step,
so regcache_reg_needs_sync() falls back to reporting that a sync is needed for
them.  Those registers are then written to the device on every regcache_sync()
even when they were never touched.

See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays")
for the same problem in a different context.

The series is based on broonie/for-linus (05eebef3c7b2).

Affected tables:
  sgtl5000_reg_defaults    1 of 35 entries unreachable
  fsl_easrc_reg_defaults   3 of 120 entries unreachable

Peter Ujfalusi (2):
  ASoC: sgtl5000: sort the register default table
  ASoC: fsl_easrc: sort the register default table

 sound/soc/codecs/sgtl5000.c | 2 +-
 sound/soc/fsl/fsl_easrc.c   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.55.0

[PATCH 1/2] ASoC: sgtl5000: 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").

SGTL5000_CHIP_SHORT_CTRL (0x003c) is listed before
SGTL5000_CHIP_ANA_TEST2 (0x003a), which makes the former unreachable.
regcache_reg_needs_sync() then cannot compare it against its default and
reports that a sync is needed, so it is written to the device on every
regcache_sync() even when it was never touched.

Sort the table by register address.

Fixes: 29aa37cddfb9 ("ASoC: sgtl5000: Fix the cache handling")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
 sound/soc/codecs/sgtl5000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index 59642673b4cb..35df1a8c4c8c 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -56,8 +56,8 @@ static const struct reg_default sgtl5000_reg_defaults[] = {
 	{ SGTL5000_CHIP_PLL_CTRL,		0x5000 },
 	{ SGTL5000_CHIP_CLK_TOP_CTRL,		0x0000 },
 	{ SGTL5000_CHIP_ANA_STATUS,		0x0000 },
-	{ SGTL5000_CHIP_SHORT_CTRL,		0x0000 },
 	{ SGTL5000_CHIP_ANA_TEST2,		0x0000 },
+	{ SGTL5000_CHIP_SHORT_CTRL,		0x0000 },
 	{ SGTL5000_DAP_CTRL,			0x0000 },
 	{ SGTL5000_DAP_PEQ,			0x0000 },
 	{ SGTL5000_DAP_BASS_ENHANCE,		0x0040 },
-- 
2.55.0

[PATCH 2/2] ASoC: fsl_easrc: 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").

The four REG_EASRC_RRL() entries are listed as a block before the four
REG_EASRC_RRH() ones, but the two registers of a context alternate in
the address map (RRL(n) at 0x110 + 8 * n, RRH(n) at 0x114 + 8 * n).
This leaves REG_EASRC_RRL(1), REG_EASRC_RRL(2) and REG_EASRC_RRL(3)
unreachable.  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: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
 sound/soc/fsl/fsl_easrc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 8535ef844ce0..6ccba3706b58 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1711,12 +1711,12 @@ static const struct reg_default fsl_easrc_reg_defaults[] = {
 	{REG_EASRC_SFS(2),	0x00000000},
 	{REG_EASRC_SFS(3),	0x00000000},
 	{REG_EASRC_RRL(0),	0x00000000},
-	{REG_EASRC_RRL(1),	0x00000000},
-	{REG_EASRC_RRL(2),	0x00000000},
-	{REG_EASRC_RRL(3),	0x00000000},
 	{REG_EASRC_RRH(0),	0x00000000},
+	{REG_EASRC_RRL(1),	0x00000000},
 	{REG_EASRC_RRH(1),	0x00000000},
+	{REG_EASRC_RRL(2),	0x00000000},
 	{REG_EASRC_RRH(2),	0x00000000},
+	{REG_EASRC_RRL(3),	0x00000000},
 	{REG_EASRC_RRH(3),	0x00000000},
 	{REG_EASRC_RUC(0),	0x00000000},
 	{REG_EASRC_RUC(1),	0x00000000},
-- 
2.55.0

Re: [PATCH 0/2] ASoC: NXP/Freescale: sort the reg_defaults tables

[Mark Brown]

On Wed, 05 Aug 2026 15:27:26 +0300, Peter Ujfalusi wrote:
> ASoC: NXP/Freescale: sort the reg_defaults tables
> 
> reg_defaults must be sorted by ascending register address, since
> regcache_lookup_reg() locates entries in it with bsearch().  When a table is
> not sorted, bsearch() cannot find the entries which follow a descending step,
> so regcache_reg_needs_sync() falls back to reporting that a sync is needed for
> them.  Those registers are then written to the device on every regcache_sync()
> even when they were never touched.
> 
> [...]

Applied to

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

Thanks!

[1/2] ASoC: sgtl5000: sort the register default table
      https://git.kernel.org/broonie/sound/c/437fbdeb6069
[2/2] ASoC: fsl_easrc: sort the register default table
      https://git.kernel.org/broonie/sound/c/84c5d79aebe6

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