[PATCH] ALSA: hda: cs35l56: Propagate ASP TX source control errors

[PATCH] ALSA: hda: cs35l56: Propagate ASP TX source control errors

[Cássio Gabriel]

cs35l56_hda_mixer_get() ignores regmap_read() and
cs35l56_hda_mixer_put() ignores regmap_update_bits_check().

This makes the ASP TX source controls report success when a regmap
access fails. The write path returns no change instead of an error,
and the read path continues after a failed read instead of aborting
the control callback.

Propagate the regmap errors, matching the posture and volume controls
in this driver.

Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier")
Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
 sound/hda/codecs/side-codecs/cs35l56_hda.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/sound/hda/codecs/side-codecs/cs35l56_hda.c b/sound/hda/codecs/side-codecs/cs35l56_hda.c
index 1ace4beef508..dc25960a4f23 100644
--- a/sound/hda/codecs/side-codecs/cs35l56_hda.c
+++ b/sound/hda/codecs/side-codecs/cs35l56_hda.c
@@ -180,11 +180,15 @@ static int cs35l56_hda_mixer_get(struct snd_kcontrol *kcontrol,
 {
 	struct cs35l56_hda *cs35l56 = snd_kcontrol_chip(kcontrol);
 	unsigned int reg_val;
-	int i;
+	int i, ret;
 
 	cs35l56_hda_wait_dsp_ready(cs35l56);
 
-	regmap_read(cs35l56->base.regmap, kcontrol->private_value, &reg_val);
+	ret = regmap_read(cs35l56->base.regmap, kcontrol->private_value,
+			  &reg_val);
+	if (ret)
+		return ret;
+
 	reg_val &= CS35L56_ASP_TXn_SRC_MASK;
 
 	for (i = 0; i < CS35L56_NUM_INPUT_SRC; ++i) {
@@ -203,15 +207,20 @@ static int cs35l56_hda_mixer_put(struct snd_kcontrol *kcontrol,
 	struct cs35l56_hda *cs35l56 = snd_kcontrol_chip(kcontrol);
 	unsigned int item = ucontrol->value.enumerated.item[0];
 	bool changed;
+	int ret;
 
 	if (item >= CS35L56_NUM_INPUT_SRC)
 		return -EINVAL;
 
 	cs35l56_hda_wait_dsp_ready(cs35l56);
 
-	regmap_update_bits_check(cs35l56->base.regmap, kcontrol->private_value,
-				 CS35L56_INPUT_MASK, cs35l56_tx_input_values[item],
-				 &changed);
+	ret = regmap_update_bits_check(cs35l56->base.regmap,
+				       kcontrol->private_value,
+				       CS35L56_INPUT_MASK,
+				       cs35l56_tx_input_values[item],
+				       &changed);
+	if (ret)
+		return ret;
 
 	return changed;
 }

---
base-commit: 876c495d412ef67bd4d0bdc4b74b0bd3d9f4e890
change-id: 20260420-alsa-cs35l56-asp-tx-source-errors-8d10c3258304

Best regards,
--  
Cássio Gabriel <cassiogabrielcontato@gmail.com>

Re: [PATCH] ALSA: hda: cs35l56: Propagate ASP TX source control errors

[Richard Fitzgerald]

On 23/04/2026 2:11 pm, Cássio Gabriel wrote:
> cs35l56_hda_mixer_get() ignores regmap_read() and
> cs35l56_hda_mixer_put() ignores regmap_update_bits_check().
> 
> This makes the ASP TX source controls report success when a regmap
> access fails. The write path returns no change instead of an error,
> and the read path continues after a failed read instead of aborting
> the control callback.

Are you seeing a problem on hardware? Or is this a static analysis
warning?

Re: [PATCH] ALSA: hda: cs35l56: Propagate ASP TX source control errors

[Cássio Gabriel Monteiro Pires]

[-- Attachment #1.1: Type: text/plain, Size: 1745 bytes --]

On 4/23/26 10:32, Richard Fitzgerald wrote:
> On 23/04/2026 2:11 pm, Cássio Gabriel wrote:
>> cs35l56_hda_mixer_get() ignores regmap_read() and
>> cs35l56_hda_mixer_put() ignores regmap_update_bits_check().
>>
>> This makes the ASP TX source controls report success when a regmap
>> access fails. The write path returns no change instead of an error,
>> and the read path continues after a failed read instead of aborting
>> the control callback.
> 
> Are you seeing a problem on hardware? Or is this a static analysis
> warning?

This was found by code inspection, then checked with a focused
Coccinelle rule (I do not have the hardware to check it).

Rule:

@ignored_regmap_read@
position p;
expression map, reg, val;
@@

regmap_read@p(map, reg, val);

@script:python depends on ignored_regmap_read@
p << ignored_regmap_read.p;
@@

coccilib.report.print_report(p[0], "ignored regmap_read() return value")

@ignored_regmap_update_bits_check@
position p;
expression map, reg, mask, val, change;
@@

regmap_update_bits_check@p(map, reg, mask, val, change);

@script:python depends on ignored_regmap_update_bits_check@
p << ignored_regmap_update_bits_check.p;
@@

coccilib.report.print_report(p[0], "ignored regmap_update_bits_check() return value")



Before the patch:
$ spatch --very-quiet --cocci-file /tmp/ignored-regmap-access.cocci /tmp/cs35l56_hda-before.c
/tmp/cs35l56_hda-before.c:187:1-12: ignored regmap_read() return value
/tmp/cs35l56_hda-before.c:212:1-25: ignored regmap_update_bits_check() return value

After the patch:
$ spatch --very-quiet --cocci-file /tmp/ignored-regmap-access.cocci sound/hda/codecs/side-
codecs/cs35l56_hda.c

No matches.

-- 
Thanks,
Cássio


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH] ALSA: hda: cs35l56: Propagate ASP TX source control errors

[Cássio Gabriel Monteiro Pires]

[-- Attachment #1.1: Type: text/plain, Size: 3086 bytes --]

On 4/23/26 11:09, Cássio Gabriel Monteiro Pires wrote:
> On 4/23/26 10:32, Richard Fitzgerald wrote:
>> On 23/04/2026 2:11 pm, Cássio Gabriel wrote:
>>> cs35l56_hda_mixer_get() ignores regmap_read() and
>>> cs35l56_hda_mixer_put() ignores regmap_update_bits_check().
>>>
>>> This makes the ASP TX source controls report success when a regmap
>>> access fails. The write path returns no change instead of an error,
>>> and the read path continues after a failed read instead of aborting
>>> the control callback.
>>
>> Are you seeing a problem on hardware? Or is this a static analysis
>> warning?
> 
> This was found by code inspection, then checked with a focused
> Coccinelle rule (I do not have the hardware to check it).
> 
> Rule:
> 
> @ignored_regmap_read@
> position p;
> expression map, reg, val;
> @@
> 
> regmap_read@p(map, reg, val);
> 
> @script:python depends on ignored_regmap_read@
> p << ignored_regmap_read.p;
> @@
> 
> coccilib.report.print_report(p[0], "ignored regmap_read() return value")
> 
> @ignored_regmap_update_bits_check@
> position p;
> expression map, reg, mask, val, change;
> @@
> 
> regmap_update_bits_check@p(map, reg, mask, val, change);
> 
> @script:python depends on ignored_regmap_update_bits_check@
> p << ignored_regmap_update_bits_check.p;
> @@
> 
> coccilib.report.print_report(p[0], "ignored regmap_update_bits_check() return value")
> 
> 
> 
> Before the patch:
> $ spatch --very-quiet --cocci-file /tmp/ignored-regmap-access.cocci /tmp/cs35l56_hda-before.c
> /tmp/cs35l56_hda-before.c:187:1-12: ignored regmap_read() return value
> /tmp/cs35l56_hda-before.c:212:1-25: ignored regmap_update_bits_check() return value
> 
> After the patch:
> $ spatch --very-quiet --cocci-file /tmp/ignored-regmap-access.cocci sound/hda/codecs/side-
> codecs/cs35l56_hda.c
> 
> No matches.

Hello,

Sorry for bothering you guys with this minor fix.

After further analysis checking the callback contract in the current tree:

ALSA propagates negative errors from control callbacks:

sound/core/control.c
ret = kctl->get(kctl, control);
if (ret < 0)
        return ret;

sound/core/control.c
result = snd_ctl_put(card, kctl, control, vd->access);
if (result < 0)
        return result;

regmap_update_bits_check() also sets *change = false before attempting
the access and returns an error if the read/write fails:

drivers/base/regmap/regmap.c
if (change)
        *change = false;
...
ret = _regmap_read(map, reg, &orig);
if (ret != 0)
        return ret;

Before the patch, cs35l56_hda_mixer_get() ignored regmap_read() and
cs35l56_hda_mixer_put() ignored regmap_update_bits_check(), so a real
regmap failure was being converted into a successful ALSA callback
return. In the put path that can become return 0, i.e. "success, no
change".

The sibling posture/volume callbacks in the same file already propagate
the regmap errors, so this brings the ASP TX source controls in line
with the rest of the driver.

Looking forward to know what you think.
Thanks!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]