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()

 arch/x86/events/intel/ds.c                    | 11 +--
 arch/x86/events/intel/pt.c                    |  2 +-
 arch/x86/events/intel/uncore_discovery.c      |  2 +-
 arch/x86/events/intel/uncore_snbep.c          |  2 +-
 arch/x86/include/asm/msr.h                    | 44 +++--------
 arch/x86/kernel/acpi/cppc.c                   |  8 +-
 arch/x86/kernel/cpu/intel_epb.c               |  8 +-
 arch/x86/kernel/cpu/mce/amd.c                 |  6 +-
 arch/x86/kernel/cpu/mce/inject.c              | 12 +--
 arch/x86/kernel/cpu/microcode/intel.c         |  2 +-
 arch/x86/kernel/msr.c                         |  8 +-
 arch/x86/lib/msr-smp.c                        | 79 ++-----------------
 drivers/cpufreq/acpi-cpufreq.c                |  4 +-
 drivers/cpufreq/amd-pstate-ut.c               |  2 +-
 drivers/cpufreq/amd-pstate.c                  | 21 +++--
 drivers/cpufreq/amd_freq_sensitivity.c        |  4 +-
 drivers/cpufreq/intel_pstate.c                | 64 +++++++--------
 drivers/cpufreq/p4-clockmod.c                 | 32 ++++----
 drivers/cpufreq/speedstep-centrino.c          | 27 ++++---
 drivers/hwmon/coretemp.c                      | 44 +++++------
 drivers/hwmon/via-cputemp.c                   | 16 ++--
 drivers/platform/x86/amd/hfi/hfi.c            |  4 +-
 .../intel/speed_select_if/isst_if_common.c    | 13 ++-
 .../intel/uncore-frequency/uncore-frequency.c | 12 +--
 drivers/powercap/intel_rapl_msr.c             |  2 +-
 drivers/thermal/intel/intel_tcc.c             | 43 +++++-----
 drivers/thermal/intel/x86_pkg_temp_thermal.c  | 22 +++---
 27 files changed, 203 insertions(+), 291 deletions(-)

-- 
2.54.0

* 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.

Thanks,

	Ingo

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.


Juergen

* 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

On 05.06.26 11:18, Ingo Molnar wrote:
> 
> * 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.

In the long run I'd like to do the same conversion for the rdmsr*() and
wrmsr*() interfaces, too (so only offering and using the 64-bit variants).

I understand that this is not guaranteed to be accepted immediately after
this series, so I agree that it is better to keep the "q" suffix for now
in order to avoid confusion.


Juergen

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

> > 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.
> 
> In the long run I'd like to do the same conversion for the rdmsr*() and
> wrmsr*() interfaces, too (so only offering and using the 64-bit variants).

Why? We had this discussion for the original MSR API namespace
cleanup a year ago, and decided to standardize on the rdmsrq()/wrmsrq()
namespace:

  c435e608cf59 x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'
  78255eb23973 x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'
  6fe22abacd40 x86/msr: Rename 'rdmsrl_safe()' to 'rdmsrq_safe()'
  6fa17efe4544 x86/msr: Rename 'wrmsrl_safe()' to 'wrmsrq_safe()'
  5e404cb7ac4c x86/msr: Rename 'rdmsrl_safe_on_cpu()' to 'rdmsrq_safe_on_cpu()'
  27a23a544a55 x86/msr: Rename 'wrmsrl_safe_on_cpu()' to 'wrmsrq_safe_on_cpu()'
  d7484babd2c4 x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'
  c895ecdab2e4 x86/msr: Rename 'wrmsrl_on_cpu()' to 'wrmsrq_on_cpu()'
  ebe29309c4d2 x86/msr: Rename 'mce_rdmsrl()' to 'mce_rdmsrq()'
  8e44e83f57c3 x86/msr: Rename 'mce_wrmsrl()' to 'mce_wrmsrq()'
  e2b8af0c6939 x86/msr: Rename 'rdmsrl_amd_safe()' to 'rdmsrq_amd_safe()'
  604d15d15ebd x86/msr: Rename 'wrmsrl_amd_safe()' to 'wrmsrq_amd_safe()'
  7cbc2ba7c107 x86/msr: Rename 'native_wrmsrl()' to 'native_wrmsrq()'
  eef476f15c83 x86/msr: Rename 'wrmsrl_cstar()' to 'wrmsrq_cstar()'

There's several good reasons to use the 'q' suffix in the API names,
why relitigate this? :-)

Thanks,

	Ingo

* Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Jürgen Groß <jgross@suse.com> wrote:
> 
> > > 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.
> > 
> > In the long run I'd like to do the same conversion for the rdmsr*() and
> > wrmsr*() interfaces, too (so only offering and using the 64-bit variants).
> 
> Why? We had this discussion for the original MSR API namespace
> cleanup a year ago, and decided to standardize on the rdmsrq()/wrmsrq()
> namespace:
> 
>   c435e608cf59 x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'
>   78255eb23973 x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'
>   6fe22abacd40 x86/msr: Rename 'rdmsrl_safe()' to 'rdmsrq_safe()'
>   6fa17efe4544 x86/msr: Rename 'wrmsrl_safe()' to 'wrmsrq_safe()'
>   5e404cb7ac4c x86/msr: Rename 'rdmsrl_safe_on_cpu()' to 'rdmsrq_safe_on_cpu()'
>   27a23a544a55 x86/msr: Rename 'wrmsrl_safe_on_cpu()' to 'wrmsrq_safe_on_cpu()'
>   d7484babd2c4 x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'
>   c895ecdab2e4 x86/msr: Rename 'wrmsrl_on_cpu()' to 'wrmsrq_on_cpu()'
>   ebe29309c4d2 x86/msr: Rename 'mce_rdmsrl()' to 'mce_rdmsrq()'
>   8e44e83f57c3 x86/msr: Rename 'mce_wrmsrl()' to 'mce_wrmsrq()'
>   e2b8af0c6939 x86/msr: Rename 'rdmsrl_amd_safe()' to 'rdmsrq_amd_safe()'
>   604d15d15ebd x86/msr: Rename 'wrmsrl_amd_safe()' to 'wrmsrq_amd_safe()'
>   7cbc2ba7c107 x86/msr: Rename 'native_wrmsrl()' to 'native_wrmsrq()'
>   eef476f15c83 x86/msr: Rename 'wrmsrl_cstar()' to 'wrmsrq_cstar()'
> 
> There's several good reasons to use the 'q' suffix in the API names,
> why relitigate this? :-)

And just to be clear: I have no objections whatsoever to
phasing out all the old 32-bit APIs, like your series does.

Thanks,

	Ingo

On 05.06.26 11:56, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@kernel.org> wrote:
> 
>>
>> * Jürgen Groß <jgross@suse.com> wrote:
>>
>>>> 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.
>>>
>>> In the long run I'd like to do the same conversion for the rdmsr*() and
>>> wrmsr*() interfaces, too (so only offering and using the 64-bit variants).
>>
>> Why? We had this discussion for the original MSR API namespace
>> cleanup a year ago, and decided to standardize on the rdmsrq()/wrmsrq()
>> namespace:
>>
>>    c435e608cf59 x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'
>>    78255eb23973 x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'
>>    6fe22abacd40 x86/msr: Rename 'rdmsrl_safe()' to 'rdmsrq_safe()'
>>    6fa17efe4544 x86/msr: Rename 'wrmsrl_safe()' to 'wrmsrq_safe()'
>>    5e404cb7ac4c x86/msr: Rename 'rdmsrl_safe_on_cpu()' to 'rdmsrq_safe_on_cpu()'
>>    27a23a544a55 x86/msr: Rename 'wrmsrl_safe_on_cpu()' to 'wrmsrq_safe_on_cpu()'
>>    d7484babd2c4 x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'
>>    c895ecdab2e4 x86/msr: Rename 'wrmsrl_on_cpu()' to 'wrmsrq_on_cpu()'
>>    ebe29309c4d2 x86/msr: Rename 'mce_rdmsrl()' to 'mce_rdmsrq()'
>>    8e44e83f57c3 x86/msr: Rename 'mce_wrmsrl()' to 'mce_wrmsrq()'
>>    e2b8af0c6939 x86/msr: Rename 'rdmsrl_amd_safe()' to 'rdmsrq_amd_safe()'
>>    604d15d15ebd x86/msr: Rename 'wrmsrl_amd_safe()' to 'wrmsrq_amd_safe()'
>>    7cbc2ba7c107 x86/msr: Rename 'native_wrmsrl()' to 'native_wrmsrq()'
>>    eef476f15c83 x86/msr: Rename 'wrmsrl_cstar()' to 'wrmsrq_cstar()'
>>
>> There's several good reasons to use the 'q' suffix in the API names,
>> why relitigate this? :-)
> 
> And just to be clear: I have no objections whatsoever to
> phasing out all the old 32-bit APIs, like your series does.

Thanks for the confirmation. :-)

And regarding the "q" suffix: I'm not insisting to drop it, I just felt it would
no longer be needed when the variants without suffix no longer exist. If you
like to keep it, then be it so.


Juergen

On 05.06.26 11:56, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@kernel.org> wrote:
> 
>>
>> * Jürgen Groß <jgross@suse.com> wrote:
>>
>>>> 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.
>>>
>>> In the long run I'd like to do the same conversion for the rdmsr*() and
>>> wrmsr*() interfaces, too (so only offering and using the 64-bit variants).
>>
>> Why? We had this discussion for the original MSR API namespace
>> cleanup a year ago, and decided to standardize on the rdmsrq()/wrmsrq()
>> namespace:
>>
>>    c435e608cf59 x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'
>>    78255eb23973 x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'
>>    6fe22abacd40 x86/msr: Rename 'rdmsrl_safe()' to 'rdmsrq_safe()'
>>    6fa17efe4544 x86/msr: Rename 'wrmsrl_safe()' to 'wrmsrq_safe()'
>>    5e404cb7ac4c x86/msr: Rename 'rdmsrl_safe_on_cpu()' to 'rdmsrq_safe_on_cpu()'
>>    27a23a544a55 x86/msr: Rename 'wrmsrl_safe_on_cpu()' to 'wrmsrq_safe_on_cpu()'
>>    d7484babd2c4 x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'
>>    c895ecdab2e4 x86/msr: Rename 'wrmsrl_on_cpu()' to 'wrmsrq_on_cpu()'
>>    ebe29309c4d2 x86/msr: Rename 'mce_rdmsrl()' to 'mce_rdmsrq()'
>>    8e44e83f57c3 x86/msr: Rename 'mce_wrmsrl()' to 'mce_wrmsrq()'
>>    e2b8af0c6939 x86/msr: Rename 'rdmsrl_amd_safe()' to 'rdmsrq_amd_safe()'
>>    604d15d15ebd x86/msr: Rename 'wrmsrl_amd_safe()' to 'wrmsrq_amd_safe()'
>>    7cbc2ba7c107 x86/msr: Rename 'native_wrmsrl()' to 'native_wrmsrq()'
>>    eef476f15c83 x86/msr: Rename 'wrmsrl_cstar()' to 'wrmsrq_cstar()'
>>
>> There's several good reasons to use the 'q' suffix in the API names,
>> why relitigate this? :-)
> 
> And just to be clear: I have no objections whatsoever to
> phasing out all the old 32-bit APIs, like your series does.

Thanks for the confirmation. :-)

And regarding the "q" suffix: I'm not insisting to drop it, I just felt it would
no longer be needed when the variants without suffix no longer exist. If you
like to keep it, then be it so.


Juergen