From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0042317206272943748==" MIME-Version: 1.0 From: Greg Kroah-Hartman To: kbuild-all@lists.01.org Subject: Re: [stable:linux-4.9.y 66/1284] drivers/iio/magnetometer/ak8974.c:511:40: sparse: sparse: incorrect type in argument 2 (different base types) Date: Mon, 14 Dec 2020 10:17:25 +0100 Message-ID: In-Reply-To: <20201214090735.00002bf5@Huawei.com> List-Id: --===============0042317206272943748== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Dec 14, 2020 at 09:07:35AM +0000, Jonathan Cameron wrote: > On Sat, 12 Dec 2020 15:21:10 +0100 > Linus Walleij wrote: > = > > On Fri, Dec 11, 2020 at 3:27 PM kernel test robot wro= te: > > = > > > "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: incorrec= t type in argument 2 (different base types) @@ expected signed short [u= sertype] *result @@ got restricted __le16 * @@ = > > > drivers/iio/magnetometer/ak8974.c:511:40: sparse: expected sig= ned short [usertype] *result > > > drivers/iio/magnetometer/ak8974.c:511:40: sparse: got restrict= ed __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= /drivers/iio/magnetometer/ak8974.c?h=3Dv5.10&id=3D7f709dcda46105f617329630d= 97f5c97cea5b068 > = > 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 :( --===============0042317206272943748==--