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)