Re: [PATCH 08/28] ALSA: control: Add kcontrol callbacks for lock/unlock

[James Calligeros <jcalligeros99@gmail.com>]

On Tuesday, 29 September 2026 7:52:59 pm Australian Eastern Standard Time 
Takashi Iwai wrote:
> On Sun, 20 Sep 2026 06:53:47 +0200,
> 
> James Calligeros wrote:
> > From: Hector Martin <marcan@marcan.st>
> > 
> > This allows drivers to implement policy around locking/unlocking
> > controls, such as enforcing that a group of controls may only be locked
> > by the same process/file, and taking actions when the controls
> > lock/unlock (such as granting special access on lock and resetting
> > values on unlock).
> > 
> > This is, in particular, useful to implement volume safety controls, such
> > that only a particular process (that locks controls and completes a
> > handshake) may increase volumes above a given safe limit. It also allows
> > the volume to be automatically lowered if that process dies (which will
> > trigger an implicit unlock).
> > 
> > Signed-off-by: Hector Martin <marcan@marcan.st>
> > Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> 
> This doesn't sound like a good approach to me, and this looks rather
> irrelevant with the purpose of the series.

I'm not sure what you mean by it being irrelevant. A significant portion
of the machine driver is dedicated to implementing safety interlocks based
on the functionality added via this patch. It would be impossible to prevent
badly-behaving users{,pace} from defeating the safety guarantees made by
speakersafetyd (and thus permanently damaging the machine) without giving
speakersafetd exclusive ownership over the safety interlock kcontrol.

Is there something specific about this approach that you do not like?

> 
> thanks,
> 
> Takashi

James