[PATCH 0/3] ASoC: mt6358: Fixes from an initial glance at a kselftest run
This is a collection of fixes I came up after glancing through an initial test run with the snappily named Kukui Jacuzzi SKU16 Chromebook on KernelCI. There are more issues flagged, this is just what I fixed thus far.
Signed-off-by: Mark Brown broonie@kernel.org --- Mark Brown (3): ASoC: mt6358: Fix event generation for wake on voice stage 2 switch ASoC: mt6358: Validate Wake on Voice 2 writes ASoC: mt6358: Remove undefined HPx Mux enumeration values
sound/soc/codecs/mt6358.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) --- base-commit: d2980d8d826554fa6981d621e569a453787472f8 change-id: 20230224-asoc-mt6358-quick-fixes-71b4ea6b8f13
Best regards,
ALSA control put() operations should return 0 if the value changed so that events can be generated appropriately for userspace but the custom control for wake on voice stage 2 doesn't do this, fix it.
Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/codecs/mt6358.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/mt6358.c b/sound/soc/codecs/mt6358.c index 93f35e8d26fc..9004377461f7 100644 --- a/sound/soc/codecs/mt6358.c +++ b/sound/soc/codecs/mt6358.c @@ -567,6 +567,8 @@ static int mt6358_put_wov(struct snd_kcontrol *kcontrol, mt6358_disable_wov_phase2(priv);
priv->wov_enabled = enabled; + + return 1; }
return 0;
Il 26/02/23 13:47, Mark Brown ha scritto:
ALSA control put() operations should return 0 if the value changed so that events can be generated appropriately for userspace but the custom control for wake on voice stage 2 doesn't do this, fix it.
Signed-off-by: Mark Brown broonie@kernel.org
Reviewed-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com
Currently the Wake on Voice 2 control accepts and stores any value written but it reports that only 0 and 1 are valid values. Reject any out of range values written by userspace.
Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/codecs/mt6358.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/soc/codecs/mt6358.c b/sound/soc/codecs/mt6358.c index 9004377461f7..89d0dcb2635b 100644 --- a/sound/soc/codecs/mt6358.c +++ b/sound/soc/codecs/mt6358.c @@ -560,6 +560,9 @@ static int mt6358_put_wov(struct snd_kcontrol *kcontrol, struct mt6358_priv *priv = snd_soc_component_get_drvdata(c); int enabled = ucontrol->value.integer.value[0];
+ if (enabled < 0 || enabled > 1) + return -EINVAL; + if (priv->wov_enabled != enabled) { if (enabled) mt6358_enable_wov_phase2(priv);
Il 26/02/23 13:47, Mark Brown ha scritto:
Currently the Wake on Voice 2 control accepts and stores any value written but it reports that only 0 and 1 are valid values. Reject any out of range values written by userspace.
Signed-off-by: Mark Brown broonie@kernel.org
Reviewed-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com
The HPx Mux enumerations define values 5, 6 and 7 but describe them as "undefined" and map them to the value 0 on writing. Given the descriptions and behaviour it seems that these values are invalid and should not be present in the register, the current behaviour is detected as problematic by mixer-test:
# # HPL Mux.0 expected 5 but read 0, is_volatile 0 # # HPL Mux.0 expected 6 but read 0, is_volatile 0 # # HPL Mux.0 expected 7 but read 0, is_volatile 0
Remove the values from the enumeration, this will prevent userspace setting them.
Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/codecs/mt6358.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/sound/soc/codecs/mt6358.c b/sound/soc/codecs/mt6358.c index 89d0dcb2635b..b54610b27906 100644 --- a/sound/soc/codecs/mt6358.c +++ b/sound/soc/codecs/mt6358.c @@ -637,9 +637,6 @@ static const char * const hp_in_mux_map[] = { "Audio Playback", "Test Mode", "HP Impedance", - "undefined1", - "undefined2", - "undefined3", };
static int hp_in_mux_map_value[] = { @@ -648,9 +645,6 @@ static int hp_in_mux_map_value[] = { HP_MUX_HP, HP_MUX_TEST_MODE, HP_MUX_HP_IMPEDANCE, - HP_MUX_OPEN, - HP_MUX_OPEN, - HP_MUX_OPEN, };
static SOC_VALUE_ENUM_SINGLE_DECL(hpl_in_mux_map_enum,
Il 26/02/23 13:47, Mark Brown ha scritto:
The HPx Mux enumerations define values 5, 6 and 7 but describe them as "undefined" and map them to the value 0 on writing. Given the descriptions and behaviour it seems that these values are invalid and should not be present in the register, the current behaviour is detected as problematic by mixer-test:
# # HPL Mux.0 expected 5 but read 0, is_volatile 0 # # HPL Mux.0 expected 6 but read 0, is_volatile 0 # # HPL Mux.0 expected 7 but read 0, is_volatile 0
Remove the values from the enumeration, this will prevent userspace setting them.
Signed-off-by: Mark Brown broonie@kernel.org
Reviewed-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com
On Sun, 26 Feb 2023 12:47:55 +0000, Mark Brown wrote:
This is a collection of fixes I came up after glancing through an initial test run with the snappily named Kukui Jacuzzi SKU16 Chromebook on KernelCI. There are more issues flagged, this is just what I fixed thus far.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/3] ASoC: mt6358: Fix event generation for wake on voice stage 2 switch commit: 3425ddaea57af77ca96a59a5b8eaa2f9e1b021ba [2/3] ASoC: mt6358: Validate Wake on Voice 2 writes commit: 8e847a43c28fca0aaa11fba8f91da7dfd9d6936f [3/3] ASoC: mt6358: Remove undefined HPx Mux enumeration values commit: 8cbd7273a724d4e9615b26d696bb1221a8a48e4c
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
participants (2)
-
AngeloGioacchino Del Regno
-
Mark Brown