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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5e7fdb87-651d-6056-9323-7a29573b6300@ti.com>
Date:   Tue, 4 Sep 2018 11:02:14 -0500
From:   "Andrew F. Davis" <afd@...com>
To:     Mark Brown <broonie@...nel.org>
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 09/04/2018 10:56 AM, Mark Brown wrote:
> On Tue, Sep 04, 2018 at 10:10:24AM -0500, Andrew F. Davis wrote:
>> On 09/04/2018 09:55 AM, Mark Brown wrote:
> 
>>> 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.
> 
>> Not sure how that could even look, it would need to be in DT as only
>> that layer knows the connections, but then the it would also have to
>> have internal knowledge of the widgets used in the driver..
> 
> We already have a bunch of DT code that knows about and uses the
> external widgets the device has (which are I'd guess the only ones where
> this is an issue)?  I was thinking just have a property that lists the
> widgets that should never be turned on.
> 
>>> 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.
> 
>> Then only time this could happen is if they specified MICBIAS_OFF in DT
>> but got the default 2v instead. In which case, yes, the behavior would
>> change, but it would also be changing to the correct behavior. We can't
>> avoid fixing code on the off chance someone depended on the broken
>> behavior, no progress could ever be made.
> 
> I'm really having a lot of trouble seeing MICBIAS_OFF as a useful
> voltage to specify in DT in the first place.
> 

I don't see the usefulness in specifying any bias voltage in DT at all,
it is a configuration and can be made at runtime, it has no place in DT.
But it is already here, so lets allow all available voltages a board may
need and the CODEC can supply, even 0.