linux-kernel - RE: [PATCH v2] ALSA: hda: cs35l56: Stop creating ALSA controls for firmware coefficients

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <002c01dae359$733e2ce0$59ba86a0$@opensource.cirrus.com>
Date: Wed, 31 Jul 2024 15:53:48 +0100
From: Simon Trimmer <simont@...nsource.cirrus.com>
To: <tiwai@...e.com>
CC: <linux-sound@...r.kernel.org>, <alsa-devel@...a-project.org>,
        <linux-kernel@...r.kernel.org>, <patches@...nsource.cirrus.com>
Subject: RE: [PATCH v2] ALSA: hda: cs35l56: Stop creating ALSA controls for firmware coefficients

Takashi - whilst the reasons for not adding the ALSA controls are different
to
those of the CS35L41, given the dislike about being able to re-enable them
using a kernel parameter for debugging we'll send a V3 that removes all the
firmware control support.

Thanks
-Simon

> -----Original Message-----
> From: Simon Trimmer <simont@...nsource.cirrus.com>
> Sent: Tuesday, July 30, 2024 5:29 PM
> To: tiwai@...e.com
> Cc: linux-sound@...r.kernel.org; alsa-devel@...a-project.org; linux-
> kernel@...r.kernel.org; patches@...nsource.cirrus.com; Simon Trimmer
> <simont@...nsource.cirrus.com>
> Subject: [PATCH v2] ALSA: hda: cs35l56: Stop creating ALSA controls for
> firmware coefficients
> 
> A number of laptops have gone to market with old firmware versions that
> export controls that have since been hidden, but we can't just install a
> newer firmware because the firmware for each product is customized and
> qualified by the OEM. The issue is that alsactl save and restore has no
> idea what controls are good to persist which can lead to
> misconfiguration.
> 
> As the ALSA controls for the firmware coefficients are not used in
> normal operation they can all be hidden, but add a kernel parameter so
> that they can be re-enabled for debugging.
> 
> Signed-off-by: Simon Trimmer <simont@...nsource.cirrus.com>
> ---
> Changes in v2:
> - v1 was accidentally the backport version for older kernels instead of
>   the one for v6.11
> 
>  sound/pci/hda/cs35l56_hda.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/pci/hda/cs35l56_hda.c b/sound/pci/hda/cs35l56_hda.c
> index 96d3f13c5abf..f2f623f713d1 100644
> --- a/sound/pci/hda/cs35l56_hda.c
> +++ b/sound/pci/hda/cs35l56_hda.c
> @@ -23,6 +23,10 @@
>  #include "hda_cs_dsp_ctl.h"
>  #include "hda_generic.h"
> 
> +static bool expose_dsp_controls;
> +module_param(expose_dsp_controls, bool, 0444);
> +MODULE_PARM_DESC(expose_dsp_controls, "Expose firmware controls as
> ALSA controls 0=no (default), 1=yes");
> +
>   /*
>    * The cs35l56_hda_dai_config[] reg sequence configures the device as
>    *  ASP1_BCLK_FREQ = 3.072 MHz
> @@ -613,7 +617,7 @@ static void cs35l56_hda_fw_load(struct cs35l56_hda
> *cs35l56)
>  	 */
>  	if (cs35l56->base.fw_patched)
>  		cs_dsp_power_down(&cs35l56->cs_dsp);
> -	else
> +	else if (expose_dsp_controls)
>  		add_dsp_controls_required = true;
> 
>  	cs35l56->base.fw_patched = false;
> --
> 2.43.0