diff mbox

[08/14] Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning

Message ID CAK8P3a0nZsqWtFX84FTHmm=aVFevrU5ZATnaLVSA39PZeG=6UQ@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Arnd Bergmann July 14, 2017, 8:17 p.m. UTC 
On Fri, Jul 14, 2017 at 9:24 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> FIFO_MODE is an macro expression with a '<<' operator, which
>> gcc points out could be misread as a '<':
>
> Yeah, no, NAK again.
>
> We don't make the code look worse just because gcc is being a f*cking
> moron about things.
>
> This warning is clearly pure garbage.
>

I looked at this one again and found a better approach, matching the
check that is done a few lines later. Unless you find something wrong
with that one, I'd resubmit it with the fixup below.

      Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Dmitry Torokhov July 14, 2017, 9:40 p.m. UTC | #1 
On Fri, Jul 14, 2017 at 10:17:10PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 14, 2017 at 9:24 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> FIFO_MODE is an macro expression with a '<<' operator, which
> >> gcc points out could be misread as a '<':
> >
> > Yeah, no, NAK again.
> >
> > We don't make the code look worse just because gcc is being a f*cking
> > moron about things.
> >
> > This warning is clearly pure garbage.
> >
> 
> I looked at this one again and found a better approach, matching the
> check that is done a few lines later. Unless you find something wrong
> with that one, I'd resubmit it with the fixup below.
> 
>       Arnd
> 
> --- a/drivers/input/misc/adxl34x.c
> +++ b/drivers/input/misc/adxl34x.c
> @@ -789,21 +789,21 @@ struct adxl34x *adxl34x_probe(struct device *dev, int irq,
>                 __set_bit(pdata->ev_code_ff, input_dev->keybit);
>         }
> 
>         if (pdata->ev_code_act_inactivity)
>                 __set_bit(pdata->ev_code_act_inactivity, input_dev->keybit);
> 
>         ac->int_mask |= ACTIVITY | INACTIVITY;
> 
>         if (pdata->watermark) {
>                 ac->int_mask |= WATERMARK;
> -               if (FIFO_MODE(pdata->fifo_mode) == 0)
> +               if (FIFO_MODE(pdata->fifo_mode) == FIFO_BYPASS)

This is better, not because of GCC, but it makes sense logically; 0 is
not a special value here.

Still, I am not sure that GCC is being that helpful here. Checking
result of shift for 0/non 0 with "!" is very common pattern.

Thanks.
diff mbox

Patch

--- a/drivers/input/misc/adxl34x.c
+++ b/drivers/input/misc/adxl34x.c
@@ -789,21 +789,21 @@  struct adxl34x *adxl34x_probe(struct device *dev, int irq,
                __set_bit(pdata->ev_code_ff, input_dev->keybit);
        }

        if (pdata->ev_code_act_inactivity)
                __set_bit(pdata->ev_code_act_inactivity, input_dev->keybit);

        ac->int_mask |= ACTIVITY | INACTIVITY;

        if (pdata->watermark) {
                ac->int_mask |= WATERMARK;
-               if (FIFO_MODE(pdata->fifo_mode) == 0)
+               if (FIFO_MODE(pdata->fifo_mode) == FIFO_BYPASS)
                        ac->pdata.fifo_mode |= FIFO_STREAM;
        } else {
                ac->int_mask |= DATA_READY;
        }

        if (pdata->tap_axis_control & (TAP_X_EN | TAP_Y_EN | TAP_Z_EN))
                ac->int_mask |= SINGLE_TAP | DOUBLE_TAP;

        if (FIFO_MODE(pdata->fifo_mode) == FIFO_BYPASS)
                ac->fifo_delay = false;