Re: [PATCH] cpufreq: Don't use smp_processor_id() in preemptible context

2013-08-28 Thread Stephen Boyd
On 08/27/13 23:34, Viresh Kumar wrote: > On 28 August 2013 03:31, Stephen Boyd wrote: >> diff --git a/drivers/cpufreq/cpufreq_governor.c >> b/drivers/cpufreq/cpufreq_governor.c >> index b9b20fd..523af48 100644 >> --- a/drivers/cpufreq/cpufreq_governor.c >> +++ b/drivers/cpufreq/cpufreq_governor.c

Re: [PATCH] cpufreq: Don't use smp_processor_id() in preemptible context

2013-08-27 Thread Viresh Kumar
On 28 August 2013 03:31, Stephen Boyd wrote: > diff --git a/drivers/cpufreq/cpufreq_governor.c > b/drivers/cpufreq/cpufreq_governor.c > index b9b20fd..523af48 100644 > --- a/drivers/cpufreq/cpufreq_governor.c > +++ b/drivers/cpufreq/cpufreq_governor.c > @@ -137,7 +137,7 @@ void gov_queue_work(str

[PATCH] cpufreq: Don't use smp_processor_id() in preemptible context

2013-08-27 Thread Stephen Boyd
Workqueues are preemptible even if works are queued on them with queue_work_on(). Let's just use the policy->cpu argument here instead of using smp_processor_id() to silence the warning. BUG: using smp_processor_id() in preemptible [] code: kworker/3:2/674 caller is gov_queue_work+0x28/0xb