On 12-02-16, 17:10, Rafael J. Wysocki wrote:
> On Friday, February 12, 2016 09:28:29 PM Viresh Kumar wrote:
> > On 12-02-16, 14:18, Rafael J. Wysocki wrote:
> > > Well, having a check that never fails is certainly unuseful.
> > >
> > > > So, even we may want to add a WARN_ON() for that case instea
On Friday, February 12, 2016 09:28:29 PM Viresh Kumar wrote:
> On 12-02-16, 14:18, Rafael J. Wysocki wrote:
> > Well, having a check that never fails is certainly unuseful.
> >
> > > So, even we may want to add a WARN_ON() for that case instead.
> >
> > I can add WARN_ON()s just fine.
>
> What a
On 12-02-16, 14:18, Rafael J. Wysocki wrote:
> Well, having a check that never fails is certainly unuseful.
>
> > So, even we may want to add a WARN_ON() for that case instead.
>
> I can add WARN_ON()s just fine.
What about dropping the check completely ?
--
viresh
down_write(&policy->rwsem);
> > ret = fattr->store(policy, buf, count);
> > - else
> > - ret = -EIO;
> > + up_write(&policy->rwsem);
> > + }
> >
> > - up_write(&policy->rwsem);
> > -un
On 11-02-16, 02:25, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The show() and store() routines in the cpufreq core don't need to
> acquire all of the locks to check if the struct freq_attr they want
> to use really provides the callbacks they need as expected, so change
> them to avoi
From: Rafael J. Wysocki
The show() and store() routines in the cpufreq core don't need to
acquire all of the locks to check if the struct freq_attr they want
to use really provides the callbacks they need as expected, so change
them to avoid doing that.
Signed-off-by: Rafael J. Wysocki
---
dri
6 matches
Mail list logo
