[PATCH] ASoC: cs35l56: Fix illegal writes to OTP_MEM registers

[PATCH] ASoC: cs35l56: Fix illegal writes to OTP_MEM registers

[Richard Fitzgerald]

Mark the OTP_MEM registers as volatile so that regcache_sync() will not
attempt to write to them.

These registers hold a constant, and originally they were marked as
readable non-volatile so that this value would be read into the regmap
cache. The problem with this is regcache_sync() issues a write for any
cached register that does not have a reg_default.

Though these registers are constants and writing them in normal use
cannot change OTP, it is illegal for the host to write to them.

Fixes: e1830f66f6c6 ("ASoC: cs35l56: Add helper functions for amp calibration")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 sound/soc/codecs/cs35l56-shared.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/cs35l56-shared.c b/sound/soc/codecs/cs35l56-shared.c
index e05d975ba794..033e56d5e9db 100644
--- a/sound/soc/codecs/cs35l56-shared.c
+++ b/sound/soc/codecs/cs35l56-shared.c
@@ -108,8 +108,6 @@ int cs35l56_set_patch(struct cs35l56_base *cs35l56_base)
 EXPORT_SYMBOL_NS_GPL(cs35l56_set_patch, "SND_SOC_CS35L56_SHARED");
 
 static const struct reg_default cs35l56_reg_defaults[] = {
-	/* no defaults for OTP_MEM - first read populates cache */
-
 	{ CS35L56_ASP1_ENABLES1,		0x00000000 },
 	{ CS35L56_ASP1_CONTROL1,		0x00000028 },
 	{ CS35L56_ASP1_CONTROL2,		0x18180200 },
@@ -138,8 +136,6 @@ static const struct reg_default cs35l56_reg_defaults[] = {
 };
 
 static const struct reg_default cs35l63_reg_defaults[] = {
-	/* no defaults for OTP_MEM - first read populates cache */
-
 	{ CS35L56_ASP1_ENABLES1,		0x00000000 },
 	{ CS35L56_ASP1_CONTROL1,		0x00000028 },
 	{ CS35L56_ASP1_CONTROL2,		0x18180200 },
@@ -282,6 +278,9 @@ static bool cs35l56_common_volatile_reg(unsigned int reg)
 	case CS35L56_GLOBAL_ENABLES:		   /* owned by firmware */
 	case CS35L56_BLOCK_ENABLES:		   /* owned by firmware */
 	case CS35L56_BLOCK_ENABLES2:		   /* owned by firmware */
+	case CS35L56_OTP_MEM_53:
+	case CS35L56_OTP_MEM_54:
+	case CS35L56_OTP_MEM_55:
 	case CS35L56_SYNC_GPIO1_CFG ... CS35L56_ASP2_DIO_GPIO13_CFG:
 	case CS35L56_UPDATE_REGS:
 	case CS35L56_REFCLK_INPUT:		   /* owned by firmware */
-- 
2.47.3

Re: [PATCH] ASoC: cs35l56: Fix illegal writes to OTP_MEM registers

[Mark Brown]

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

On Tue, Apr 28, 2026 at 12:52:28PM +0100, Richard Fitzgerald wrote:

> These registers hold a constant, and originally they were marked as
> readable non-volatile so that this value would be read into the regmap
> cache. The problem with this is regcache_sync() issues a write for any
> cached register that does not have a reg_default.

This feels like something that's common enough to be worth teaching the
regmap core about.

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

Re: [PATCH] ASoC: cs35l56: Fix illegal writes to OTP_MEM registers

[Mark Brown]

On Tue, 28 Apr 2026 12:52:28 +0100, Richard Fitzgerald wrote:
> ASoC: cs35l56: Fix illegal writes to OTP_MEM registers

Applied to

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

Thanks!

[1/1] ASoC: cs35l56: Fix illegal writes to OTP_MEM registers
      https://git.kernel.org/broonie/sound/c/be102efb832e

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