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 :(