Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH 1/6] cpufreq: Use existing stub functions instead of IS_ENABLED macro | Date | Mon, 24 Jun 2019 11:30:07 +0200 |
| |
On Monday, June 24, 2019 11:22:19 AM CEST Daniel Lezcano wrote: > On 22/06/2019 11:12, Rafael J. Wysocki wrote: > > On Fri, Jun 21, 2019 at 3:23 PM Daniel Lezcano > > <daniel.lezcano@linaro.org> wrote: > >> > >> The functions stub already exist for the condition the IS_ENABLED > >> is trying to avoid. > >> > >> Remove the IS_ENABLED macros as they are pointless. > > > > AFAICS, the IS_ENABLED checks are an optimization to avoid generating > > pointless code (including a branch) in case CONFIG_CPU_THERMAL is not > > set. > > > > Why do you think that it is not useful? > > I agree but I'm not a big fan of IS_ENABLED macros in the code when it > is possible to avoid them. > > What about adding a stub for that like:
Well,
> #ifdef CPU_THERMAL > static inline int cpufreq_is_cooling_dev(struct cpufreq_driver *drv) > { > return drv->flags & CPUFREQ_IS_COOLING_DEV; > } > #else > static inline int cpufreq_is_cooling_dev(struct cpufreq_driver *drv) > { > return 0; > } > #endif
This may as well be defined as
static inline int cpufreq_is_cooling_dev(struct cpufreq_driver *drv) { return IS_ENABLED(CPU_THERMAL) && drv->flags & CPUFREQ_IS_COOLING_DEV; }
which is fewer lines of code.
And I would call it something like cpufreq_thermal_control_enabled().
| |