[PATCH AUTOSEL 6.17] ASoC: ops: improve snd_soc_get_volsw

[Sasha Levin <sashal@kernel.org>]

From: Niranjan H Y <niranjan.hy@ti.com>

[ Upstream commit a0ce874cfaaab9792d657440b9d050e2112f6e4d ]

* clamp the values if the register value read is
  out of range

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
[This patch originally had two changes in it, I removed a second buggy
 one -- broonie]
--
v5:
 - remove clamp parameter
 - move the boundary check after sign-bit extension
Link: https://patch.msgid.link/20250912083624.804-1-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- The fix clamps the register-derived value before it is re-based in
  `soc_mixer_reg_to_ctl()` (`sound/soc/soc-ops.c:113-127`), preventing
  it from wandering outside `[mc->min, mc->max]`. Without this, any
  register value below `mc->min` (common when a codec powers up with
  zero while the control’s logical minimum is >0 or negative) underflows
  when `mc->min` is subtracted and then wraps through the `& mask`, so
  userspace can observe bogus values above the advertised maximum from
  `snd_soc_get_volsw()` and `snd_soc_get_volsw_sx()`. That mismatch
  breaks ALSA controls built with `SOC_SINGLE_RANGE`,
  `SOC_DOUBLE_R_RANGE`, `SOC_*_S8_TLV`, etc., all of which rely on the
  helper to enforce the declared range.
- Hardware already rejects out-of-range writes via
  `soc_mixer_valid_ctl()`/`soc_mixer_ctl_to_reg()` (`sound/soc/soc-
  ops.c:160-205`), so the user-visible read path was the lone gap;
  adding `clamp()` makes readback consistent with the rest of the
  subsystem and the limits reported by `soc_info_volsw()`.
- This bug is long-standing: older kernels (e.g. v6.9’s
  `snd_soc_get_volsw_sx`) perform the same `value - min` arithmetic
  without any bounds check before masking, so stable trees inherit the
  same failure mode. Backporting only adds the clamp line and has no
  architectural fallout or API change.
- Risk is minimal: `clamp()` is already available, the new bound check
  happens after optional sign-extension (meeting the requirement for
  signed controls), and only narrows the set of values we propagate to
  userspace. Given it fixes real misreports while touching a single
  helper used by all range-aware mixer gets, it fits stable policy well.

Next steps: consider sanity-testing a couple of affected controls (e.g.
via `amixer`) on hardware that boots with out-of-range defaults to
confirm the user-visible values now saturate instead of wrapping.

 sound/soc/soc-ops.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
index a629e0eacb20e..d2b6fb8e0b6c6 100644
--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -118,6 +118,7 @@ static int soc_mixer_reg_to_ctl(struct soc_mixer_control *mc, unsigned int reg_v
 	if (mc->sign_bit)
 		val = sign_extend32(val, mc->sign_bit);
 
+	val = clamp(val, mc->min, mc->max);
 	val -= mc->min;
 
 	if (mc->invert)
-- 
2.51.0