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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d9fe7a29-c4cc-4ca7-a901-43051f1935d5@intel.com>
Date: Tue, 20 Jan 2026 08:34:49 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>, linux-kernel@...r.kernel.org,
 sohil.mehta@...el.com, Borislav Petkov <bp@...en8.de>,
 "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
 Jon Kohler <jon@...anix.com>, Pawan Gupta
 <pawan.kumar.gupta@...ux.intel.com>,
 "Peter Zijlstra (Intel)" <peterz@...radead.org>,
 Thomas Gleixner <tglx@...nel.org>, Tony Luck <tony.luck@...el.com>,
 x86@...nel.org
Subject: Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into
 separate header

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