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

Ingo Molnar <[email protected]> Thu, 2 Jul 2026 12:07:15 +0200
Newsgroups org.kernel.vger.linux-fbdev,dev.linux.lists.linux-coco,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-mtd,org.kernel.vger.kvm,org.kernel.vger.linux-acpi,org.kernel.vger.linux-crypto,org.kernel.vger.linux-edac,org.kernel.vger.linux-gpio,org.kernel.vger.linux-hwmon,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-pm,org.kernel.vger.platform-driver-x86,org.xenproject.lists.xen-devel
Message-ID <[email protected]>
* 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.

Thanks,

	Ingo