linux-kernel - Re: [PATCH 01/11] ASoC: ak5386: switch to using gpiod API

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:   Wed, 16 Nov 2022 11:07:48 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
        alsa-devel@...a-project.org
Subject: Re: [PATCH 01/11] ASoC: ak5386: switch to using gpiod API

On Wed, Nov 16, 2022 at 10:36:27AM +0000, Mark Brown wrote:
> On Tue, Nov 15, 2022 at 09:38:07PM -0800, Dmitry Torokhov wrote:
> 
> > Switch the driver from legacy gpio API that is deprecated to the newer
> > gpiod API that respects line polarities described in ACPI/DT.
> 
> > -	if (gpio_is_valid(priv->reset_gpio))
> > -		gpio_set_value(priv->reset_gpio, 1);
> > +	if (priv->reset_gpio)
> > +		gpiod_set_value(priv->reset_gpio, 0);
> 
> How are we ensuring that people have described signals as active
> low/high in existing DTs, and are we positive that the signal is
> described as active low for all devices?  In particular if the
> signal is described as a reset signal then it's active high even
> if we want it low while the device is actually in use.

I have been going through in-kernel DTSes and adjusting ones that are
incorrect. For external ones I think we should take a pragmatic approach
and say that if driver has last non-mechanical update in 2014 and there
are no users submitted to mainline since then (as this one), then it is
highly unlikely that devices currently using this component/codec will
be updated to the 6.2+ kernel even if they are still in service. And if
this does happen the breakage will be immediately obvious as we'll keep
the codec in reset state.

But if you really want to I can add quirk(s) to gpiolib forcing this
line to be treated as active-low regardless of what specified in DTS.
This kind of negates benefit of going to gpiod though.

Please let me know.

-- 
Dmitry