From: Kent Gibson <warthog618@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Bartosz Golaszewski" <brgl@bgdev.pl>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Pali Rohár" <pali@kernel.org>,
"Shawn Guo" <shawn.guo@linaro.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] PCI: mvebu: switch to using gpiod API
Date: Thu, 15 Sep 2022 17:30:24 +0800 [thread overview]
Message-ID: <YyLwsOBXv9jRw/+n@sol> (raw)
In-Reply-To: <CACRpkdYB6dZf4TBhfXB2Z5E2PJ46ctAM_QKLiW-fykbCopcVGQ@mail.gmail.com>
On Thu, Sep 15, 2022 at 10:51:02AM +0200, Linus Walleij wrote:
> On Thu, Sep 15, 2022 at 4:23 AM Kent Gibson <warthog618@gmail.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.
>
Enums work for me - especially if the goal is to differentiate
logical from physical - there should be a distinct enum for each.
> > 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.
>
Agreed - do it all at once. My question was specific to the change of the
function signatures to using enums - what is to prevent us doing that
before running the sed script, and have the script switch usage over to
the enums?
Cheers,
Kent.
next prev parent reply other threads:[~2022-09-15 9:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 20:43 [PATCH 1/2] PCI: histb: switch to using gpiod API Dmitry Torokhov
2022-09-06 20:43 ` [PATCH 2/2] PCI: mvebu: " Dmitry Torokhov
2022-09-06 21:16 ` Pali Rohár
2022-09-06 21:26 ` Dmitry Torokhov
2022-09-06 21:40 ` Dmitry Torokhov
2022-09-06 21:42 ` Pali Rohár
2022-09-06 21:41 ` Pali Rohár
2022-09-06 21:52 ` Dmitry Torokhov
2022-09-06 22:09 ` Pali Rohár
2022-09-06 22:41 ` Dmitry Torokhov
2022-09-11 12:58 ` Pali Rohár
2022-09-14 10:35 ` Linus Walleij
2022-09-14 12:10 ` Bartosz Golaszewski
2022-09-14 12:48 ` Linus Walleij
2022-09-14 13:00 ` Kent Gibson
2022-09-14 13:36 ` Linus Walleij
2022-09-15 2:23 ` Kent Gibson
2022-09-15 8:51 ` Linus Walleij
2022-09-15 9:30 ` Kent Gibson [this message]
2022-09-16 7:22 ` Bartosz Golaszewski
2022-09-18 14:37 ` Linus Walleij
2022-09-18 23:58 ` Kent Gibson
2022-09-08 8:42 ` Linus Walleij
2022-09-07 4:11 ` kernel test robot
2022-09-09 20:10 ` kernel test robot
2022-09-06 21:08 ` [PATCH 1/2] PCI: histb: " Pali Rohár
2022-09-06 21:41 ` Dmitry Torokhov
2022-09-06 21:46 ` Pali Rohár
2022-09-08 8:37 ` Linus Walleij
2022-11-11 15:01 ` Lorenzo Pieralisi
2022-11-11 15:20 ` Dmitry Torokhov
2022-11-14 10:58 ` (subset) " Lorenzo Pieralisi
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=YyLwsOBXv9jRw/+n@sol \
--to=warthog618@gmail.com \
--cc=bhelgaas@google.com \
--cc=brgl@bgdev.pl \
--cc=dmitry.torokhov@gmail.com \
--cc=kw@linux.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=pali@kernel.org \
--cc=robh@kernel.org \
--cc=shawn.guo@linaro.org \
--cc=thomas.petazzoni@bootlin.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.