[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200626080924.GA281178@google.com>
Date: Fri, 26 Jun 2020 09:09:24 +0100
From: Quentin Perret <qperret@...gle.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
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 v2 2/2] cpufreq: Specify default governor on command line
On Friday 26 Jun 2020 at 08:23:46 (+0530), Viresh Kumar wrote:
> On 23-06-20, 15:21, Quentin Perret wrote:
> > @@ -2789,7 +2796,13 @@ static int __init cpufreq_core_init(void)
> > cpufreq_global_kobject = kobject_create_and_add("cpufreq", &cpu_subsys.dev_root->kobj);
> > BUG_ON(!cpufreq_global_kobject);
> >
> > + mutex_lock(&cpufreq_governor_mutex);
> > + if (!default_governor)
>
> Also is this check really required ? The pointer will always be NULL
> at this point, isn't it ?
Not necessarily in this implementation -- the governors are registered
at core_initcall time too, so I don't think we can assume any ordering
there.
But it looks like your new version has fixed that by design, so I'll go
look at it some more, and try it out.
Thanks for the help!
Quentin
>
> > + default_governor = cpufreq_default_governor();
> > + mutex_unlock(&cpufreq_governor_mutex);
> > +
> > return 0;
> > }
> > module_param(off, int, 0444);
> > +module_param_string(default_governor, cpufreq_param_governor, CPUFREQ_NAME_LEN, 0444);
> > core_initcall(cpufreq_core_init);
> > --
> > 2.27.0.111.gc72c7da667-goog
>
> --
> viresh
Powered by blists - more mailing lists