From: Mark Brown <broonie@kernel.org> To: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 01/11] ASoC: ak5386: switch to using gpiod API Date: Thu, 17 Nov 2022 11:34:06 +0000 [thread overview] Message-ID: <Y3YcLulaebidYYsg@sirena.org.uk> (raw) In-Reply-To: <Y3U1BJAPOJTLw/Zb@google.com> [-- Attachment #1: Type: text/plain, Size: 1607 bytes --] 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. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
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: Thu, 17 Nov 2022 11:34:06 +0000 [thread overview] Message-ID: <Y3YcLulaebidYYsg@sirena.org.uk> (raw) In-Reply-To: <Y3U1BJAPOJTLw/Zb@google.com> [-- Attachment #1: Type: text/plain, Size: 1607 bytes --] 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. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-11-17 11:35 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-16 5:38 [PATCH 01/11] ASoC: ak5386: switch to using gpiod API Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 02/11] ASoC: max98373: " Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 03/11] ASoC: tas5086: " Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 04/11] ASoC: tpa6130a2: remove support for platform data Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 05/11] ASoC: tpa6130a2: switch to using gpiod API Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 06/11] ASoC: tlv320aic32x4: remove support for platform data Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 07/11] ASoC: tlv320aic32x4: switch to using gpiod API Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 08/11] ASoC: dt-bindings: wcd9335: fix reset line polarity in example Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 09/11] ASoC: wcd9335: switch to using gpiod API Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 10/11] ASoC: dt-bindings: wcd938x: fix codec reset line polarity in example Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2022-11-16 5:38 ` [PATCH 11/11] ASoC: wcd938x: switch to using gpiod API Dmitry Torokhov 2022-11-16 5:38 ` Dmitry Torokhov 2023-03-08 18:11 ` Krzysztof Kozlowski 2022-11-16 10:36 ` [PATCH 01/11] ASoC: ak5386: " Mark Brown 2022-11-16 10:36 ` Mark Brown 2022-11-16 19:07 ` Dmitry Torokhov 2022-11-16 19:07 ` Dmitry Torokhov 2022-11-17 11:34 ` Mark Brown [this message] 2022-11-17 11:34 ` Mark Brown 2022-11-18 6:31 ` Dmitry Torokhov 2022-11-18 6:31 ` Dmitry Torokhov 2022-11-18 13:12 ` Mark Brown 2022-11-18 13:12 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y3YcLulaebidYYsg@sirena.org.uk \ --to=broonie@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=dmitry.torokhov@gmail.com \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.