linux-kernel - Re: [PATCH 02/11] gpiolib: introduce devm_fwnode_gpiod_get

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]

Message-ID: <CACRpkdZjZZKQqkN-HC11PJ5SgZbZd1Gnbeh8ApJ7+cS1eOOMbw@mail.gmail.com>
Date:   Thu, 12 Sep 2019 10:48:13 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 02/11] gpiolib: introduce devm_fwnode_gpiod_get_index()

On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:

> devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode
> in question does not have to be a child of device node. Let's rename it
> to devm_fwnode_gpiod_get_index() and keep the old name for compatibility
> for now.
>
> Also let's add a devm_fwnode_gpiod_get() wrapper as majority of the
> callers need a single GPIO.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>

The patch is good because this is in line with Rusty Russells API
manifesto:

7. The obvious use is (probably) the correct one.
6. The name tells you how to use it.

It doesn't apply to my "devel" branch as of now:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel

If you rebase this and the next patch and send them separately I
am willing to apply them already for v5.4 to easy your refactoring
work during the v5.5 cycle here, provided we try to fix up the old users
ASAP and delete the compatibility fallbacks in the near future.

Yours,
Linus Walleij