ASoC: ops: Fix wraparound for mask in snd_soc_get_volsw

[ Upstream commit fc563aa900659a850e2ada4af26b9d7a3de6c591 ]

In snd_soc_info_volsw(), mask is generated by figuring out the index of
the most

ASoC: ops: Fix wraparound for mask in snd_soc_get_volsw

[ Upstream commit fc563aa900659a850e2ada4af26b9d7a3de6c591 ]

In snd_soc_info_volsw(), mask is generated by figuring out the index of
the most significant bit set in max and converting the index to a
bitmask through bit shift 1. Unintended wraparound occurs when max is an
integer value with msb bit set. Since the bit shift value 1 is treated
as an integer type, the left shift operation will wraparound and set
mask to 0 instead of all 1's. In order to fix this, we type cast 1 as
`1ULL` to prevent the wraparound.

Fixes: 7077148fb50a ("ASoC: core: Split ops out of soc-core.c")
Signed-off-by: Stephen Lee <slee08177@gmail.com>
Link: https://msgid.link/r/20240326010131.6211-1-slee08177@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

ASoC: ops: add correct range check for limiting volume

commit fb9ad24485087e0f00d84bee7a5914640b2b9024 upstream.

Volume can have ranges that start with negative values, ex: -84dB to
+40dB. Apply co

ASoC: ops: add correct range check for limiting volume

commit fb9ad24485087e0f00d84bee7a5914640b2b9024 upstream.

Volume can have ranges that start with negative values, ex: -84dB to
+40dB. Apply correct range check in snd_soc_limit_volume before setting
the platform_max. Without this patch, for example setting a 0dB limit on
a volume range of -84dB to +40dB would fail.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20231204124736.132185-2-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

ASoC: ops: Correct bounds check for second channel on SX controls

Currently the check against the max value for the control is being
applied after the value has had the minimum applied and been mask

ASoC: ops: Correct bounds check for second channel on SX controls

Currently the check against the max value for the control is being
applied after the value has had the minimum applied and been masked. But
the max value simply indicates the number of volume levels on an SX
control, and as such should just be applied on the raw value.

Fixes: 97eea946b939 ("ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221125162348.1288005-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix integer detection for when max possible values > 1

The standard snd_soc_info_volsw() allows a two value control to be
defined as an integer control only if the control name ends in
"V

ASoC: ops: Fix integer detection for when max possible values > 1

The standard snd_soc_info_volsw() allows a two value control to be
defined as an integer control only if the control name ends in
"Volume". It achieves this by creating a substring if it contains
" Volume", and ensuring this exists at the end of the name. The
volume substring is then used to decide whether the type is a
SNDRV_CTL_ELEM_TYPE_INTEGER or SNDRV_CTL_ELEM_TYPE_BOOLEAN.
However this volume substring is only computed for a two value
control.
This means for controls where there are more than two possible
values, the substring is never created, so in this case the
substring remains NULL, and the condition yields
SNDRV_CTL_ELEM_TYPE_BOOLEAN, even though there are more than 2
possible values.
If there are more than 2 possible values for the control,
then it should always be an integer control.

Fixes: aa2a4b897132 ("ASoC: ops: Fix boolean/integer detection for simple controls")

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220617153606.2619457-1-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix boolean/integer detection for simple controls

The standard snd_soc_info_volsw() detects if a control is a volume control
and needs to be reported as an integer even if it only has two

ASoC: ops: Fix boolean/integer detection for simple controls

The standard snd_soc_info_volsw() detects if a control is a volume control
and needs to be reported as an integer even if it only has two values by
looking for the string " Volume" in the control name. This results in false
positives if the control has a name like "HP Volume Ramp Switch" since any
" Volume" is matched, not just a trailing one. Fix this by making sure that
we only match at the end of the control name.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220604105407.4055294-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Don't modify the driver's plaform_max when reading state

Currently snd_soc_info_volsw() will set a platform_max based on the limit
the control has if one is not already set. This isn't re

ASoC: ops: Don't modify the driver's plaform_max when reading state

Currently snd_soc_info_volsw() will set a platform_max based on the limit
the control has if one is not already set. This isn't really great, we
shouldn't be modifying the passed in driver data especially in a path like
this which may not ever be executed or where we may execute other callbacks
before this one. Instead make this function leave the data unchanged, and
clarify things a bit by referring to max rather than platform_max within
the function. platform_max is now applied as a limit after working out the
natural maximum value for the control.

This means that platform_max is no longer treated as a direct register
value for controls were min is non-zero. The put() callbacks already
validate on this basis, and there do not appear to be any in tree users
that would be affected.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220603112508.3856519-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix off by one in range control validation

We currently report that range controls accept a range of 0..(max-min) but
accept writes in the range 0..(max-min+1). Remove that extra +1.

Sig

ASoC: ops: Fix off by one in range control validation

We currently report that range controls accept a range of 0..(max-min) but
accept writes in the range 0..(max-min+1). Remove that extra +1.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220604105246.4055214-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Remove unneeded delay.h inclusion

The ops code does not do any sleeps or delays so does not need delay.h.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/2

ASoC: ops: Remove unneeded delay.h inclusion

The ops code does not do any sleeps or delays so does not need delay.h.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220602101833.3481641-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Clarify snd_soc_info_volsw_sx()

Currently snd_soc_info_volsw_sx() is implemented indirectly, wrapping
snd_soc_info_volsw() and modifying the values it sets up rather than
directly setting

ASoC: ops: Clarify snd_soc_info_volsw_sx()

Currently snd_soc_info_volsw_sx() is implemented indirectly, wrapping
snd_soc_info_volsw() and modifying the values it sets up rather than
directly setting up the values reported to userspace. This makes it much
harder to follow what the intended behaviour of these controls is. Let's
rewrite the function to be self contained with a clarifying comment at the
top in an effort to help maintainability.

Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220602092921.3302713-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()

The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of b

ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()

The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220511134137.169575-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix bounds check for _sx controls

For _sx controls the semantics of the max field is not the usual one, max
is the number of steps rather than the maximum value. This means that our
check

ASoC: ops: Fix bounds check for _sx controls

For _sx controls the semantics of the max field is not the usual one, max
is the number of steps rather than the maximum value. This means that our
check in snd_soc_put_volsw_sx() needs to just check against the maximum
value.

Fixes: 4f1e50d6a9cf9c1b ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220511134137.169575-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Validate input values in snd_soc_put_volsw_range()

Check that values written via snd_soc_put_volsw_range() are
within the range advertised by the control, ensuring that we
don't write out

ASoC: ops: Validate input values in snd_soc_put_volsw_range()

Check that values written via snd_soc_put_volsw_range() are
within the range advertised by the control, ensuring that we
don't write out of spec values to the hardware.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220423131239.3375261-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: soc-ops: fix error handling

cppcheck throws the following warning:

sound/soc/soc-ops.c:461:8: style: Variable 'ret' is assigned a value
that is never used. [unreadVariable]
ret = err;

ASoC: soc-ops: fix error handling

cppcheck throws the following warning:

sound/soc/soc-ops.c:461:8: style: Variable 'ret' is assigned a value
that is never used. [unreadVariable]
ret = err;
^

This seems to be a missing change in the return value.

Fixes: 7f3d90a351968 ("ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()")
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220421162328.302017-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min

While the $val/$val2 values passed in from userspace are always >= 0
integers, the limits of the control can be signed integers and the

ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min

While the $val/$val2 values passed in from userspace are always >= 0
integers, the limits of the control can be signed integers and the $min
can be non-zero and less than zero. To correctly validate $val/$val2
against platform_max, add the $min offset to val first.

Fixes: 817f7c9335ec0 ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220215130645.164025-1-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix stereo change notifications in snd_soc_put_xr_sx()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only generated

ASoC: ops: Fix stereo change notifications in snd_soc_put_xr_sx()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only generated based on changes
to the second channel. Ensure that we report a change if either channel
has changed.

Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220201155629.120510-5-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_range()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only gene

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_range()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only generated based on changes
to the second channel. Ensure that we report a change if either channel
has changed.

Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220201155629.120510-4-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only generat

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only generated based on changes
to the second channel. Ensure that we report a change if either channel
has changed.

Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220201155629.120510-3-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only generated

ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw()

When writing out a stereo control we discard the change notification from
the first channel, meaning that events are only generated based on changes
to the second channel. Ensure that we report a change if either channel
has changed.

Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220201155629.120510-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Check for negative values before reading them

The controls allow inputs to be specified as negative but our manipulating
them into register fields need to be done on unsigned variables so

ASoC: ops: Check for negative values before reading them

The controls allow inputs to be specified as negative but our manipulating
them into register fields need to be done on unsigned variables so the
checks for negative numbers weren't taking effect properly. Do the checks
for negative values on the variable in the ABI struct rather than on our
local unsigned copy.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220128192443.3504823-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Reject out of bounds values in snd_soc_put_xr_sx()

We don't currently validate that the values being set are within the range
we advertised to userspace as being valid, do so and reject a

ASoC: ops: Reject out of bounds values in snd_soc_put_xr_sx()

We don't currently validate that the values being set are within the range
we advertised to userspace as being valid, do so and reject any values
that are out of range.

Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220124153253.3548853-4-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()

We don't currently validate that the values being set are within the range
we advertised to userspace as being valid, do so and rejec

ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()

We don't currently validate that the values being set are within the range
we advertised to userspace as being valid, do so and reject any values
that are out of range.

Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220124153253.3548853-3-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()

We don't currently validate that the values being set are within the range
we advertised to userspace as being valid, do so and reject a

ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()

We don't currently validate that the values being set are within the range
we advertised to userspace as being valid, do so and reject any values
that are out of range.

Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220124153253.3548853-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ASoC: ops: Fix off by one in range control validation

[ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ]

We currently report that range controls accept a range of 0..(max-min) but
accept

ASoC: ops: Fix off by one in range control validation

[ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ]

We currently report that range controls accept a range of 0..(max-min) but
accept writes in the range 0..(max-min+1). Remove that extra +1.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220604105246.4055214-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

ASoC: ops: Fix off by one in range control validation

[ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ]

We currently report that range controls accept a range of 0..(max-min) but
accept

ASoC: ops: Fix off by one in range control validation

[ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ]

We currently report that range controls accept a range of 0..(max-min) but
accept writes in the range 0..(max-min+1). Remove that extra +1.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220604105246.4055214-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

ASoC: ops: Fix off by one in range control validation

[ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ]

We currently report that range controls accept a range of 0..(max-min) but
accept

ASoC: ops: Fix off by one in range control validation

[ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ]

We currently report that range controls accept a range of 0..(max-min) but
accept writes in the range 0..(max-min+1). Remove that extra +1.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220604105246.4055214-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...