linux-kernel - Re: [PATCH 2/2] PCI: mvebu: switch to using gpiod API

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACRpkdYB6dZf4TBhfXB2Z5E2PJ46ctAM_QKLiW-fykbCopcVGQ@mail.gmail.com>
Date:   Thu, 15 Sep 2022 10:51:02 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Kent Gibson <warthog618@...il.com>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Pali Rohár <pali@...nel.org>,
        Shawn Guo <shawn.guo@...aro.org>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] PCI: mvebu: switch to using gpiod API

On Thu, Sep 15, 2022 at 4:23 AM Kent Gibson <warthog618@...il.com> wrote:

> After sleeping on this, I'm even more in disagreement with renaming
> value to state.

OK let's not do that then.

> OTOH, I totally agree with the addition of GPIOD_ACTIVE/INACTIVE to be
> used for the logical cases, and even a script to apply it globally.
> Ideally that script would change both the calls to the logical functions
> to use ACTIVE/INACTIVE, and the physical to HIGH/LOW.

OK we have consensus on this.

> Introducing enums for those, and changing the function signatures to
> use those rather than int makes sense to me too.

Either they can be enum or defined to bool true/false. Not really
sure what is best. But intuitively enum "feels better" for me.

> Though I'm not sure
> why that has to wait until after all users are changed to the new macros.
> Would that generate lint warnings?

I rather want it all to happen at once. One preparatory commit
adding the new types and one sed script to refactor the whole
lot. Not gradual switchover.

The reason is purely administrative: we have too many refactorings
lagging behind, mainly the GPIO descriptors that have been
lagging behind for what is it? 5 years? 10? GPIO irqchips also dragged
out for way too long. We can't keep doing things gradually like
this, it takes too much time and effort.

I don't want any more "in-transition-indefinitely" stuff in the GPIO
subsystem if I can avoid it.

Therefore I would advice to switch it all over at the end of a merge
window and be done with it.

Yours,
Linus Walleij