On 18 June 2014 20:09, Aaron Plattner wrote:
> I assume you meant "return -ENODEV"?
Yeah, sorry :)
>> down_write(&policy->rwsem);
>>
>> @@ -2279,10 +2277,10 @@ int cpufreq_update_policy(unsigned int cpu)
>>
>> ret = cpufreq_set_policy(policy, &new_policy);
>>
>> +no_policy:
>
>
On 06/18/2014 12:40 AM, Viresh Kumar wrote:
On 18 June 2014 05:42, Aaron Plattner wrote:
Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if
cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy'
label, which exits without unlocking any of the locks
On 18 June 2014 05:42, Aaron Plattner wrote:
> Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if
> cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy'
> label, which exits without unlocking any of the locks the function acquired
> earlier. This c
Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if
cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy'
label, which exits without unlocking any of the locks the function acquired
earlier. This causes later calls into cpufreq to hang.
Fix this by c
4 matches
Mail list logo