On Tue, Jan 18, 2022 at 03:05:54PM +0100, Jan Beulich wrote:
> On 18.01.2022 11:17, Roger Pau Monné wrote:
> > On Mon, Sep 06, 2021 at 03:00:46PM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/cpu/mwait-idle.c
> >> +++ b/xen/arch/x86/cpu/mwait-idle.c
> >> @@ -742,6 +742,32 @@ static const struct cpuidle_state dnv_cs
> >>    {}
> >>  };
> >>  
> >> +/*
> >> + * Note, depending on HW and FW revision, SnowRidge SoC may or may not 
> >> support
> >> + * C6, and this is indicated in the CPUID mwait leaf.
> >> + */
> >> +static const struct cpuidle_state snr_cstates[] = {
> >> +  {
> >> +          .name = "C1",
> > 
> > We usually use names like "C1-SNR" or similar in other cpuidle_state
> > structs. Is using plain "C1" intentional here?
> 
> I don't know. We're simply following the Linux side change. If we're
> unhappy with their naming (it indeed looks inconsistent), then we
> ought to make a separate patch on top (and maybe submit that also to
> Linux).

Looks like at some point Linux dropped the '-SNR' and similar suffixes
from the state names, so we should likely import that patch as a
pre-req for consistency? It's commit:

de09cdd09fa1 intel_idle: stop exposing platform acronyms in sysfs

> 
> >> @@ -954,6 +980,11 @@ static const struct idle_cpu idle_cpu_dn
> >>    .disable_promotion_to_c1e = 1,
> >>  };
> >>  
> >> +static const struct idle_cpu idle_cpu_snr = {
> >> +  .state_table = snr_cstates,
> >> +  .disable_promotion_to_c1e = true,
> > 
> > This likely wants to be 1 because the type is bool_t.
> 
> bool_t is just an alias of bool, so "true" ought to be fine. We may
> want to follow Linux in switching to bool altogether - iirc we didn't
> have bool yet at the time the driver (or the first commit needing it)
> was ported. I guess I'll make a patch ...

OK, thanks!

I guess for the patch itself then:

Acked-by: Roger Pau Monné <roger....@citrix.com>

Would be nice to get those things fixed for consistency.

Roger.

Reply via email to