Linux EDAC development
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Jürgen Groß" <jgross@suse.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-edac@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-hwmon@vger.kernel.org, linux-perf-users@vger.kernel.org,
	platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
	"Thomas Gleixner" <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Daniel Lezcano" <daniel.lezcano@kernel.org>,
	"Zhang Rui" <rui.zhang@intel.com>,
	"Lukasz Luba" <lukasz.luba@arm.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jiri Olsa" <jolsa@kernel.org>, "Ian Rogers" <irogers@google.com>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"James Clark" <james.clark@linaro.org>,
	"Huang Rui" <ray.huang@amd.com>,
	"Mario Limonciello" <mario.limonciello@amd.com>,
	"Perry Yuan" <perry.yuan@amd.com>,
	"K Prateek Nayak" <kprateek.nayak@amd.com>,
	"Srinivas Pandruvada" <srinivas.pandruvada@linux.intel.com>,
	"Len Brown" <lenb@kernel.org>, "Hans de Goede" <hansg@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Subject: Re: [PATCH 0/8] x86/msr: Drop 32-bit variants of *_on_cpu() MSR functions
Date: Fri, 5 Jun 2026 11:18:50 +0200	[thread overview]
Message-ID: <aiKUenaT9VD0DrpW@gmail.com> (raw)
In-Reply-To: <a477aefe-e1c8-4652-b263-86c4cce09eba@suse.com>


* Jürgen Groß <jgross@suse.com> wrote:

> On 05.06.26 11:05, Ingo Molnar wrote:
> > 
> > * Juergen Gross <jgross@suse.com> wrote:
> > 
> > > Drop the variants using 2 32-bit values instead of a single 64-bit one
> > > of the *_on_cpu() MSR access functions.
> > > 
> > > Juergen Gross (8):
> > >    x86/msr: Switch rdmsr_on_cpu() to return a 64-bit quantity
> > >    x86/msr: Switch all callers of rdmsrq_on_cpu() to use rdmsr_on_cpu()
> > >    x86/msr: Switch wrmsr_on_cpu() to use a 64-bit quantity
> > >    x86/msr: Switch all callers of wrmsrq_on_cpu() to use wrmsr_on_cpu()
> > >    x86/msr: Switch rdmsr_safe_on_cpu() to return a 64-bit quantity
> > >    x86/msr: Switch all callers of rdmsrq_safe_on_cpu() to use rdmsr_safe_on_cpu()
> > >    x86/msr: Switch wrmsr_safe_on_cpu() to use a 64-bit quantity
> > >    x86/msr: Switch all callers of wrmsrq_safe_on_cpu() to use  wrmsr_safe_on_cpu()
> > 
> > To sum up my review feedback for the invididual patches, we want
> > to do this instead:
> > 
> >    x86/msr: Convert rdmsrl_on_cpu() users to rdmsrq_on_cpu()
> >    x86/msr: Drop the rdmsrl_on_cpu() alias to rdmsrq_on_cpu()
> > 
> >    x86/msr: Switch all callers of rdmsr_on_cpu() to use rdmsrq_on_cpu()
> >    x86/msr: Remove the unused rdmsr_on_cpu() API
> > 
> >    x86/msr: Switch all callers of wrmsr_on_cpu() to use wrmsrq_on_cpu()
> >    x86/msr: Remove unused wrmsr_on_cpu() API
> > 
> >    x86/msr: Switch all callers of rdmsr_safe_on_cpu() to use rdmsrq_safe_on_cpu()
> >    x86/msr: Remove unused rdmsr_safe_on_cpu() API
> > 
> >    x86/msr: Switch all callers of wrmsr_safe_on_cpu() to use wrmsrq_safe_on_cpu()
> >    x86/mrs: Remove unused wrmsrq_safe_on_cpu() API
> > 
> > Note how there's no "conversion" of the 32-bit API itself in this
> > approach, we just do a straightforward migration of the users to
> > the already existing 64-bit APIs, then remove any unused APIs.
> 
> Fine with me, but I just wanted to get rid of the "q" and "l" suffices
> completely, as they serve no special purpose after dropping all other
> variants.
> 
> OTOH if wanted such a switch could be done later easily.

Well, we had a similar discussion back when we standardized on
rdmsrq() and wrmsrq(), and we use them as our primary 64-bit
MSR handling APIs. Why have a different pattern in any of the
derived APIs? It should really use the same conceptual namespace,
not some confusing mixture of two naming schemes.

Thanks,

	Ingo

  reply	other threads:[~2026-06-05  9:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05  7:08 [PATCH 0/8] x86/msr: Drop 32-bit variants of *_on_cpu() MSR functions Juergen Gross
2026-06-05  7:08 ` [PATCH 1/8] x86/msr: Switch rdmsr_on_cpu() to return a 64-bit quantity Juergen Gross
2026-06-05  7:08 ` [PATCH 2/8] x86/msr: Switch all callers of rdmsrq_on_cpu() to use rdmsr_on_cpu() Juergen Gross
2026-06-05  9:00   ` Ingo Molnar
2026-06-05  7:08 ` [PATCH 3/8] x86/msr: Switch wrmsr_on_cpu() to use a 64-bit quantity Juergen Gross
2026-06-05  9:05 ` [PATCH 0/8] x86/msr: Drop 32-bit variants of *_on_cpu() MSR functions Ingo Molnar
2026-06-05  9:13   ` Jürgen Groß
2026-06-05  9:18     ` Ingo Molnar [this message]
2026-06-05  9:40       ` Jürgen Groß
2026-06-05  9:54         ` Ingo Molnar
2026-06-05  9:56           ` Ingo Molnar
2026-06-05 10:05             ` Jürgen Groß
2026-06-05 10:06             ` Jürgen Groß

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aiKUenaT9VD0DrpW@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=daniel.lezcano@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=hansg@kernel.org \
    --cc=hpa@zytor.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jgross@suse.com \
    --cc=jolsa@kernel.org \
    --cc=kprateek.nayak@amd.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lukasz.luba@arm.com \
    --cc=mario.limonciello@amd.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=perry.yuan@amd.com \
    --cc=peterz@infradead.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=rui.zhang@intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=viresh.kumar@linaro.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox