Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces

Ingo Molnar <[email protected]> Fri, 17 Jul 2026 11:38:45 +0200
Newsgroups gmane.linux.ide,gmane.linux.kernel,gmane.linux.power-management.general,gmane.linux.acpi.devel,gmane.comp.emulators.kvm.devel,gmane.linux.kernel.pci,gmane.comp.video.dri.devel,gmane.linux.kernel.cryptoapi,gmane.linux.kernel.gpio,gmane.linux.kernel.hwmon,gmane.linux.kernel.perf.user,gmane.linux.drivers.mtd,gmane.linux.drivers.platform.x86.devel,gmane.linux.ports.geode,gmane.comp.emulators.xen.devel
Message-ID <[email protected]> 
* Juergen Gross <[email protected]> wrote:

> On 02.07.26 12:07, Ingo Molnar wrote:
> > 
> > * Sean Christopherson <[email protected]> wrote:
> > 
> > > > Note that the individual patches are IMO significantly easier to review
> > > > through the actual 32-bit => 64-bit variable assignment changes done
> > > > in isolation (which sometimes include minor cleanups), while
> > > > the Coccinelle semantic patch:
> > > > 
> > > >     { a(b,c) => c = a(b) }
> > > > 
> > > > which changes both the function signature and the order of terms as
> > > > well, is just a single add-on treewide patch.
> > > 
> > > Is the plan for subsystem maintainers to pick up the relevant patches,
> > > and then do the treewide change one release cycle later?
> > 
> > I'll try to keep the patches in a single tree (tip:x86/msr)
> > in the hope of not prolonging the pain two cycles - but it's
> > of course fine for maintainers to pick up the patches too
> > (most of them are standalone), we'll sort it all out in the end.
> 
> Ingo, would you be fine with me posting patch updates just as replies to the
> original patch emails? This would speed things up, as I wouldn't need to wait
> for more review input of all the patches before sending out new versions.

Sure, that works for me too. I've picked up a couple of -v2 patches
already.

Thanks,

	Ingo