From: Dave Hansen <dave.hansen@linux.intel.com>
The intel-family.h header uses Vendor/Family/Model macros but it does not
#include the header where they are defined. If that header is included,
the build blows up in #include hell.
Luckily, these macros are completely independent and do not themselves
have any dependencies on other code.
Break the VFM_*() macros out into their own header.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: x86@kernel.org
Cc: Jon Kohler <jon@nutanix.com>
---
b/arch/x86/include/asm/cpu_device_id.h | 33 ----------------------------
b/arch/x86/include/asm/vfm.h | 38 +++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 32 deletions(-)
diff -puN arch/x86/include/asm/cpu_device_id.h~x86-vfm_h arch/x86/include/asm/cpu_device_id.h
--- a/arch/x86/include/asm/cpu_device_id.h~x86-vfm_h 2026-01-19 11:38:07.714851835 -0800
+++ b/arch/x86/include/asm/cpu_device_id.h 2026-01-19 11:38:07.717851949 -0800
@@ -2,38 +2,7 @@
#ifndef _ASM_X86_CPU_DEVICE_ID
#define _ASM_X86_CPU_DEVICE_ID
-/*
- * Can't use <linux/bitfield.h> because it generates expressions that
- * cannot be used in structure initializers. Bitfield construction
- * here must match the union in struct cpuinfo_86:
- * union {
- * struct {
- * __u8 x86_model;
- * __u8 x86;
- * __u8 x86_vendor;
- * __u8 x86_reserved;
- * };
- * __u32 x86_vfm;
- * };
- */
-#define VFM_MODEL_BIT 0
-#define VFM_FAMILY_BIT 8
-#define VFM_VENDOR_BIT 16
-#define VFM_RSVD_BIT 24
-
-#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
-#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
-#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
-
-#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
-#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
-#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
-
-#define VFM_MAKE(_vendor, _family, _model) ( \
- ((_model) << VFM_MODEL_BIT) | \
- ((_family) << VFM_FAMILY_BIT) | \
- ((_vendor) << VFM_VENDOR_BIT) \
-)
+#include <asm/vfm.h>
/*
* Declare drivers belonging to specific x86 CPUs
diff -puN /dev/null arch/x86/include/asm/vfm.h
--- /dev/null 2025-12-13 18:24:00.793641044 -0800
+++ b/arch/x86/include/asm/vfm.h 2026-01-19 11:38:07.717851949 -0800
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_VFM
+#define _ASM_X86_VFM
+
+/*
+ * Can't use <linux/bitfield.h> because it generates expressions that
+ * cannot be used in structure initializers. Bitfield construction
+ * here must match the union in struct cpuinfo_86:
+ * union {
+ * struct {
+ * __u8 x86_model;
+ * __u8 x86;
+ * __u8 x86_vendor;
+ * __u8 x86_reserved;
+ * };
+ * __u32 x86_vfm;
+ * };
+ */
+#define VFM_MODEL_BIT 0
+#define VFM_FAMILY_BIT 8
+#define VFM_VENDOR_BIT 16
+#define VFM_RSVD_BIT 24
+
+#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
+#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
+#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
+
+#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
+#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
+#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
+
+#define VFM_MAKE(_vendor, _family, _model) ( \
+ ((_model) << VFM_MODEL_BIT) | \
+ ((_family) << VFM_FAMILY_BIT) | \
+ ((_vendor) << VFM_VENDOR_BIT) \
+)
+
+#endif /* _ASM_X86_VFM */
_On Mon, Jan 19, 2026 at 11:50:49AM -0800, Dave Hansen wrote: > The intel-family.h header uses Vendor/Family/Model macros but it does not > #include the header where they are defined. If that header is included, > the build blows up in #include hell. > > Luckily, these macros are completely independent and do not themselves > have any dependencies on other code. > > Break the VFM_*() macros out into their own header. > > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Still don't understand why people putting Cc list before the cutter. This noise in the commit message and when retrospectively one reads on the small screen (I do on the phone from time to time) it makes it at bare miniumum inconvenient). > Cc: Thomas Gleixner <tglx@kernel.org> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Borislav Petkov <bp@alien8.de> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: Tony Luck <tony.luck@intel.com> > Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> > Cc: x86@kernel.org > Cc: Jon Kohler <jon@nutanix.com> > --- ... > +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT) > +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT) > +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT) There are tabs after #define, is it on purpose? (yes, I know this is simple move, but if not deliberate, we can tweak the tabs/spaces while at it) ... > +#define VFM_MAKE(_vendor, _family, _model) ( \ Ditto. > + ((_model) << VFM_MODEL_BIT) | \ > + ((_family) << VFM_FAMILY_BIT) | \ > + ((_vendor) << VFM_VENDOR_BIT) \ > +) -- With Best Regards, Andy Shevchenko
> > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> > > Still don't understand why people putting Cc list before the cutter. This noise > in the commit message and when retrospectively one reads on the small screen (I > do on the phone from time to time) it makes it at bare miniumum inconvenient). > > > Cc: Thomas Gleixner <tglx@kernel.org> > > Cc: Ingo Molnar <mingo@redhat.com> > > Cc: Borislav Petkov <bp@alien8.de> > > Cc: Dave Hansen <dave.hansen@linux.intel.com> > > Cc: "H. Peter Anvin" <hpa@zytor.com> > > Cc: Tony Luck <tony.luck@intel.com> > > Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> > > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> > > Cc: x86@kernel.org > > Cc: Jon Kohler <jon@nutanix.com> > > --- I put stuff above the "---" because I'm a dinosaur using GIT and often use: $ git format-patch .... ... $ git am 00* to rebase, reorder, move bits from one patch to another, or generate a new version of the series. When I do so the "git am" drops everything after the "---" cut line. I poked around, but couldn't find any way to make "git am" keep it :-( -Tony
On Tue, Jan 20, 2026 at 04:48:55PM +0000, Luck, Tony wrote: > > > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> > > > > Still don't understand why people putting Cc list before the cutter. This noise > > in the commit message and when retrospectively one reads on the small screen (I > > do on the phone from time to time) it makes it at bare miniumum inconvenient). > > > > > Cc: Thomas Gleixner <tglx@kernel.org> > > > Cc: Ingo Molnar <mingo@redhat.com> > > > Cc: Borislav Petkov <bp@alien8.de> > > > Cc: Dave Hansen <dave.hansen@linux.intel.com> > > > Cc: "H. Peter Anvin" <hpa@zytor.com> > > > Cc: Tony Luck <tony.luck@intel.com> > > > Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> > > > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> > > > Cc: x86@kernel.org > > > Cc: Jon Kohler <jon@nutanix.com> > > > --- > > I put stuff above the "---" because I'm a dinosaur using GIT and often use: > > $ git format-patch .... > > ... > > $ git am 00* I couldn't imagine why I would need to use this flow for my own changes. We have rebase, worktree, multiple remotes in one tree, etc. I think the keyword is 'dinosaur' and now is 21st century :-) > to rebase, reorder, move bits from one patch to another, or generate a new > version of the series. When I do so the "git am" drops everything after the "---" cut line. > > I poked around, but couldn't find any way to make "git am" keep it :-( That's the idea, to get them dropped when a maintainer applies the series. lore.kernel.org will keep the list anyway. Haven't researched `b4 relay`, maybe that one helps to carry the Cc list on... -- With Best Regards, Andy Shevchenko
On 1/20/26 00:24, Andy Shevchenko wrote: >> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT) >> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT) >> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT) > There are tabs after #define, is it on purpose? > (yes, I know this is simple move, but if not deliberate, we can tweak > the tabs/spaces while at it) Yes, you can, but I chose not to here. Is there any compelling reason to tweak it?
On Tue, Jan 20, 2026 at 07:03:31AM -0800, Dave Hansen wrote: > On 1/20/26 00:24, Andy Shevchenko wrote: > >> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT) > >> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT) > >> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT) > > There are tabs after #define, is it on purpose? > > (yes, I know this is simple move, but if not deliberate, we can tweak > > the tabs/spaces while at it) > > Yes, you can, but I chose not to here. Is there any compelling reason to > tweak it? The usual style to use spaces there. Using tabs makes it mixed and inconsistent. So the expectation of a define is #define<single space>$FOO<TAB(s)>$VALUE -- With Best Regards, Andy Shevchenko
On 1/20/26 08:22, Andy Shevchenko wrote: > On Tue, Jan 20, 2026 at 07:03:31AM -0800, Dave Hansen wrote: >> On 1/20/26 00:24, Andy Shevchenko wrote: >>>> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT) >>>> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT) >>>> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT) >>> There are tabs after #define, is it on purpose? >>> (yes, I know this is simple move, but if not deliberate, we can tweak >>> the tabs/spaces while at it) >> Yes, you can, but I chose not to here. Is there any compelling reason to >> tweak it? > The usual style to use spaces there. Using tabs makes it mixed and > inconsistent. So the expectation of a define is > > #define<single space>$FOO<TAB(s)>$VALUE Remember, this code is being moved, not newly-composed. It's being moved for a bug fix and not being "cleaned up" or massaged for other purposes. In a bug fix series, I tend toward changing as few things as possible. That includes fixing up whitespace. I apply patches all the time that move code where that code breaks coding-style.rst in _some_way. I'm more than happy to ignore the checkpatch warnings there. I'm also not going to NAK a bug fix that cleans up whitespace. It's really submitter's preference. _Both_ are fine. It's really 100% up to the maintainer that applies it. In this case, the maintainer obviously has a preference, so why belabor the point? ;)
On Tue, Jan 20, 2026 at 08:34:49AM -0800, Dave Hansen wrote: > On 1/20/26 08:22, Andy Shevchenko wrote: > > On Tue, Jan 20, 2026 at 07:03:31AM -0800, Dave Hansen wrote: > >> On 1/20/26 00:24, Andy Shevchenko wrote: > >>>> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT) > >>>> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT) > >>>> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT) > >>> There are tabs after #define, is it on purpose? > >>> (yes, I know this is simple move, but if not deliberate, we can tweak > >>> the tabs/spaces while at it) > >> Yes, you can, but I chose not to here. Is there any compelling reason to > >> tweak it? > > The usual style to use spaces there. Using tabs makes it mixed and > > inconsistent. So the expectation of a define is > > > > #define<single space>$FOO<TAB(s)>$VALUE > > Remember, this code is being moved, not newly-composed. See what I put in the parentheses, this is exactly what I admit from the beginning. > It's being moved for a bug fix and not being "cleaned up" or massaged > for other purposes. Sure, but it makes no direct visible differences if amended. I don't see why we would bother with an additional patch to fix white spaces. > In a bug fix series, I tend toward changing as few things as possible. > That includes fixing up whitespace. I apply patches all the time that > move code where that code breaks coding-style.rst in _some_way. I'm more > than happy to ignore the checkpatch warnings there. > > I'm also not going to NAK a bug fix that cleans up whitespace. It's > really submitter's preference. _Both_ are fine. > > It's really 100% up to the maintainer that applies it. In this case, the > maintainer obviously has a preference, so why belabor the point? ;) Definitely. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.