Re: [tip: x86/msr] x86/cpu: Stop using 32-bit MSR interfaces

From: Ingo Molnar

Date: Fri Jul 17 2026 - 05:36:19 EST



* Borislav Petkov <bp@xxxxxxxxx> wrote:

> On Thu, Jul 02, 2026 at 10:15:54AM -0000, tip-bot2 for Juergen Gross wrote:
> > diff --git a/arch/x86/kernel/cpu/transmeta.c b/arch/x86/kernel/cpu/transmeta.c
> > index 1fdcd69..c670fbb 100644
> > --- a/arch/x86/kernel/cpu/transmeta.c
> > +++ b/arch/x86/kernel/cpu/transmeta.c
> > @@ -24,7 +24,8 @@ static void early_init_transmeta(struct cpuinfo_x86 *c)
> >
> > static void init_transmeta(struct cpuinfo_x86 *c)
> > {
> > - unsigned int cap_mask, uk, max, dummy;
> > + u64 msr;
> > + unsigned int max, dummy;
> > unsigned int cms_rev1, cms_rev2;
> > unsigned int cpu_rev, cpu_freq = 0, cpu_flags, new_cpu_rev;
> > char cpu_info[65];
>
> The tip-tree preferred ordering of variable declarations at the
> beginning of a function is reverse fir tree order::

While that's true, the style violation is a pre-existing condition
in the current code:

unsigned int cap_mask, uk, max, dummy;
unsigned int cms_rev1, cms_rev2;
unsigned int cpu_rev, cpu_freq = 0, cpu_flags, new_cpu_rev;
char cpu_info[65];

... and the best policy regarding API conversion patches like this
is to keep the original style, to not mix several changes together,
which only makes review harder.

But I agree with fixing the style problems of course, but it should
be done either in a preparatory patch, or in a followup patch. Either
ordering is fine to me.

Thanks,

Ingo