linux-kernel - Re: [RESEND PATCH] drivers/iio/gyro/mpu3050-core.c: This patch fix the following checkpatch warning.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190422104523.4bfca4ad@archlinux>
Date:   Mon, 22 Apr 2019 10:45:23 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Mohan Kumar <mohankumar718@...il.com>,
        Hartmut Knaack <knaack.h@....de>, linux-iio@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH] drivers/iio/gyro/mpu3050-core.c: This patch fix
 the following checkpatch warning.

On Tue, 16 Apr 2019 13:50:18 +0200
Linus Walleij <linus.walleij@...aro.org> wrote:

> On Sun, Apr 14, 2019 at 5:53 PM Mohan Kumar <mohankumar718@...il.com> wrote:
> 
> > As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for
> > up to 20ms. so use usleep_range.
> >
> > Signed-off-by: Mohan Kumar <mohankumar718@...il.com>  
> 
> All right, should work as fine.
> Acked-by: Linus Walleij <linus.walleij@...aro.org>
Thanks and applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Whilst we are here, there is a 'false' warning that we should clear up at
somepoint (from sparse)

CHECK   drivers/iio/gyro/mpu3050-core.c
drivers/iio/gyro/mpu3050-core.c:544:48: warning: incorrect type in assignment (different base types)
drivers/iio/gyro/mpu3050-core.c:544:48:    expected restricted __be16 <noident>
drivers/iio/gyro/mpu3050-core.c:544:48:    got int

Line in question is setting the __be16 value to 0xAAAA where endian choice has
no effect.  I'll send out the trivial 'fix' in a minute.  Give the compiler
can sort it out at build time it should make no actual difference.

Usual arguments apply for why we bother to suppress 'false' build warnings
like this...

Anyhow patch shortly.

Jonathan



> 
> Yours,
> Linus Walleij