[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160204014927.GL3469@vireshk>
Date: Thu, 4 Feb 2016 07:19:27 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Saravana Kannan <skannan@...eaurora.org>
Cc: Rafael Wysocki <rjw@...ysocki.net>, juri.lelli@....com,
linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
peterz@...radead.org, mturquette@...libre.com,
steve.muckle@...aro.org, vincent.guittot@...aro.org,
morten.rasmussen@....com, dietmar.eggemann@....com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 5/7] cpufreq: Merge cpufreq_offline_prepare/finish
routines
On 03-02-16, 12:21, Saravana Kannan wrote:
> On 02/03/2016 06:02 AM, Viresh Kumar wrote:
> >The offline routine was separated into two halves earlier by
> >'commit 1aee40ac9c86 ("cpufreq: Invoke __cpufreq_remove_dev_finish()
> >after releasing cpu_hotplug.lock");.
> >
> >And the reasons cited were, race issues between accessing policy's sysfs
> >files and policy kobject's cleanup.
> >
> >That race isn't valid anymore, as we don't remove the policy & its
> >kobject completely on hotplugs, but do that from ->remove() callback of
> >subsys framework.
> >
> >These two routines can be merged back now.
> >
> >This is a preparatory step for the next patch, that will enforce
> >policy->rwsem lock around __cpufreq_governor() routines STOP/EXIT
> >sequence.
>
> Is this stale text? Seems like this is now done in the *previous* patch?
No, the previous patch has fixed a single location only. The next
patch tried to fix others as well.
--
viresh
Powered by blists - more mailing lists