include/linux/gpio/consumer.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Andy suggested we should keep a fine-grained scheme for includes and
only pull in stuff required within individual ifdef sections. Let's
revert commit dea69f2d1cc8 ("gpiolib: move all includes to the top of
gpio/consumer.h") and make the headers situation even more fine-grained
by only including the first level headers containing requireded symbols
except for bug.h where checkpatch.pl warns against including asm/bug.h.
Fixes: dea69f2d1cc8 ("gpiolib: move all includes to the top of gpio/consumer.h")
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Closes: https://lore.kernel.org/all/Z7XPcYtaA4COHDYj@smile.fi.intel.com/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Changes in v2:
- don't include asm/errno.h: it's already provided by linux/err.h which
must be included globally for this header due to
gpiod_multi_set_value_cansleep() needing it
include/linux/gpio/consumer.h | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 0b2b56199c36..824a1717e6d2 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -3,10 +3,7 @@
#define __LINUX_GPIO_CONSUMER_H
#include <linux/bits.h>
-#include <linux/bug.h>
#include <linux/err.h>
-#include <linux/errno.h>
-#include <linux/kernel.h>
#include <linux/types.h>
struct acpi_device;
@@ -185,6 +182,9 @@ struct gpio_desc *devm_fwnode_gpiod_get_index(struct device *dev,
#else /* CONFIG_GPIOLIB */
+#include <linux/bug.h>
+#include <linux/kernel.h>
+
static inline int gpiod_count(struct device *dev, const char *con_id)
{
return 0;
@@ -549,6 +549,9 @@ struct gpio_desc *devm_fwnode_gpiod_get_index(struct device *dev,
int gpiod_enable_hw_timestamp_ns(struct gpio_desc *desc, unsigned long flags);
int gpiod_disable_hw_timestamp_ns(struct gpio_desc *desc, unsigned long flags);
#else
+
+#include <linux/bug.h>
+
static inline int gpiod_enable_hw_timestamp_ns(struct gpio_desc *desc,
unsigned long flags)
{
--
2.45.2From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
On Tue, 25 Feb 2025 10:52:10 +0100, Bartosz Golaszewski wrote:
> Andy suggested we should keep a fine-grained scheme for includes and
> only pull in stuff required within individual ifdef sections. Let's
> revert commit dea69f2d1cc8 ("gpiolib: move all includes to the top of
> gpio/consumer.h") and make the headers situation even more fine-grained
> by only including the first level headers containing requireded symbols
> except for bug.h where checkpatch.pl warns against including asm/bug.h.
>
> [...]
Applied, thanks!
[1/1] gpiolib: use the required minimum set of headers
commit: 007094c83872ed33c1d9e39b3ef7168d85a3f214
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
On Tue, Feb 25, 2025 at 10:52:10AM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Andy suggested we should keep a fine-grained scheme for includes and
> only pull in stuff required within individual ifdef sections. Let's
> revert commit dea69f2d1cc8 ("gpiolib: move all includes to the top of
> gpio/consumer.h") and make the headers situation even more fine-grained
> by only including the first level headers containing requireded symbols
> except for bug.h where checkpatch.pl warns against including asm/bug.h.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
FWIW, I have checked the current state of affairs of linux/bug.h vs. asm/bug.h
and found no possible issues with the dependencies. While linux/bug.h drags
more than needed into this header it won't prevent cleaning up the rest of
the headers. So for now we can stick with linux/bug.h, but at some point it
would be better to be more pedantic on this.
--
With Best Regards,
Andy Shevchenko
On Tue, 25 Feb 2025 12:44:21 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Feb 25, 2025 at 10:52:10AM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Andy suggested we should keep a fine-grained scheme for includes and
> > only pull in stuff required within individual ifdef sections. Let's
> > revert commit dea69f2d1cc8 ("gpiolib: move all includes to the top of
> > gpio/consumer.h") and make the headers situation even more fine-grained
> > by only including the first level headers containing requireded symbols
> > except for bug.h where checkpatch.pl warns against including asm/bug.h.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> FWIW, I have checked the current state of affairs of linux/bug.h vs. asm/bug.h
> and found no possible issues with the dependencies. While linux/bug.h drags
> more than needed into this header it won't prevent cleaning up the rest of
> the headers. So for now we can stick with linux/bug.h, but at some point it
> would be better to be more pedantic on this.
>
A 'fun' activity is to pick a random file add "#define _IOW xxx" at the
top and see where ioctl.h is is first included from.
(I've not got a build machine up at the moment.)
Then start fixing that include sequence.
Moving a few headers around is otherwise pretty pointless.
David
Wed, Feb 26, 2025 at 09:46:13PM +0000, David Laight kirjoitti:
> On Tue, 25 Feb 2025 12:44:21 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Tue, Feb 25, 2025 at 10:52:10AM +0100, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > >
> > > Andy suggested we should keep a fine-grained scheme for includes and
> > > only pull in stuff required within individual ifdef sections. Let's
> > > revert commit dea69f2d1cc8 ("gpiolib: move all includes to the top of
> > > gpio/consumer.h") and make the headers situation even more fine-grained
> > > by only including the first level headers containing requireded symbols
> > > except for bug.h where checkpatch.pl warns against including asm/bug.h.
> >
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> >
> > FWIW, I have checked the current state of affairs of linux/bug.h vs. asm/bug.h
> > and found no possible issues with the dependencies. While linux/bug.h drags
> > more than needed into this header it won't prevent cleaning up the rest of
> > the headers. So for now we can stick with linux/bug.h, but at some point it
> > would be better to be more pedantic on this.
> >
>
> A 'fun' activity is to pick a random file add "#define _IOW xxx" at the
> top and see where ioctl.h is is first included from.
> (I've not got a build machine up at the moment.)
>
> Then start fixing that include sequence.
> Moving a few headers around is otherwise pretty pointless.
Have you tried to help with reviewing this?
https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/
--
With Best Regards,
Andy Shevchenko
On Thu, 27 Feb 2025 11:22:41 +0200 Andy Shevchenko <andy.shevchenko@gmail.com> wrote: ... > > A 'fun' activity is to pick a random file add "#define _IOW xxx" at the > > top and see where ioctl.h is is first included from. > > (I've not got a build machine up at the moment.) > > > > Then start fixing that include sequence. > > Moving a few headers around is otherwise pretty pointless. > > Have you tried to help with reviewing this? > > https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/ > Not seriously, though maybe I remember it. 'dayjobs' makefile first deletes all the SUFFIX and builtin rules. Then it copies lots of headers from all over everywhere into a (fairly flat) obj/include tree to reduce the number of -Ipath to a minimum. A 'create' dependency is added to all the main targets to ensure the headers get copied (the .d files pick up updates). It then generates explicit rules for each .o against its .c file. Definitely speeds things up because make is no longer searching directories for all sorts of files that might be needed - but never are. (I've not dug through the bowels of the kernel makefile, but probably have the skills to do so!) But that is all different from solving the 'all the header files always get included' issue. David
On Fri, Feb 28, 2025 at 05:50:19PM +0000, David Laight wrote: > On Thu, 27 Feb 2025 11:22:41 +0200 > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: ... > > > A 'fun' activity is to pick a random file add "#define _IOW xxx" at the > > > top and see where ioctl.h is is first included from. > > > (I've not got a build machine up at the moment.) > > > > > > Then start fixing that include sequence. > > > Moving a few headers around is otherwise pretty pointless. > > > > Have you tried to help with reviewing this? > > > > https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/ > > > > Not seriously, though maybe I remember it. > > 'dayjobs' makefile first deletes all the SUFFIX and builtin rules. > Then it copies lots of headers from all over everywhere into a (fairly > flat) obj/include tree to reduce the number of -Ipath to a minimum. > A 'create' dependency is added to all the main targets to ensure the > headers get copied (the .d files pick up updates). > > It then generates explicit rules for each .o against its .c file. > > Definitely speeds things up because make is no longer searching > directories for all sorts of files that might be needed - but never are. > > (I've not dug through the bowels of the kernel makefile, but probably > have the skills to do so!) > > But that is all different from solving the 'all the header files always > get included' issue. How? That gigantic series makes the headers cleaner in a sense to avoid "include everything" thingy. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.