In preparation to converting several drivers to gpiod API, and to keep
existing DTS working, this series adds additional quirks to locate
gpio lines with legacy names.

Additionally the quirk handling has been reworked (once again) to pull
all simple renames (ones that do not involve change of indices or other
complex manipulations) into a single quirk with a table containing
transformations. This should make adding new quirks easier.
When using legacy names gpiolib will emit a message to nudge users to
update DTSes (when possible).

Note that the last patch requires the following change from the OF tree:

        88269151be67 ("of: base: make of_device_compatible_match() accept const device node")

The change is also available in mainline - it has been merged in 6.1
merge window.

Thanks.

To: Linus Walleij <linus.walleij@linaro.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org

---
Changes in v3:
- added missed legacy compatible for UART variant of Marvell NFC controller
- added naming quirk for MOXA ART RTC
- Link to v2: https://lore.kernel.org/r/20221011-gpiolib-quirks-v2-0-73cb7176fd94@gmail.com

Changes in v2:
- fixed 'fsl,imx8mq-fec' & 'fsl,imx8qm-fec' compatibles issue noticed
  by Alexander Stein
- implemented Daniel Thompson's suggestion on tightening configs
  selecting renaming quirks and added a comment to discourage adding
  rename quirks without checks for specific compatible(s) 
- added a polarity quirk for Himax LCDs
- collected reviewed-by tags
- Link to v1: https://lore.kernel.org/r/20221011-gpiolib-quirks-v1-0-e01d9d3e7b29@gmail.com

---
Dmitry Torokhov (10):
      gpiolib: of: add a quirk for legacy names in Mediatek mt2701-cs42448
      gpiolib: of: consolidate simple renames into a single quirk
      gpiolib: of: tighten selection of gpio renaming quirks
      gpiolib: of: add quirk for locating reset lines with legacy bindings
      gpiolib: of: add a quirk for reset line for Marvell NFC controller
      gpiolib: of: add a quirk for reset line for Cirrus CS42L56 codec
      gpiolib: of: add a quirk for legacy names in MOXA ART RTC
      gpiolib: of: factor out code overriding gpio line polarity
      gpiolib: of: add quirk for phy reset polarity for Freescale Ethernet
      gpiolib: of: add a quirk for reset line polarity for Himax LCDs

 drivers/gpio/gpiolib-of.c | 349 ++++++++++++++++++++++++++++++----------------
 1 file changed, 227 insertions(+), 122 deletions(-)
---
base-commit: dca0a0385a4963145593ba417e1417af88a7c18d
change-id: 20221011-gpiolib-quirks-d452ed31d24e

-- 
Dmitry

On Tue, Oct 18, 2022 at 7:41 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> In preparation to converting several drivers to gpiod API, and to keep
> existing DTS working, this series adds additional quirks to locate
> gpio lines with legacy names.
>
> Additionally the quirk handling has been reworked (once again) to pull
> all simple renames (ones that do not involve change of indices or other
> complex manipulations) into a single quirk with a table containing
> transformations. This should make adding new quirks easier.
> When using legacy names gpiolib will emit a message to nudge users to
> update DTSes (when possible).
>
> Note that the last patch requires the following change from the OF tree:
>
>         88269151be67 ("of: base: make of_device_compatible_match() accept const device node")
>
> The change is also available in mainline - it has been merged in 6.1
> merge window.
>
> Thanks.
>
> To: Linus Walleij <linus.walleij@linaro.org>
> To: Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Alexander Stein <alexander.stein@ew.tq-group.com>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mediatek@lists.infradead.org
>

I applied the entire series.

Bartosz

On Mon, Oct 17, 2022 at 10:41:01PM -0700, Dmitry Torokhov wrote:
> In preparation to converting several drivers to gpiod API, and to keep
> existing DTS working, this series adds additional quirks to locate
> gpio lines with legacy names.
> 
> Additionally the quirk handling has been reworked (once again) to pull
> all simple renames (ones that do not involve change of indices or other
> complex manipulations) into a single quirk with a table containing
> transformations. This should make adding new quirks easier.
> When using legacy names gpiolib will emit a message to nudge users to
> update DTSes (when possible).
> 
> Note that the last patch requires the following change from the OF tree:
> 
>         88269151be67 ("of: base: make of_device_compatible_match() accept const device node")
> 
> The change is also available in mainline - it has been merged in 6.1
> merge window.

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.

-- 
With Best Regards,
Andy Shevchenko

On Tue, Oct 18, 2022 at 2:32 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Mon, Oct 17, 2022 at 10:41:01PM -0700, Dmitry Torokhov wrote:
> > In preparation to converting several drivers to gpiod API, and to keep
> > existing DTS working, this series adds additional quirks to locate
> > gpio lines with legacy names.
> >
> > Additionally the quirk handling has been reworked (once again) to pull
> > all simple renames (ones that do not involve change of indices or other
> > complex manipulations) into a single quirk with a table containing
> > transformations. This should make adding new quirks easier.
> > When using legacy names gpiolib will emit a message to nudge users to
> > update DTSes (when possible).
> >
> > Note that the last patch requires the following change from the OF tree:
> >
> >         88269151be67 ("of: base: make of_device_compatible_match() accept const device node")
> >
> > The change is also available in mainline - it has been merged in 6.1
> > merge window.
>
> 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.

Yours,
Linus Walleij

On Wed, Oct 19, 2022 at 12:56:31PM +0200, Linus Walleij wrote:
> On Tue, Oct 18, 2022 at 2:32 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Oct 17, 2022 at 10:41:01PM -0700, Dmitry Torokhov wrote:
> > > In preparation to converting several drivers to gpiod API, and to keep
> > > existing DTS working, this series adds additional quirks to locate
> > > gpio lines with legacy names.
> > >
> > > Additionally the quirk handling has been reworked (once again) to pull
> > > all simple renames (ones that do not involve change of indices or other
> > > complex manipulations) into a single quirk with a table containing
> > > transformations. This should make adding new quirks easier.
> > > When using legacy names gpiolib will emit a message to nudge users to
> > > update DTSes (when possible).
> > >
> > > Note that the last patch requires the following change from the OF tree:
> > >
> > >         88269151be67 ("of: base: make of_device_compatible_match() accept const device node")
> > >
> > > The change is also available in mainline - it has been merged in 6.1
> > > merge window.
> >
> > 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...

-- 
With Best Regards,
Andy Shevchenko

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