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: <aW_ridAxfzQ5TU6S@black.igk.intel.com>
Date: Tue, 20 Jan 2026 21:54:33 +0100
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Dave Hansen <dave.hansen@...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 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