[PATCH 01/11] ASoC: ak5386: switch to using gpiod API

[Mark Brown]

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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20221117/9834ca98/attachment.sig>