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
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
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
= fattr->store(policy, buf, count);
> > - else
> > - ret = -EIO;
> > + up_write(>rwsem);
> > + }
> >
> > - up_write(>rwsem);
> > -unlock:
>
> I have no problems with the patch as is, but how are we going t
ve no problems with the patch as is, but how are we going to benefit from
> it
> ?
>
> 'if (fattr->show/store)' is never ever going to fail, unless we have a bug
> here.
Well, having a check that never fails is certainly unuseful.
> So, even we may want to add a WARN_ON() for
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
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
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
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
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
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
---
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.
12 matches
Mail list logo