linux-kernel - Re: [PATCH v3 00/10] gpiolib: more quirks to handle legacy names

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Oct 2022 15:31:58 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexander Stein <alexander.stein@...tq-group.com>,
        linux-arm-kernel@...ts.infradead.org, linux-gpio@...r.kernel.org,
        Daniel Thompson <daniel.thompson@...aro.org>,
        linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v3 00/10] gpiolib: more quirks to handle legacy names

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