linux-kernel - Re: [PATCH v1] ALSA: hda: cs35l41: 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87zfpxyht3.wl-tiwai@suse.de>
Date: Wed, 31 Jul 2024 12:30:48 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Jaroslav Kysela <perex@...ex.cz>
Cc: Stefan Binding <sbinding@...nsource.cirrus.com>,
	Takashi Iwai <tiwai@...e.com>,
	alsa-devel@...a-project.org,
	linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	patches@...nsource.cirrus.com
Subject: Re: [PATCH v1] ALSA: hda: cs35l41: Stop creating ALSA Controls for firmware coefficients

On Tue, 30 Jul 2024 16:55:19 +0200,
Jaroslav Kysela wrote:
> 
> On 30. 07. 24 16:37, Stefan Binding wrote:
> > Add a kernel parameter to allow coefficients to be exposed as ALSA controls.
> > 
> > When the CS35L41 loads its firmware, it has a number of controls to
> > affect its behaviour. Currently, these controls are exposed as ALSA
> > Controls by default.
> > 
> > However, nothing in userspace currently uses them, and is unlikely to
> > do so in the future, therefore we don't need to create ASLA controls
> > for them.
> > 
> > These controls can be useful for debug, so we can add a kernel
> > parameter to re-enable them if necessary.
> > 
> > Disabling these controls would prevent userspace from trying to read
> > these controls when the CS35L41 is hibernating, which ordinarily
> > would result in an error message.
> 
> This is probably not a right argument to add this code. The codec
> should be powered up when those controls are accessed or those
> controls should be cached by the driver.
> 
> Although the controls have not been used yet, exposing them in this
> way is not ideal.
> 
> Could you fix the driver (no I/O errors)?

While we should fix the potential errors at hibernation, it's not bad
to hide those controls, IMO.  For the normal use cases, it's nothing
but a cause of troubles, after all.


thanks,

Takashi