From: Joshua Crofts <crofts@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bartosz Golaszewski <brgl@kernel.org>,
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>,
Joshua Crofts <joshua.crofts1@gmail.com>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Linus Walleij <linusw@kernel.org>,
Kent Gibson <warthog618@gmail.com>,
Adrian Ambrozewicz <aambrozewicz@nvidia.com>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2 4/5] gpiolib: don't overwrite the entire flags field in gpiod_free_commit()
Date: Tue, 10 Nov 2026 12:05:28 +0100 [thread overview]
Message-ID: <20261110120522.000057f9@kernel.org> (raw)
In-Reply-To: <avLsrOqdXSFSH6WM@ashevche-desk.local>
On Tue, 10 Nov 2026 12:06:36 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Nov 10, 2026 at 09:54:11AM +0100, Bartosz Golaszewski wrote:
> > On Mon, Nov 09, 2026 at 11:53:03PM +0200, Andy Shevchenko wrote:
> > > On Mon, Nov 09, 2026 at 11:27:08AM +0100, Bartosz Golaszewski wrote:
>
> ...
>
> > > > #include <linux/acpi.h>
> > > > #include <linux/array_size.h>
> > > > #include <linux/bitmap.h>
> > > > +#include <linux/bitops.h>
> > > > #include <linux/cleanup.h>
> > > > #include <linux/compat.h>
> > > > #include <linux/debugfs.h>
> > >
> > > No need, bitmap API implies all bitops.
> >
> > I honestly have no idea what the policy is on "proxy" headers. In some
> > cases people advise against them, in others they say to include them.
The main proxy header one should beware when adding new drivers or tweaking
is kernel.h, better to just use the iwyu principle.
There are a few loose exceptions (i.e. not fully iwyu but good enough), e.g.
- bitops.h implies bits.h
- bitmap.h implies bitops.h
- acpi.h, i2c.h, spi.h etc. imply the corresponding linux/device_id/* header
- if you have an opaque pointer (like struct device * but don't use any
functions from device.h) you can just skip the header entirely.
This can be also "automated" using iwyu-tool (which requires LLVM). I have
a mapping file tailored for IIO but surely you can swap the iio headers for
gpio ones.
https://lore.kernel.org/all/20260512073505.1310-1-joshua.crofts1@gmail.com/
> > Is this documented anywhere?
>
> No, but feel free to start such a documentation. In IIO we did a huge work
> to enforce IWYU principle, and there we have some tribe knowledge about
> the dependencies and guarantees. (Cc'ed some people.) In this case the
> bitops.h inclusion is guaranteed by bitmap.h. If it stops doing like this
> it will be a flag day.
Would be great if someone documented this in detail, at least people who read
the docs and LLMs would learn it :P
Javier Carrasco Cruz wrote a blog post on iwyu-tool where he links to my
mapping file:
https://hackerbikepacker.com/iwyu
--
Kind regards,
Joshua Crofts
next prev parent reply other threads:[~2026-11-10 11:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 10:27 [PATCH v2 0/5] gpiolib: improve concurrent access to the flags field of struct gpio_desc Bartosz Golaszewski
2026-11-09 10:27 ` [PATCH v2 1/5] gpiolib: don't overwrite the entire flags field in gpiod_get_direction() Bartosz Golaszewski
2026-11-09 10:27 ` [PATCH v2 2/5] gpio: shared: use atomic set_bit() for descriptor flags Bartosz Golaszewski
2026-11-09 10:27 ` [PATCH v2 3/5] gpiolib: clear debounce period before the "requested" flag Bartosz Golaszewski
2026-11-09 10:27 ` [PATCH v2 4/5] gpiolib: don't overwrite the entire flags field in gpiod_free_commit() Bartosz Golaszewski
2026-11-09 21:53 ` Andy Shevchenko
2026-11-10 8:54 ` Bartosz Golaszewski
2026-11-10 10:06 ` Andy Shevchenko
2026-11-10 11:05 ` Joshua Crofts [this message]
2026-11-09 10:27 ` [PATCH v2 5/5] gpio: cdev: don't overwrite the whole flags field when configuring lines Bartosz Golaszewski
2026-11-09 21:58 ` 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=20261110120522.000057f9@kernel.org \
--to=crofts@kernel.org \
--cc=aambrozewicz@nvidia.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=jonathan.cameron@oss.qualcomm.com \
--cc=joshua.crofts1@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®