[stable:linux-4.9.y 66/1284] drivers/iio/magnetometer/ak8974.c:511:40: sparse: sparse: incorrect type in argument 2 (different base types)
1:26 a.m.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
head: 5d55c2adbefeb2d49d16891ed8ca8d03789fd31b
commit: 980eaca9a409208439c84f7860202d61e31d225f [66/1284] iio:magnetometer:ak8974: Fix
alignment and data leak issues
config: nios2-randconfig-s031-20201209 (attached as .config)
compiler: nios2-linux-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-179-ga00755aa-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/c...
git remote add stable
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch --no-tags stable linux-4.9.y
git checkout 980eaca9a409208439c84f7860202d61e31d225f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-7.5.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=nios2
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
"sparse warnings: (new ones prefixed by >>)"
drivers/iio/magnetometer/ak8974.c:408:16: sparse: sparse: cast to restricted __le16
drivers/iio/magnetometer/ak8974.c:485:29: sparse: sparse: cast to restricted __le16
> drivers/iio/magnetometer/ak8974.c:511:40: sparse: sparse:
incorrect type in argument 2 (different base types) @@ expected signed short
[usertype] *result @@ got restricted __le16 * @@
drivers/iio/magnetometer/ak8974.c:511:40: sparse: expected signed short [usertype]
*result
drivers/iio/magnetometer/ak8974.c:511:40: sparse: got restricted __le16 *
vim +511 drivers/iio/magnetometer/ak8974.c
497
498 static void ak8974_fill_buffer(struct iio_dev *indio_dev)
499 {
500 struct ak8974 *ak8974 = iio_priv(indio_dev);
501 int ret;
502
503 pm_runtime_get_sync(&ak8974->i2c->dev);
504 mutex_lock(&ak8974->lock);
505
506 ret = ak8974_trigmeas(ak8974);
507 if (ret) {
508 dev_err(&ak8974->i2c->dev, "error triggering measure\n");
509 goto out_unlock;
510 }
511 ret = ak8974_getresult(ak8974, ak8974->scan.channels);
512 if (ret) {
513 dev_err(&ak8974->i2c->dev, "error getting measures\n");
514 goto out_unlock;
515 }
516
517 iio_push_to_buffers_with_timestamp(indio_dev, &ak8974->scan,
518 iio_get_time_ns(indio_dev));
519
520 out_unlock:
521 mutex_unlock(&ak8974->lock);
522 pm_runtime_mark_last_busy(&ak8974->i2c->dev);
523 pm_runtime_put_autosuspend(&ak8974->i2c->dev);
524 }
525
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
1:21 a.m.
On Fri, Dec 11, 2020 at 3:27 PM kernel test robot <lkp(a)intel.com> wrote:
"sparse warnings: (new ones prefixed by >>)"
drivers/iio/magnetometer/ak8974.c:408:16: sparse: sparse: cast to restricted __le16
drivers/iio/magnetometer/ak8974.c:485:29: sparse: sparse: cast to restricted __le16
>> drivers/iio/magnetometer/ak8974.c:511:40: sparse: sparse: incorrect type in
argument 2 (different base types) @@ expected signed short [usertype] *result @@
got restricted __le16 * @@
drivers/iio/magnetometer/ak8974.c:511:40: sparse: expected signed short [usertype]
*result
drivers/iio/magnetometer/ak8974.c:511:40: sparse: got restricted __le16 *
I don't understand this, is sparse warning about implicit casting __le16
to signed short or the other way around?
It seems to me to reasonable to allow anyway, I don't even see how
we could avoid that except using explicit casts.
Yours,
Linus Walleij
8:07 p.m.
On Sat, 12 Dec 2020 15:21:10 +0100
Linus Walleij <linus.walleij(a)linaro.org> wrote:
On Fri, Dec 11, 2020 at 3:27 PM kernel test robot
<lkp(a)intel.com> wrote:
> "sparse warnings: (new ones prefixed by >>)"
> drivers/iio/magnetometer/ak8974.c:408:16: sparse: sparse: cast to restricted
__le16
> drivers/iio/magnetometer/ak8974.c:485:29: sparse: sparse: cast to restricted
__le16
> >> drivers/iio/magnetometer/ak8974.c:511:40: sparse: sparse: incorrect type in
argument 2 (different base types) @@ expected signed short [usertype] *result @@
got restricted __le16 * @@
> drivers/iio/magnetometer/ak8974.c:511:40: sparse: expected signed short
[usertype] *result
> drivers/iio/magnetometer/ak8974.c:511:40: sparse: got restricted __le16 *
I don't understand this, is sparse warning about implicit casting __le16
to signed short or the other way around?
It seems to me to reasonable to allow anyway, I don't even see how
we could avoid that except using explicit casts.
Looks to me like we didn't bother backporting a tidy up of the endian
types in here to 4.9. That changed the argument types to reflect that they
were arrays of __le16.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
Personally I'm not that bothered about leaving this in place.
I don't think its an actual bug after all.
Jonathan
Yours,
Linus Walleij
8:17 p.m.
On Mon, Dec 14, 2020 at 09:07:35AM +0000, Jonathan Cameron wrote:
On Sat, 12 Dec 2020 15:21:10 +0100
Linus Walleij <linus.walleij(a)linaro.org> wrote:
> On Fri, Dec 11, 2020 at 3:27 PM kernel test robot <lkp(a)intel.com> wrote:
>
> > "sparse warnings: (new ones prefixed by >>)"
> > drivers/iio/magnetometer/ak8974.c:408:16: sparse: sparse: cast to restricted
__le16
> > drivers/iio/magnetometer/ak8974.c:485:29: sparse: sparse: cast to restricted
__le16
> > >> drivers/iio/magnetometer/ak8974.c:511:40: sparse: sparse: incorrect
type in argument 2 (different base types) @@ expected signed short [usertype] *result
@@ got restricted __le16 * @@
> > drivers/iio/magnetometer/ak8974.c:511:40: sparse: expected signed short
[usertype] *result
> > drivers/iio/magnetometer/ak8974.c:511:40: sparse: got restricted __le16
*
>
> I don't understand this, is sparse warning about implicit casting __le16
> to signed short or the other way around?
>
> It seems to me to reasonable to allow anyway, I don't even see how
> we could avoid that except using explicit casts.
Looks to me like we didn't bother backporting a tidy up of the endian
types in here to 4.9. That changed the argument types to reflect that they
were arrays of __le16.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
Personally I'm not that bothered about leaving this in place.
I don't think its an actual bug after all.
Agreed, dealing with old sparse issues on the stable kernel trees is not
a thing, I don't know why the lkp bot keeps emailing about them :(
8:39 p.m.
On 12/14/20 5:17 PM, Greg Kroah-Hartman wrote:
On Mon, Dec 14, 2020 at 09:07:35AM +0000, Jonathan Cameron wrote:
> On Sat, 12 Dec 2020 15:21:10 +0100
> Linus Walleij <linus.walleij(a)linaro.org> wrote:
>
>> On Fri, Dec 11, 2020 at 3:27 PM kernel test robot <lkp(a)intel.com> wrote:
>>
>>> "sparse warnings: (new ones prefixed by >>)"
>>> drivers/iio/magnetometer/ak8974.c:408:16: sparse: sparse: cast to
restricted __le16
>>> drivers/iio/magnetometer/ak8974.c:485:29: sparse: sparse: cast to
restricted __le16
>>>>> drivers/iio/magnetometer/ak8974.c:511:40: sparse: sparse: incorrect
type in argument 2 (different base types) @@ expected signed short [usertype] *result
@@ got restricted __le16 * @@
>>> drivers/iio/magnetometer/ak8974.c:511:40: sparse: expected signed
short [usertype] *result
>>> drivers/iio/magnetometer/ak8974.c:511:40: sparse: got restricted
__le16 *
>> I don't understand this, is sparse warning about implicit casting __le16
>> to signed short or the other way around?
>>
>> It seems to me to reasonable to allow anyway, I don't even see how
>> we could avoid that except using explicit casts.
> Looks to me like we didn't bother backporting a tidy up of the endian
> types in here to 4.9. That changed the argument types to reflect that they
> were arrays of __le16.
>
>
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
>
> Personally I'm not that bothered about leaving this in place.
> I don't think its an actual bug after all.
Agreed, dealing with old sparse issues on the stable kernel trees is not
a thing, I don't know why the lkp bot keeps emailing about them :(
Hi Greg,
Sorry about that, we'll stop reporting these static analysis issues on
stable kernel trees.
Best Regards,
Rong Chen
644
days inactive
648
days old
4 comments
5 participants
participants (5)
-
Greg Kroah-Hartman -
Jonathan Cameron -
kernel test robot -
Linus Walleij -
Rong Chen