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

From: Mark Brown <broonie@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH 01/11] ASoC: ak5386: switch to using gpiod API
Date: Fri, 18 Nov 2022 13:12:41 +0000	[thread overview]
Message-ID: <Y3eEyf9fv0A5obNR@sirena.org.uk> (raw)
In-Reply-To: <Y3cm1eeDN+n3tbpG@google.com>

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

On Thu, Nov 17, 2022 at 10:31:49PM -0800, Dmitry Torokhov wrote:
> On Thu, Nov 17, 2022 at 11:34:06AM +0000, Mark Brown wrote:

> > 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).

My comments were more generic ones about the whole series since
all the patches seemed to be doing the same thing with flipping
the polarity - some of the GPIOs were labelled as things like
reset which is active high if it's not nRESET or something even
though we want to pull it low while using the device.

> > 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.

There are practical systems which ship DTs as part of the
firmware, and frankly things like this do contribute to the
issue.  The systems that just ship their DTs are obviously a lot
less visible, but that's the whole goal here.  It's most common
with more server type systems using EDK2 for the firmware, ACPI
isn't always a good fit for them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]