linux-kernel - Re: [PATCH] ASoC: tlv320aic31xx: Add MICBIAS off setting

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 4 Sep 2018 15:55:03 +0100
From:   Mark Brown <broonie@...nel.org>
To:     "Andrew F. Davis" <afd@...com>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        alsa-devel@...a-project.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: tlv320aic31xx: Add MICBIAS off setting

On Tue, Sep 04, 2018 at 09:43:03AM -0500, Andrew F. Davis wrote:
> On 09/04/2018 09:41 AM, Mark Brown wrote:

> >>> If we really want to pay attention to something setting this up we'd
> >>> need to completely remove the widget - what the code is doing at the
> >>> minute is setting the voltage that the bias will go to when enabled,
> >>> there's still a widget for turning it on and off.  There's some chance
> >>> that this will break existing boards.

> >> Turning on bias is controlled separately, automatically in user-space in
> >> many cases, not based on the board. The DT needs to have a way to state
> >> that 0v is the needed bias on this board, without this you can not set
> >> 0v bias and 2v is chosen by default (which is IMHO should be 0v but that
> >> would change existing behavior so I won't touch that).

> > Surely turning on MICBIAS at 0V is equivalent to leaving the bias off?

> It is, but DT doesn't control when or why MICBIAS is turned on or off,
> only what voltage on should be.

The DT controls this in so far as it will arrange for the bias to be
connected to something, if it's not connected to anything then it will
only be turned on if the machine driver explicitly forces it on which is
a potential source of problems but seems comfortably in "you broke it,
you get to keep the pieces" territory.  If we really want to have a way
of explicitly specifying that some widgets should never be turned on
then it feels like rather than have something device and widget specific
like this we should instead have a higher level way of doing that which
can be applied to any widget, that is something that could be useful
especially with things like speaker drivers where there's real potential
for physical damage to the system.

Like I said in my original reply I'm also worried that this will break
existing boards by causing them to change to a voltage of 0 when they
had managed to end up with the default of 2V which happened to work for
them.

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