Re: [PATCH v4 28/34] x86/cacheinfo: Use parsed CPUID(0x80000005) and CPUID(0x80000006)

"Ahmed S. Darwish" <[email protected]>
Newsgroups dev.linux.lists.x86-cpuid,org.kernel.vger.linux-kernel
Message-ID <aKNJB1uM4LIX3WDw@lx-t490>
On Fri, 15 Aug 2025, Dave Hansen wrote:
>
> On 8/15/25 00:02, Ahmed S. Darwish wrote:
> > +static void legacy_amd_cpuid4(struct cpuinfo_x86 *c, int index, struct leaf_0x4_0 *regs)
> >  {
> > -	unsigned int dummy, line_size, lines_per_tag, assoc, size_in_kb;
> > -	union l1_cache l1i, l1d, *l1;
> > -	union l2_cache l2;
> > -	union l3_cache l3;
> > +	const struct leaf_0x80000005_0 *el5 = cpuid_leaf(c, 0x80000005);
> > +	const struct leaf_0x80000006_0 *el6 = cpuid_leaf(c, 0x80000006);
> > +	const struct cpuid_regs *el5_raw = (const struct cpuid_regs *)el5;
>
> Is there any way we could get rid of the casts? The lack of type safety
> on those always worries me. Maybe a helper like this:
>
>     const struct cpuid_regs *el5_raw = cpuid_leaf_raw(c, 0x80000006);
>
> (although that would probably just do casts internally).
>

Indeed.

I already have at <asm/cpuid/api.h>:

    /**
     * cpuid_leaf_regs() - Access parsed CPUID data in raw format
     * @_cpuinfo:	CPU capability structure reference ('struct cpuinfo_x86')
     * @_leaf:		CPUID leaf, in compile-time 0xN format
     *
     * Similar to cpuid_leaf(), but returns a raw 'struct cpuid_regs' pointer to
     * the parsed CPUID data instead of a "typed" <cpuid/leaf_types.h> pointer.
     */
    #define cpuid_leaf_regs(_cpuinfo, _leaf)				\
	((struct cpuid_regs *)(cpuid_leaf(_cpuinfo, _leaf)))

The only reason I didn't use it in this patch was to avoid a repetion.
But, you're correct, using the API is better than call-site casting.

Thus, the code shall be:

    const struct leaf_0x80000005_0 *el5 = cpuid_leaf(c, 0x80000005);
    const struct leaf_0x80000006_0 *el6 = cpuid_leaf(c, 0x80000006);
    const struct cpuid_regs *el5_raw = cpuid_leaf_regs(c, 0x80000005);

I'll do it like that in v5.

Thanks!
Ahmed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.