From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
Kent Gibson <warthog618@gmail.com>,
linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
brcm80211@lists.linux.dev, brcm80211-dev-list.pdl@broadcom.com,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Arend van Spriel <arend.vanspriel@broadcom.com>,
Kalle Valo <kvalo@kernel.org>,
Charles Keepax <ckeepax@opensource.cirrus.com>
Subject: Re: [PATCH v2 1/2] gpiolib: Fix a mess with the GPIO_* flags
Date: Fri, 12 Apr 2024 18:25:28 +0300 [thread overview]
Message-ID: <ZhlSaFWlbE6OS7om@smile.fi.intel.com> (raw)
In-Reply-To: <CACRpkdYaXVvtt3b9rFxU4ZNShD17Bm4XU9X3h4dY501iJy3kPA@mail.gmail.com>
On Fri, Apr 12, 2024 at 10:20:24AM +0200, Linus Walleij wrote:
> On Tue, Apr 9, 2024 at 1:17 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>
> > The GPIO_* flag definitions are *almost* duplicated in two files
> > (with unmatches OPEN_SOURCE / OPEN_DRAIN). Moreover, some code relies
> > on one set of definitions while the rest is on the other. Clean up
> > this mess by providing only one source of the definitions to all.
> >
> > Fixes: b424808115cb ("brcm80211: brcmsmac: Move LEDs to GPIO descriptors")
> > Fixes: 5923ea6c2ce6 ("gpio: pass lookup and descriptor flags to request_own")
> > Fixes: fed7026adc7c ("gpiolib: Make use of enum gpio_lookup_flags consistent")
> > Fixes: 4c0facddb7d8 ("gpio: core: Decouple open drain/source flag with active low/high")
> > Fixes: 69d301fdd196 ("gpio: add DT bindings for existing consumer flags")
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> The way the line lookup flags ("lflags") were conceived was through
> support for non-DT systems using descriptor tables, and that is how
> enum gpio_lookup_flags came to be.
>
> When OF support was added it was bolted on on the side, in essence
> assuming that the DT/OF ABI was completely separate (and they/we
> sure like to think about it that way...) and thus needed translation from
> OF flags to kernel-internal enum gpio_lookup_flags.
>
> The way *I* thought about this when writing it was certainly that the
> DT bindings was a separate thing (<dt-bindings/*.h> didn't even exist
> at the time I think) and that translation from OF to kernel-internal
> lflags would happen in *one* place.
>
> The main reasoning still holds: the OF define is an ABI, so it can
> *never* be changed, but the enum gpio_lookup_flags is subject to
> Documentation/process/stable-api-nonsense.rst and that means
> that if we want to swap around the order of the definitions we can.
>
> But admittedly this is a bit over-belief in process and separation of
> concerns and practical matters may be something else...
Got it. But we have a name clash and the mess added to the users.
I can redo this to separate these entities.
Note, that there is code in the kernel that *does* use
#include <dt-bindings/*.h>
for Linux internals.
$ git grep -lw '^#include <dt-bindings/.*\.h>' -- drivers/ | xargs dirname | cut -f 1,2 -d '/' | sort -u
drivers/bus
drivers/clk
drivers/clocksource
drivers/cpufreq
drivers/dma
drivers/firmware
drivers/gpio
drivers/gpu
drivers/hwtracing
drivers/i2c
drivers/iio
drivers/input
drivers/interconnect
drivers/iommu
drivers/irqchip
drivers/leds
drivers/mailbox
drivers/media
drivers/memory
drivers/mfd
drivers/net
drivers/phy
drivers/pinctrl
drivers/platform
drivers/pmdomain
drivers/power
drivers/pwm
drivers/regulator
drivers/remoteproc
drivers/reset
drivers/rtc
drivers/soc
drivers/spmi
drivers/thermal
drivers/tty
drivers/video
drivers/watchdog
P.S>
One of the patch this tries to fix is yours IIRC :-)
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-04-12 15:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 23:12 [PATCH v2 0/2] gpiolib: Fix gpio_lookup_flags mess and add Return sections Andy Shevchenko
2024-04-08 23:12 ` [PATCH v2 1/2] gpiolib: Fix a mess with the GPIO_* flags Andy Shevchenko
2024-04-09 4:38 ` kernel test robot
2024-04-09 8:12 ` kernel test robot
2024-04-09 9:42 ` Bartosz Golaszewski
2024-04-09 12:51 ` Andy Shevchenko
2024-04-09 12:55 ` Bartosz Golaszewski
2024-04-09 13:30 ` Andy Shevchenko
2024-04-12 8:20 ` Linus Walleij
2024-04-12 15:25 ` Andy Shevchenko [this message]
2024-04-12 19:43 ` Bartosz Golaszewski
2024-04-16 12:22 ` Linus Walleij
2024-04-16 14:05 ` Andy Shevchenko
2024-04-16 21:07 ` Bartosz Golaszewski
2024-04-17 8:45 ` Andy Shevchenko
2024-04-17 18:39 ` Bartosz Golaszewski
2024-04-18 11:52 ` Andy Shevchenko
2024-04-19 13:29 ` Linus Walleij
2024-04-19 13:38 ` Andy Shevchenko
2024-04-08 23:12 ` [PATCH v2 2/2] gpiolib: Update the kernel documentation - add Return sections Andy Shevchenko
2024-04-09 12:51 ` Andy Shevchenko
2024-04-09 14:01 ` Bartosz Golaszewski
2024-04-09 14:06 ` Andy Shevchenko
2024-04-09 14:18 ` Bartosz Golaszewski
2024-04-09 14:29 ` Andy Shevchenko
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=ZhlSaFWlbE6OS7om@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=arend.vanspriel@broadcom.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211@lists.linux.dev \
--cc=brgl@bgdev.pl \
--cc=ckeepax@opensource.cirrus.com \
--cc=kvalo@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=warthog618@gmail.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.