linux-kernel - Re: [PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181023193405.pxfl4vyazt7rtc3x@isilmar-4.linta.de>
Date:   Tue, 23 Oct 2018 21:34:05 +0200
From:   Dominik Brodowski <linux@...inikbrodowski.net>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc:     linux-pm@...r.kernel.org, lenb@...nel.org, rjw@...ysocki.net,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

On Tue, Oct 23, 2018 at 12:17:28PM -0700, Srinivas Pandruvada wrote:
> On Tue, 2018-10-23 at 20:54 +0200, Dominik Brodowski wrote:
> > Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency
> > attribute")
> Thanks for the fix.
> 
> > Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > Cc: Len Brown <lenb@...nel.org>
> > Signed-off-by: Dominik Brodowski <linux@...inikbrodowski.net>
> > 
> > diff --git a/drivers/cpufreq/intel_pstate.c
> > b/drivers/cpufreq/intel_pstate.c
> > index 49c0abf2d48f..50c5699970c5 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -390,11 +390,6 @@ static int intel_pstate_get_cppc_guranteed(int
> > cpu)
> >  static void intel_pstate_set_itmt_prio(int cpu)
> >  {
> >  }
> > -
> > -static int intel_pstate_get_cppc_guranteed(int cpu)
> > -{
> > -	return -ENOTSUPP;
> > -}
> What is ACPI is defined but SCHED_MC_PRIO is not defined?
> Based on
> "select ACPI_CPPC_LIB if X86_64 && ACPI && SCHED_MC_PRIO"
> 
> So the above is still required. correct?

Seems so, yes. Though that leads to either complicated #ifdefs or code
duplications.

In any case, I'd suggest marking at least nested #else and #endif lines
with comments denoting which #ifdef they relate to, e.g.

	#else	/* CONFIG_ACPI */
	#endif	/* CONFIG_ACPI */

Thanks,
	Dominik