linux-kernel - RE: [PATCH] ASoC: da7218: Enable mic level detection reporting to user-space

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: <2E89032DDAA8B9408CB92943514A0337D460FAE1@SW-EX-MBX01.diasemi.com>
Date:	Thu, 3 Dec 2015 14:45:11 +0000
From:	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
To:	Takashi Iwai <tiwai@...e.de>,
	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
CC:	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Jaroslav Kysela <perex@...ex.cz>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	Support Opensource <Support.Opensource@...semi.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ASoC: da7218: Enable mic level detection reporting to
 user-space

On December 03, 2015 11:37, Takashi Iwai wrote:

> > > > This patch adds support to the codec driver to handle mic level
> > > > detect related IRQs, and report these to user-space using a uevent
> > > > variable.
> > >
> > > Is the uevent the best way for this?
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> >
> > Well originally I was using an input device mechanism to report to user-space,
> > albeit using KEY_VOICECOMMAND, which Mark mentioned wasn't correct for this
> > scenario, which was fair enough. He also mentioned that there had been a general
> > push back on using input devices so that code was dropped. See thread below:
> >
> > https://lkml.org/lkml/2015/11/10/347
> >
> > uevent seemed like the simplest solution to report this event, and allow
> > user-space to act based on it. As mentioned before though, I am open to
> > suggestions if there's a better way.
> 
> I'm not strongly opposing to uevent as long as it's well considered.
> But then please describe how it's notified properly and why it was
> chosen.  The patch changelog has enough free room to write more
> details, fortunately.  Tell more your story for Christmas :)
> 
> In general, you can use an ALSA control notification for this kind of
> event.  But it also depends on the user-space side.  With alsa-lib,
> it's pretty easy to use, while with tinyalsa that lacks of the notifier
> handling, you'd need to implement more code there.
> 
> For a plug/unplug type event, we have a generic jack layer, but this
> doesn't seem fitting perfectly, either.

For ALSA control notification, this implies there's a control associated, but
for this scenario that's really not necessary. You just want to know when the
noise level captured at the mic has gone above a certain threshold and then act
accordingly (process audio capture stream). There's no real need I can see for
a control to read from. As for the jack layer, I agree that it doesn't really
fit.

Ok, will update the patch commit message to add more details on this, including
references to Santa Claus, reindeer with shining noses, and other festive
symbols. :)