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

[Dave Hansen]

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? ;)