From: Linus Walleij <linus.walleij@linaro.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Alexander Stein <alexander.stein@ew.tq-group.com>,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
Daniel Thompson <daniel.thompson@linaro.org>,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v3 00/10] gpiolib: more quirks to handle legacy names
Date: Thu, 20 Oct 2022 10:00:01 +0200 [thread overview]
Message-ID: <CACRpkda_BbpNa+OLz=9vYuMbBNyWi4RBfoDS8F_gtc+vP_Fgyg@mail.gmail.com> (raw)
In-Reply-To: <Y0/cot711ad/hG/o@smile.fi.intel.com>
On Wed, Oct 19, 2022 at 1:16 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Wed, Oct 19, 2022 at 12:56:31PM +0200, Linus Walleij wrote:
> > On Tue, Oct 18, 2022 at 2:32 PM Andy Shevchenko
> > > I was wondering if we can use the approach that ACPI chose for itself,
> > > i.e. the separate data that can be filled by the corresponding driver
> > > and then GPIO OF common code may use it. In that case each driver knows
> > > the exact list of compatible strings and associated quirks.
> >
> > I actually deliverately chose the other way around, to centralize all quirks,
> > so that drivers look nice and simple and the ugly historical errors of the
> > device tree be hidden away in gpiolib-of.c.
>
> This makes sense if and only if we may guarantee no quirks will appear in the
> future. So, it may be true for DT, but I'm quite skeptical about ACPI...
Right, the idea is to stop more idiomatic DT bindings from coming into existance
by review and formal verification of the reviewed bindings by using
YAML schemas.
ACPI is somewhat lacking public review of "bindings" and DSDT tables, and I
don't know if there is some counterpart to the schema validation, so that
makes for more new bugs. But maybe ACPI has some tricks up its sleeve that I
don't know about. To me it seems like bugs in ACPI are discovered by developers
after the devices are already produced :/
There are bindings and device trees which lack public review too, most notably
Apple Mac, so especially for them we are redefining new bindings and
who knows, maybe Apple will pick them up eventually!
Yours,
Linus Walleij
next prev parent reply other threads:[~2022-10-20 8:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 5:41 [PATCH v3 00/10] gpiolib: more quirks to handle legacy names Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 01/10] gpiolib: of: add a quirk for legacy names in Mediatek mt2701-cs42448 Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 02/10] gpiolib: of: consolidate simple renames into a single quirk Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 03/10] gpiolib: of: tighten selection of gpio renaming quirks Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 04/10] gpiolib: of: add quirk for locating reset lines with legacy bindings Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 05/10] gpiolib: of: add a quirk for reset line for Marvell NFC controller Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 06/10] gpiolib: of: add a quirk for reset line for Cirrus CS42L56 codec Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 07/10] gpiolib: of: add a quirk for legacy names in MOXA ART RTC Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 08/10] gpiolib: of: factor out code overriding gpio line polarity Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 09/10] gpiolib: of: add quirk for phy reset polarity for Freescale Ethernet Dmitry Torokhov
2022-10-18 5:41 ` [PATCH v3 10/10] gpiolib: of: add a quirk for reset line polarity for Himax LCDs Dmitry Torokhov
2022-10-18 12:31 ` [PATCH v3 00/10] gpiolib: more quirks to handle legacy names Andy Shevchenko
2022-10-19 10:56 ` Linus Walleij
2022-10-19 11:16 ` Andy Shevchenko
2022-10-20 8:00 ` Linus Walleij [this message]
2022-10-20 11:58 ` Bartosz Golaszewski
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='CACRpkda_BbpNa+OLz=9vYuMbBNyWi4RBfoDS8F_gtc+vP_Fgyg@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=alexander.stein@ew.tq-group.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=daniel.thompson@linaro.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).