| Message ID | 522FE369.3030106@intel.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On 11 September 2013 08:58, Lan Tianyu <tianyu.lan@intel.com> wrote: > From 668e1b6fd94b5c0e56a651b4c60cbbc7a6868b46 Mon Sep 17 00:00:00 2001 > From: Lan Tianyu <tianyu.lan@intel.com> > Date: Wed, 11 Sep 2013 11:31:15 +0800 > Subject: [PATCH] Cpufreq/governor: Remove fossil comment > > cpufreq_set_policy() has been changed to origin __cpufreq_set_policy() > and policy->lock has been converted to rewrite lock by commit 5a01f2. > So remove it. > > Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> > --- > drivers/cpufreq/cpufreq_userspace.c | 11 ----------- > 1 file changed, 11 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq_userspace.c > b/drivers/cpufreq/cpufreq_userspace.c > index 0307809..4dbf1db 100644 > --- a/drivers/cpufreq/cpufreq_userspace.c > +++ b/drivers/cpufreq/cpufreq_userspace.c > @@ -38,18 +38,7 @@ static int cpufreq_set(struct cpufreq_policy *policy, > unsigned int freq) > if (!per_cpu(cpu_is_managed, policy->cpu)) > goto err; > > - /* > - * We're safe from concurrent calls to ->target() here > - * as we hold the userspace_mutex lock. If we were calling > - * cpufreq_driver_target, a deadlock situation might occur: > - * A: cpufreq_set (lock userspace_mutex) -> > - * cpufreq_driver_target(lock policy->lock) > - * B: cpufreq_set_policy(lock policy->lock) -> > - * __cpufreq_governor -> > - * cpufreq_governor_userspace (lock userspace_mutex) > - */ > ret = __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L); > - > err: > mutex_unlock(&userspace_mutex); > return ret; Looks fine: Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/11/2013 06:08 AM, Viresh Kumar wrote: > On 11 September 2013 08:58, Lan Tianyu <tianyu.lan@intel.com> wrote: >> From 668e1b6fd94b5c0e56a651b4c60cbbc7a6868b46 Mon Sep 17 00:00:00 2001 >> From: Lan Tianyu <tianyu.lan@intel.com> >> Date: Wed, 11 Sep 2013 11:31:15 +0800 >> Subject: [PATCH] Cpufreq/governor: Remove fossil comment >> >> cpufreq_set_policy() has been changed to origin __cpufreq_set_policy() >> and policy->lock has been converted to rewrite lock by commit 5a01f2. >> So remove it. >> >> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> >> --- >> drivers/cpufreq/cpufreq_userspace.c | 11 ----------- >> 1 file changed, 11 deletions(-) >> >> diff --git a/drivers/cpufreq/cpufreq_userspace.c >> b/drivers/cpufreq/cpufreq_userspace.c >> index 0307809..4dbf1db 100644 >> --- a/drivers/cpufreq/cpufreq_userspace.c >> +++ b/drivers/cpufreq/cpufreq_userspace.c >> @@ -38,18 +38,7 @@ static int cpufreq_set(struct cpufreq_policy *policy, >> unsigned int freq) >> if (!per_cpu(cpu_is_managed, policy->cpu)) >> goto err; >> >> - /* >> - * We're safe from concurrent calls to ->target() here >> - * as we hold the userspace_mutex lock. If we were calling >> - * cpufreq_driver_target, a deadlock situation might occur: >> - * A: cpufreq_set (lock userspace_mutex) -> >> - * cpufreq_driver_target(lock policy->lock) >> - * B: cpufreq_set_policy(lock policy->lock) -> >> - * __cpufreq_governor -> >> - * cpufreq_governor_userspace (lock userspace_mutex) >> - */ >> ret = __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L); >> - >> err: >> mutex_unlock(&userspace_mutex); >> return ret; > > Looks fine: > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > Thanks. I will send formal version. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c index 0307809..4dbf1db 100644 --- a/drivers/cpufreq/cpufreq_userspace.c +++ b/drivers/cpufreq/cpufreq_userspace.c @@ -38,18 +38,7 @@ static int cpufreq_set(struct cpufreq_policy *policy, unsigned int freq) if (!per_cpu(cpu_is_managed, policy->cpu)) goto err; - /* - * We're safe from concurrent calls to ->target() here - * as we hold the userspace_mutex lock. If we were calling - * cpufreq_driver_target, a deadlock situation might occur: - * A: cpufreq_set (lock userspace_mutex) -> - * cpufreq_driver_target(lock policy->lock) - * B: cpufreq_set_policy(lock policy->lock) -> - * __cpufreq_governor -> - * cpufreq_governor_userspace (lock userspace_mutex) - */ ret = __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L); - err: mutex_unlock(&userspace_mutex);