Hi Michael,
I haven't followed this mail chain earlier and saw this mail only as I am
added in cc now. I probably have answers to few questions here:
On 20 May 2013 12:36, Michael Wang <wangyun@xxxxxxxxxxxxxxxxxx> wrote:
> On 05/20/2013 02:58 PM, Michael Wang wrote:
>> On 05/20/2013 02:47 PM, Borislav Petkov wrote:
>>> On Mon, May 20, 2013 at 02:23:37PM +0800, Michael Wang wrote:
>>>> On 05/20/2013 12:50 PM, Borislav Petkov wrote:
>>>> So there are two questions here:
>>>> 1. Is gov_queue_work() want to queue the work on offline cpu?
No. We are only working with online cpus now in cpufreq core and governors.
>> Besides, the cpu gov_queue_work() is using 'policy->cpus' which seems to
>> be updated during UP DOWN notify, I think they are supposed to be online.
>>
>> But we need expert in cpufreq to confirm all these...
I confirm this. policy->cpus only contains online cpus.. and
policy->related_cpus
always contain online+offline cpus.
> And I guess this may help to reduce the chance to trigger WARN:
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index 443442d..0f96013 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -180,7 +180,7 @@ void gov_queue_work(struct dbs_data *dbs_data,
> struct cpufreq_policy *policy,
> if (!all_cpus) {
> __gov_queue_work(smp_processor_id(), dbs_data, delay);
> } else {
> - for_each_cpu(i, policy->cpus)
> + for_each_cpu_and(i, policy->cpus, cpu_online_mask)
> __gov_queue_work(i, dbs_data, delay);
> }
> }
Not required at all... policy->cpus is guaranteed to have only online cpus.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
