On 07/15/2014 11:05 PM, skan...@codeaurora.org wrote:
Srivatsa S. Bhat wrote:
On 07/15/2014 11:06 AM, Saravana Kannan wrote:
On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote:
Yeah, it definitely crashes if policy-cpu
On 07/16/2014 11:14 AM, Viresh Kumar wrote:
On 15 July 2014 12:28, Srivatsa S. Bhat sriva...@mit.edu wrote:
Wait, allowing an offline CPU to be the policy-cpu (i.e., the CPU which is
considered as the master of the policy/group) is just absurd.
Yeah, that was as Absurd as I am :)
I have
doesn't re-introduce those
deadlock possibilities!
break;
}
}
I am still not sure if everything will work as expected as I seriously doubt
my reviewing capabilities. There might be corner cases which I am still
missing.
Regards,
Srivatsa S
On 07/16/2014 06:43 PM, Viresh Kumar wrote:
On 16 July 2014 16:46, Srivatsa S. Bhat sriva...@mit.edu wrote:
Short answer: If the sysfs directory has already been created by cpufreq,
then yes, it will remain as it is. However, if the online operation failed
before that, then cpufreq won't know
:-)
Regards,
Srivatsa S. Bhat
So, even if we are sure cpufreq.c is fine, it's 137 other uses spread
across all the other files. I definitely don't want to try and fix those
as part of this patch. Way too risky and hard to get the test coverage
it would need. Even some of the acpi cpufreq drivers seem
I had a hard time reviewing all of this in
one go.
Thank you for taking up this work!
Regards,
Srivatsa S. Bhat
I should also be able to remove get_online_cpus() in the store function and
replace it with just a check for policy-governor_enabled. That should
theoretically reduce some
, which is clearly
wrong.
My guess is that, if we fix that locking, everything will be fine and
you won't hit the bug. Would you like to give that a shot?
Regards,
Srivatsa S. Bhat
if (!policy-cur) {
@@ -1207,6 +1202,11 @@ static int __cpufreq_add_dev(struct device *dev,
struct
