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

[Ingo Molnar <mingo@kernel.org>]

* Borislav Petkov <bp@alien8.de> 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