The wordpart.h header is collecting APIs related to the handling
parts of the word (usually in byte granularity). The upper_*_bits()
and lower_*_bits() are good candidates to be moved to there.
This helps to clean up header dependency hell with regard to kernel.h
as the latter gathers completely unrelated stuff together and slows
down compilation (especially when it's included into other header).
Signed-off-by: Andy Shevchenko <[email protected]>
---
Kees, since wordpart.h is now only in your tree, this is supposed
to go there as well.
include/linux/kernel.h | 30 ++----------------------------
include/linux/wordpart.h | 29 +++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5f74733391ed..d718fbec72dd 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -33,6 +33,8 @@
#include <linux/sprintf.h>
#include <linux/static_call_types.h>
#include <linux/instruction_pointer.h>
+#include <linux/wordpart.h>
+
#include <asm/byteorder.h>
#include <uapi/linux/kernel.h>
@@ -52,34 +54,6 @@
} \
)
-/**
- * upper_32_bits - return bits 32-63 of a number
- * @n: the number we're accessing
- *
- * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress
- * the "right shift count >= width of type" warning when that quantity is
- * 32-bits.
- */
-#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
-
-/**
- * lower_32_bits - return bits 0-31 of a number
- * @n: the number we're accessing
- */
-#define lower_32_bits(n) ((u32)((n) & 0xffffffff))
-
-/**
- * upper_16_bits - return bits 16-31 of a number
- * @n: the number we're accessing
- */
-#define upper_16_bits(n) ((u16)((n) >> 16))
-
-/**
- * lower_16_bits - return bits 0-15 of a number
- * @n: the number we're accessing
- */
-#define lower_16_bits(n) ((u16)((n) & 0xffff))
-
struct completion;
struct user;
diff --git a/include/linux/wordpart.h b/include/linux/wordpart.h
index c9e6bd773ebd..f6f8f83b15b0 100644
--- a/include/linux/wordpart.h
+++ b/include/linux/wordpart.h
@@ -2,6 +2,35 @@
#ifndef _LINUX_WORDPART_H
#define _LINUX_WORDPART_H
+
+/**
+ * upper_32_bits - return bits 32-63 of a number
+ * @n: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress
+ * the "right shift count >= width of type" warning when that quantity is
+ * 32-bits.
+ */
+#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
+
+/**
+ * lower_32_bits - return bits 0-31 of a number
+ * @n: the number we're accessing
+ */
+#define lower_32_bits(n) ((u32)((n) & 0xffffffff))
+
+/**
+ * upper_16_bits - return bits 16-31 of a number
+ * @n: the number we're accessing
+ */
+#define upper_16_bits(n) ((u16)((n) >> 16))
+
+/**
+ * lower_16_bits - return bits 0-15 of a number
+ * @n: the number we're accessing
+ */
+#define lower_16_bits(n) ((u16)((n) & 0xffff))
+
/**
* REPEAT_BYTE - repeat the value @x multiple times as an unsigned long value
* @x: value to repeat
--
2.43.0.rc1.1.gbec44491f096
On Thu, Feb 15, 2024 at 9:49 AM Andy Shevchenko
<[email protected]> wrote:
> The wordpart.h header is collecting APIs related to the handling
> parts of the word (usually in byte granularity). The upper_*_bits()
> and lower_*_bits() are good candidates to be moved to there.
Sigh. This was actually a copy of my patch which I submitted a week
before yours. https://lore.kernel.org/lkml/[email protected]/
On Thu, Feb 15, 2024 at 09:53:48AM +0100, Max Kellermann wrote:
> On Thu, Feb 15, 2024 at 9:49 AM Andy Shevchenko
> <[email protected]> wrote:
> > The wordpart.h header is collecting APIs related to the handling
> > parts of the word (usually in byte granularity). The upper_*_bits()
> > and lower_*_bits() are good candidates to be moved to there.
>
> Sigh. This was actually a copy of my patch which I submitted a week
> before yours. https://lore.kernel.org/lkml/[email protected]/
But it was not standalone and the series has issues AFAICS.
Nevertheless, I like it!
In any case the wordpart.h is only in Kees' tree, hence can't be applied
separately right now, so if you continue with a series it's technically can't
be applied before v6.9-rc1.
--
With Best Regards,
Andy Shevchenko
On Thu, Feb 15, 2024 at 03:50:51PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 15, 2024 at 09:53:48AM +0100, Max Kellermann wrote:
> > On Thu, Feb 15, 2024 at 9:49 AM Andy Shevchenko
> > <[email protected]> wrote:
> > > The wordpart.h header is collecting APIs related to the handling
> > > parts of the word (usually in byte granularity). The upper_*_bits()
> > > and lower_*_bits() are good candidates to be moved to there.
> >
> > Sigh. This was actually a copy of my patch which I submitted a week
> > before yours. https://lore.kernel.org/lkml/[email protected]/
>
> But it was not standalone and the series has issues AFAICS.
> Nevertheless, I like it!
>
> In any case the wordpart.h is only in Kees' tree, hence can't be applied
> separately right now, so if you continue with a series it's technically can't
> be applied before v6.9-rc1.
Btw, you need to look to the patches by Ingo, you are repeating some of them.
--
With Best Regards,
Andy Shevchenko