linux-kernel - Re: [alsa-devel] [PATCH v2 3/3] ASoC: TDA7802: Add turn-on diagnostic routine

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:   Fri, 2 Aug 2019 00:42:41 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Thomas Preston <thomas.preston@...ethink.co.uk>
Cc:     Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
        alsa-devel@...a-project.org,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Kirill Marinushkin <kmarinushkin@...dec.tech>,
        Liam Girdwood <lgirdwood@...il.com>,
        Marco Felsch <m.felsch@...gutronix.de>,
        Annaliese McDermond <nh6z@...z.net>,
        Takashi Iwai <tiwai@...e.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Vinod Koul <vkoul@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Jerome Brunet <jbrunet@...libre.com>,
        linux-kernel@...r.kernel.org,
        Cheng-Yi Chiang <cychiang@...omium.org>
Subject: Re: [alsa-devel] [PATCH v2 3/3] ASoC: TDA7802: Add turn-on
 diagnostic routine

On Tue, Jul 30, 2019 at 05:28:11PM +0100, Thomas Preston wrote:
> On 30/07/2019 16:50, Mark Brown wrote:

> > Like I say it's not just debugfs though, there's the standard driver
> > interface too.

> Ah right, I understand. So if we run the turn-on diagnostics routine, there's
> nothing stopping anyone from interacting with the device in other ways.

> I guess there's no way to share that mutex with ALSA? In that case, it doesn't
> matter if this mutex is there or not - this feature is incompatible. How
> compatible do debugfs interfaces have to be? I was under the impression anything
> goes. I would argue that the debugfs is better off for having the mutex so
> that no one re-reads "diagnostic" within the 5s poll timeout.

It's not really something that's supported; like Charles says the DAPM
mutex is exposed but if the regular controls would still be able to do
stuff.  It is kind of a "you broke it, you fix it" thing but on the
other hand it's better to make things safer if we can since it might not
be obvious later on why things are broken.

> Alternatively, this diagnostic feature could be handled with an external-handler
> kcontrol SOC_SINGLE_EXT? I'm not sure if this is an atomic interface either.
> 
> What would be acceptable?

Yes, that's definitely doable - we've got some other drivers with
similar things like calibration triggers exposed that way.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)