Let me try send a v2 and see what you think.
regards,
dan carpenter
Let me try send a v2 and see what you think.
regards,
dan carpenter
On Tue, Sep 05, 2017 at 05:02:55PM -0400, Brian Masney wrote:
> On Tue, Sep 05, 2017 at 05:58:54PM +0300, Dan Carpenter wrote:
> > On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote:
> > > On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> > > > On Mon, 21 Aug 2017
On Tue, Sep 05, 2017 at 05:02:55PM -0400, Brian Masney wrote:
> On Tue, Sep 05, 2017 at 05:58:54PM +0300, Dan Carpenter wrote:
> > On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote:
> > > On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> > > > On Mon, 21 Aug 2017
On Tue, Sep 05, 2017 at 05:58:54PM +0300, Dan Carpenter wrote:
> On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote:
> > On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> > > On Mon, 21 Aug 2017 13:11:03 +0300
> > > Dan Carpenter wrote:
> > >
On Tue, Sep 05, 2017 at 05:58:54PM +0300, Dan Carpenter wrote:
> On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote:
> > On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> > > On Mon, 21 Aug 2017 13:11:03 +0300
> > > Dan Carpenter wrote:
> > >
> > > > The second part
On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote:
> On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> > On Mon, 21 Aug 2017 13:11:03 +0300
> > Dan Carpenter wrote:
> >
> > > The second part of this patch is probably the most interesting.
On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote:
> On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> > On Mon, 21 Aug 2017 13:11:03 +0300
> > Dan Carpenter wrote:
> >
> > > The second part of this patch is probably the most interesting. We
> > > use
On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> On Mon, 21 Aug 2017 13:11:03 +0300
> Dan Carpenter wrote:
>
> > The second part of this patch is probably the most interesting. We
> > use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> On Mon, 21 Aug 2017 13:11:03 +0300
> Dan Carpenter wrote:
>
> > The second part of this patch is probably the most interesting. We
> > use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
> >
On Mon, 21 Aug 2017 13:11:03 +0300
Dan Carpenter wrote:
> The second part of this patch is probably the most interesting. We
> use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
> "TSL2X7X_MAX_LUX_TABLE_SIZE". It creates a static checker warning that
>
On Mon, 21 Aug 2017 13:11:03 +0300
Dan Carpenter wrote:
> The second part of this patch is probably the most interesting. We
> use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
> "TSL2X7X_MAX_LUX_TABLE_SIZE". It creates a static checker warning that
> we are going of of bounds,
The second part of this patch is probably the most interesting. We
use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
"TSL2X7X_MAX_LUX_TABLE_SIZE". It creates a static checker warning that
we are going of of bounds, but in real life we always hit the break
statement on the last
The second part of this patch is probably the most interesting. We
use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
"TSL2X7X_MAX_LUX_TABLE_SIZE". It creates a static checker warning that
we are going of of bounds, but in real life we always hit the break
statement on the last
14 matches
Mail list logo