Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-03 Thread Viresh Kumar
On 03-02-16, 11:05, Juri Lelli wrote: > It should be easy to rebase that set (or a part of it) on top of your > and/or Rafael changes. I realize that there are multiple sets of changes > under discussion; so, please tell me how do you, and Rafael, want to > proceed about this. Yeah, please wait

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-03 Thread Juri Lelli
On 03/02/16 11:35, Viresh Kumar wrote: > On 02-02-16, 16:49, Juri Lelli wrote: > > There are still paths where we call __cpufreq_governor() without holding > > policy->rwsem, but those should be fixed with my cleanups (that I intend > > to refresh and post soon). So, I'm not sure we can safely

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-03 Thread Viresh Kumar
On 03-02-16, 11:05, Juri Lelli wrote: > It should be easy to rebase that set (or a part of it) on top of your > and/or Rafael changes. I realize that there are multiple sets of changes > under discussion; so, please tell me how do you, and Rafael, want to > proceed about this. Yeah, please wait

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-03 Thread Juri Lelli
On 03/02/16 11:35, Viresh Kumar wrote: > On 02-02-16, 16:49, Juri Lelli wrote: > > There are still paths where we call __cpufreq_governor() without holding > > policy->rwsem, but those should be fixed with my cleanups (that I intend > > to refresh and post soon). So, I'm not sure we can safely

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Viresh Kumar
On 02-02-16, 16:49, Juri Lelli wrote: > There are still paths where we call __cpufreq_governor() without holding > policy->rwsem, but those should be fixed with my cleanups (that I intend > to refresh and post soon). So, I'm not sure we can safely remove this > yet. No, we can't.. Though I

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Rafael J. Wysocki
On Tue, Feb 2, 2016 at 11:57 AM, Viresh Kumar wrote: > Invalid state-transitions is verified by governor core now What about the governors that don't use cpufreq_governor_dbs()? > and there is no need to replicate that in cpufreq core. Also we don't drop > policy->rwsem anymore, which makes

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Juri Lelli
Hi Viresh, On 02/02/16 16:27, Viresh Kumar wrote: > Invalid state-transitions is verified by governor core now and there is > no need to replicate that in cpufreq core. Also we don't drop > policy->rwsem anymore, which makes rest of the races go away. There are still paths where we call

[PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Viresh Kumar
Invalid state-transitions is verified by governor core now and there is no need to replicate that in cpufreq core. Also we don't drop policy->rwsem anymore, which makes rest of the races go away. Simplify code a bit now. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 24

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Rafael J. Wysocki
On Tue, Feb 2, 2016 at 11:57 AM, Viresh Kumar wrote: > Invalid state-transitions is verified by governor core now What about the governors that don't use cpufreq_governor_dbs()? > and there is no need to replicate that in cpufreq core. Also we don't drop > policy->rwsem

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Viresh Kumar
On 02-02-16, 16:49, Juri Lelli wrote: > There are still paths where we call __cpufreq_governor() without holding > policy->rwsem, but those should be fixed with my cleanups (that I intend > to refresh and post soon). So, I'm not sure we can safely remove this > yet. No, we can't.. Though I

Re: [PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Juri Lelli
Hi Viresh, On 02/02/16 16:27, Viresh Kumar wrote: > Invalid state-transitions is verified by governor core now and there is > no need to replicate that in cpufreq core. Also we don't drop > policy->rwsem anymore, which makes rest of the races go away. There are still paths where we call

[PATCH 5/5] cpufreq: Get rid of ->governor_enabled and its lock

2016-02-02 Thread Viresh Kumar
Invalid state-transitions is verified by governor core now and there is no need to replicate that in cpufreq core. Also we don't drop policy->rwsem anymore, which makes rest of the races go away. Simplify code a bit now. Signed-off-by: Viresh Kumar ---