On Fri, 17 Jul 2015, Laura Abbott wrote:
> v2: Tweaked a few names to be more descriptive

Descriptive by some definition of descriptive. See below.

> +static void init_intel_energy_perf(struct cpuinfo_x86 *c)
> +{
> +     /*
> +      * Initialize MSR_IA32_ENERGY_PERF_BIAS if BIOS did not.
> +      * x86_energy_perf_policy(8) is available to change it at run-time
> +      */
> +     if (cpu_has(c, X86_FEATURE_EPB)) {

Make this 

        if (!cpu_has(c, X86_FEATURE_EPB))
                return;

and spare the extra indentation level.

> +             u64 epb;
> +             rdmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
> +             if ((epb & 0xF) == ENERGY_PERF_BIAS_PERFORMANCE) {

Ditto

> +                     pr_warn_once("ENERGY_PERF_BIAS: Set to 'normal', was 
> 'performance'\n");
> +                     pr_warn_once("ENERGY_PERF_BIAS: View and update with 
> x86_energy_perf_policy(8)\n");
> +                     epb = (epb & ~0xF) | ENERGY_PERF_BIAS_NORMAL;
> +                     wrmsrl(MSR_IA32_ENERGY_PERF_BIAS, epb);
> +             }
> +     }
> +}
>  #ifdef CONFIG_X86_32
> @@ -747,6 +752,7 @@ static const struct cpu_dev intel_cpu_dev = {
>       .c_detect_tlb   = intel_detect_tlb,
>       .c_early_init   = early_init_intel,
>       .c_init         = init_intel,
> +     .c_bsp_resume   = init_intel_energy_perf,

Looking at the resulting code I have no idea WHY
init_intel_energy_perf is set here. So much for descriptive.

This really wants to be bsp_resume() or something like this (add the
pointless intel prefix if it makes your managers happy). That _IS_
actually descriptive.

static void bsp_resume(struct cpuinfo_x86 *c)
{
        /*
         * Some reasonable comment WHY we call this here.
         */
         init_intel_energy_perf(c);
}

Aside of documenting what that resume thing is for and why
init_intel_energy_perf() needs to be called, I'm quite sure that this
will fill up pretty fast with other stuff which gets lost across S/R.

Thanks,

        tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to