Re: [PATCH v6 09/90] x86/cpuid: Introduce a centralized CPUID parser

Maciej Wieczor-Retman <[email protected]> Tue, 28 Apr 2026 17:03:47 +0200
Newsgroups dev.linux.lists.x86-cpuid,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 2026-04-27 at 21:42:08 +0200, Ahmed S. Darwish wrote:
>On Wed, 15 Apr 2026, Maciej Wieczor-Retman wrote:
>>
>> Also should cpuid_parser.c/.h be attached to some subsystem in
>> MAINTAINERS? Not sure if it should or shouldn't but I noticed you added
>> leaf_types.h before and was curious if not adding new files is
>> intentional here.
>>
>
>IMHO, it should be maintained just like any other code within the x86 tree.
>
>leaf_types.h is added to MAINTAINERS x86 CPUID database entry at the
>previous patch so that I can catch anyone modifying it outside of
>x86-cpuid-db.

Okay, I thought cpuid_parser.c/h would fit more into the cpuid database but I
guess that's only for the tools directory.

>>
>> >
>> ...
>> >diff --git a/arch/x86/kernel/cpu/cpuid_parser.c b/arch/x86/kernel/cpu/cpuid_parser.c
>> >new file mode 100644
>> >index 000000000000..898b0c441431
>> >--- /dev/null
>> >+++ b/arch/x86/kernel/cpu/cpuid_parser.c
>> ...
>> >+static unsigned int cpuid_range_max_leaf(const struct cpuid_table *t, unsigned int range)
>> >+{
>> >+	const struct leaf_0x0_0 *l0 = __cpuid_table_subleaf(t, 0x0, 0);
>> >+
>> >+	switch (range) {
>> >+	case CPUID_BASE_START:	return l0  ?  l0->max_std_leaf : 0;
>> >+	default:		return 0;
>> >+	}
>> >+}
>>
>> Trailing statements should go on the next line, right?
>>
>
>By the end of this patch queue, this aligns well as a table:
>
>	switch (range) {
>	case CPUID_BASE_START:	return l0  ?  l0->max_std_leaf  : 0;
>	case CPUID_EXT_START:	return el0 ? el0->max_ext_leaf  : 0;
>	case CPUID_TMX_START:	return tl0 ? tl0->max_tra_leaf  : 0;
>	case CPUID_CTR_START:	return cl0 ? cl0->max_cntr_leaf : 0;
>	case CPUID_LNX_START:	return CPUID_LNX_END;
>	default:		return 0;
>	}
>
>Thanks,
>Ahmed

I guess that is a good reason to ignore checkpatch being picky :b
Ignore my other comments about this then.

-- 
Kind regards
Maciej Wieczór-Retman