On 01/03/2014 07:26 AM, Dmitry Torokhov wrote
Unlocking in different branches is not the best practice IMO, I'd
recommend doing:
mutex_lock(&cpufreq_governor_lock);
if (!policy->governor_enabled)
goto out_unlock;
...
out_unlock:
mutex_unlock(&c
Hi Jane:
On Thu, Jan 02, 2014 at 11:14:42AM +0800, j...@marvell.com wrote:
> @@ -119,8 +121,11 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
> cpufreq_policy *policy,
> {
> int i;
>
> - if (!policy->governor_enabled)
> + mutex_lock(&cpufreq_governor_lock);
> + if (
On 2 January 2014 08:44, wrote:
> From: Jane Li
>
> When a CPU is hot removed we'll cancel all the delayed work items via
> gov_cancel_work(). Sometimes the delayed work function determines that
> it should adjust the delay for all other CPUs that the policy is
> managing. If this scenario occur
From: Jane Li
When a CPU is hot removed we'll cancel all the delayed work items via
gov_cancel_work(). Sometimes the delayed work function determines that
it should adjust the delay for all other CPUs that the policy is
managing. If this scenario occurs, the canceling CPU will cancel its own
work
4 matches
Mail list logo