On Wed, Sep 17, 2014 at 01:57:33PM +0200, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 12:34 PM, Henrique de Moraes Holschuh
> wrote:
> > On Tue, 16 Sep 2014, Darren Hart wrote:
> >> - When reading and writing sysfs device attribute files, avoid dependency
> >> on specific error codes wherever
On Wed, Sep 17, 2014 at 12:34 PM, Henrique de Moraes Holschuh
wrote:
> On Tue, 16 Sep 2014, Darren Hart wrote:
>> - When reading and writing sysfs device attribute files, avoid dependency
>> on specific error codes wherever possible. This minimizes coupling to
>> the error handling
On Tue, 16 Sep 2014, Darren Hart wrote:
> - When reading and writing sysfs device attribute files, avoid dependency
> on specific error codes wherever possible. This minimizes coupling to
> the error handling implemementation within the kernel.
>
> In general, failures to read or write
On Tue, 16 Sep 2014, Darren Hart wrote:
- When reading and writing sysfs device attribute files, avoid dependency
on specific error codes wherever possible. This minimizes coupling to
the error handling implemementation within the kernel.
In general, failures to read or write sysfs
On Wed, Sep 17, 2014 at 12:34 PM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
On Tue, 16 Sep 2014, Darren Hart wrote:
- When reading and writing sysfs device attribute files, avoid dependency
on specific error codes wherever possible. This minimizes coupling to
the error handling
On Wed, Sep 17, 2014 at 01:57:33PM +0200, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 12:34 PM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
On Tue, 16 Sep 2014, Darren Hart wrote:
- When reading and writing sysfs device attribute files, avoid dependency
on specific error codes
On Tue, Sep 16, 2014 at 11:10:01PM +0200, Frans Klaver wrote:
> On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
> > On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
> > > On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver
> > > wrote:
> > > > On Mon, Sep 15, 2014 at
On Tue, Sep 16, 2014 at 11:40:37PM +0200, Frans Klaver wrote:
> On Tue, Sep 16, 2014 at 02:27:15PM -0700, Darren Hart wrote:
> >
> > - When reading and writing sysfs device attribute files, avoid dependency
> > on specific error codes wherever possible. This minimizes coupling to
> > the
On Tue, Sep 16, 2014 at 02:27:15PM -0700, Darren Hart wrote:
>
> - When reading and writing sysfs device attribute files, avoid dependency
> on specific error codes wherever possible. This minimizes coupling to
> the error handling implemementation within the kernel.
>
> In general,
On Tue, Sep 16, 2014 at 02:27:15PM -0700, Darren Hart wrote:
> On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
> > On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
> > > On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver
> > > wrote:
> > > > On Mon, Sep 15, 2014 at
On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
> On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
> > On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver
> > wrote:
> > > On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
> > >> On Mon, Sep 15, 2014 at
On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
> On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
> > On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver
> > wrote:
> > > On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
> > >> On Mon, Sep 15, 2014 at
On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
> On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver wrote:
> > On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
> >> On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
> >> >
> >> > This patch is fine as is.
On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver wrote:
> On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
>> On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
>> >
>> > This patch is fine as is. However, Greg has supported propogating the
>> > error code
>> > through
On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver franskla...@gmail.com wrote:
On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
This patch is fine as is. However, Greg has supported propogating the
error code
On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver franskla...@gmail.com wrote:
On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
This patch is fine
On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver franskla...@gmail.com
wrote:
On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
On Mon, Sep 15,
On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver franskla...@gmail.com
wrote:
On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
On Mon, Sep 15,
On Tue, Sep 16, 2014 at 02:27:15PM -0700, Darren Hart wrote:
On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver franskla...@gmail.com
wrote:
On Mon, Sep 15, 2014 at
On Tue, Sep 16, 2014 at 02:27:15PM -0700, Darren Hart wrote:
- When reading and writing sysfs device attribute files, avoid dependency
on specific error codes wherever possible. This minimizes coupling to
the error handling implemementation within the kernel.
In general, failures to
On Tue, Sep 16, 2014 at 11:40:37PM +0200, Frans Klaver wrote:
On Tue, Sep 16, 2014 at 02:27:15PM -0700, Darren Hart wrote:
- When reading and writing sysfs device attribute files, avoid dependency
on specific error codes wherever possible. This minimizes coupling to
the error
On Tue, Sep 16, 2014 at 11:10:01PM +0200, Frans Klaver wrote:
On Tue, Sep 16, 2014 at 01:52:47PM -0700, Darren Hart wrote:
On Tue, Sep 16, 2014 at 01:54:25PM +0200, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 11:55 PM, Frans Klaver franskla...@gmail.com
wrote:
On Mon, Sep 15, 2014 at
On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
> > On Sat, Sep 13, 2014 at 01:06:49AM +0200, Frans Klaver wrote:
> > > In get_cpufv the return value of get_acpi is stored in the cpufv struct.
> > > Right before
On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
> On Sat, Sep 13, 2014 at 01:06:49AM +0200, Frans Klaver wrote:
> > In get_cpufv the return value of get_acpi is stored in the cpufv struct.
> > Right before this value is checked for errors, it is and'ed with 0xff.
> > This means c->cur
On Sat, Sep 13, 2014 at 01:06:49AM +0200, Frans Klaver wrote:
> In get_cpufv the return value of get_acpi is stored in the cpufv struct.
> Right before this value is checked for errors, it is and'ed with 0xff.
> This means c->cur can never be less than zero. Besides that, the actual
> error value
On Sat, Sep 13, 2014 at 01:06:49AM +0200, Frans Klaver wrote:
In get_cpufv the return value of get_acpi is stored in the cpufv struct.
Right before this value is checked for errors, it is and'ed with 0xff.
This means c-cur can never be less than zero. Besides that, the actual
error value is
On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
On Sat, Sep 13, 2014 at 01:06:49AM +0200, Frans Klaver wrote:
In get_cpufv the return value of get_acpi is stored in the cpufv struct.
Right before this value is checked for errors, it is and'ed with 0xff.
This means c-cur can
On Mon, Sep 15, 2014 at 02:51:25PM -0700, Greg Kroah-Hartman wrote:
On Mon, Sep 15, 2014 at 02:49:02PM -0700, Darren Hart wrote:
On Sat, Sep 13, 2014 at 01:06:49AM +0200, Frans Klaver wrote:
In get_cpufv the return value of get_acpi is stored in the cpufv struct.
Right before this value
In get_cpufv the return value of get_acpi is stored in the cpufv struct.
Right before this value is checked for errors, it is and'ed with 0xff.
This means c->cur can never be less than zero. Besides that, the actual
error value is ignored.
c->num is also and'ed with 0xff, which means we can
In get_cpufv the return value of get_acpi is stored in the cpufv struct.
Right before this value is checked for errors, it is and'ed with 0xff.
This means c-cur can never be less than zero. Besides that, the actual
error value is ignored.
c-num is also and'ed with 0xff, which means we can ignore
30 matches
Mail list logo