Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header

[Andy Shevchenko <andriy.shevchenko@intel.com>]

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