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]

Message-ID: <Y3cm1eeDN+n3tbpG@google.com>
Date:   Thu, 17 Nov 2022 22:31:49 -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 Thu, Nov 17, 2022 at 11:34:06AM +0000, Mark Brown wrote:
> On Wed, Nov 16, 2022 at 11:07:48AM -0800, Dmitry Torokhov wrote:
> > On Wed, Nov 16, 2022 at 10:36:27AM +0000, Mark Brown wrote:
> 
> > > 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.
> 
> That doesn't address the bit about checking that the device
> describes the signal as active low in hardware - it's assuming
> that the signal is described by the device as an active low
> reset and not for example as a shutdown signal.

Huh? If we add a quirk to gpiolib to treat the signal as active low
(i.e. preserve current driver behavior - I am talking about this
particular peripheral here, not treating everything as active low of
course).

> 
> TBH I'm not thrilled about just randomly breaking ABI
> compatibility for neatness reasons, it's really not helping
> people take device tree ABI compatibility seriously.

Yes, I freely admit I do not take device tree ABI compatibility
seriously. IMO, with the exception of a few peripherals, it is a
solution in search of a problem, and we declared stability of it too
early, before we came up with reasonable rules for how resources should
be described. I strongly believe that in vast majority of cases devices
with out-of-tree DTs will not be updated to upstream kernels as this
requires significant engineering effort and vendors usually not
interested in doing that.

Thanks.

-- 
Dmitry