[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200616095438.v7wywhfq5ealvyih@vireshk-i7>
Date: Tue, 16 Jun 2020 15:24:38 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Quentin Perret <qperret@...gle.com>
Cc: rjw@...ysocki.net, rafael@...nel.org, arnd@...db.de,
mpe@...erman.id.au, benh@...nel.crashing.org, paulus@...ba.org,
mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, linuxppc-dev@...ts.ozlabs.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
kernel-team@...roid.com, tkjos@...gle.com, adharmap@...eaurora.org
Subject: Re: [PATCH 2/2] cpufreq: Specify default governor on command line
On 16-06-20, 10:48, Quentin Perret wrote:
> ---8<---
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 0f05caedc320..a9219404e07f 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2340,6 +2340,11 @@ int cpufreq_register_governor(struct cpufreq_governor *governor)
> list_add(&governor->governor_list, &cpufreq_governor_list);
> }
>
> + if (!strncasecmp(cpufreq_param_governor, governor->name, CPUFREQ_NAME_LEN))
> + default_governor = governor;
> + else if (!default_governor && cpufreq_default_governor() == governor)
> + default_governor = cpufreq_default_governor();
Instead of the else part here, maybe just do this from
cpufreq_core_init() only once, and so we will always have
default_governor set.
> +
> mutex_unlock(&cpufreq_governor_mutex);
> return err;
> }
> @@ -2368,6 +2373,8 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor)
>
> mutex_lock(&cpufreq_governor_mutex);
> list_del(&governor->governor_list);
> + if (governor == default_governor)
> + default_governor = cpufreq_default_governor();
> mutex_unlock(&cpufreq_governor_mutex);
> }
> EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
> --->8---
>
> should do the trick. That removes the unnecessary reference count, and
> feels like a good place to hook things -- that is how cpuidle does it
> too IIRC.
>
> I'll double check the locking/synchronization, but that shouldn't be too
> bad (famous last words).
>
> Cheers,
> Quentin
--
viresh
Powered by blists - more mailing lists