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

[Takashi Iwai]

On Sat, 03 Oct 2026 03:34:07 +0200,
James Calligeros wrote:
> 
> 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 at 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 at marcan.st>
> > > Signed-off-by: James Calligeros <jcalligeros99 at 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.

Improving the lock/unlock itself can be an interesting idea (but we
should do in a different way instead of blindly extending each kernel
control ops).  OTOH, the whole implementation of the driver and the
feature depending on that stuff sounds rather fragile.


thanks,

Takashi