linux-kernel - RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

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]

Date:	Tue, 10 Nov 2015 14:24:13 +0000
From:	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
To:	Mark Brown <broonie@...nel.org>,
	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
CC:	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Support Opensource" <Support.Opensource@...semi.com>
Subject: RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

On November 10, 2015 14:15, Mark Brown wrote:

> > > The general userspace expectation is that the detection is always active
> > > and consistent rather than varying at runtime - runtime variability
> > > might be a bit surprising for it, and even then variability in what is
> > > detected based on other settings is a bit surprising.  If the hardware
> > > is that limited I guess it's about all that can be done but I'm still
> > > not clear what the use cases are for configuring the levels (as opposed
> > > ot the routing).
> 
> > How about the example of always on voice in Android, which can be enabled and
> > disabled, depending on user settings, and routing will vary depending on which
> > mic is in use at the time? For the levelling is it not plausible that a user
> > could configure the level based on their current environment. You have
> > moderately loud background noise, then your threshold would want to be
> > higher, but in a quiet environment the likelihood is you would want to lower
> > that threshold?
> 
> So this *isn't* a normal mic detection feature?  What's the userspace
> interface for reporting then?

By mic detection you thought this was to detect if a mic was present or not?
It's to detect the noise level on a mic and raise an event if the captured
sound is above a specific threshold level. Apologies if that wasn't clear.

In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and
release of this key, to indicate to user-space. This seemed like the obvious
choice for this feature to me, although I'd happily get your opinion on this.