RE: [jic23-iio:testing 6/10] drivers/iio/adc/max14001.c:135:13: warning: result of comparison of constant 18446744073709551615 with expression of type 'typeof (_Generic((mask), char: (unsigned char)0, unsigned char: (unsigned char)0, signed char: (unsi...

["Paller, Kim Seer" <KimSeer.Paller@analog.com>]

> -----Original Message-----
> From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> Sent: Wednesday, June 21, 2023 8:06 PM
> To: Paller, Kim Seer <KimSeer.Paller@analog.com>
> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>; llvm@lists.linux.dev; oe-
> kbuild-all@lists.linux.dev; kernel test robot <lkp@intel.com>
> Subject: Re: [jic23-iio:testing 6/10] drivers/iio/adc/max14001.c:135:13:
> warning: result of comparison of constant 18446744073709551615 with
> expression of type 'typeof (_Generic((mask), char: (unsigned char)0, unsigned
> char: (unsigned char)0, signed char: (unsi...
> 
> [External]
> 
> On Wed, 21 Jun 2023 08:58:47 +0000
> "Paller, Kim Seer" <KimSeer.Paller@analog.com> wrote:
> 
> > > -----Original Message-----
> > > From: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > Sent: Wednesday, June 21, 2023 4:25 PM
> > > To: kernel test robot <lkp@intel.com>
> > > Cc: Paller, Kim Seer <KimSeer.Paller@analog.com>;
> > > llvm@lists.linux.dev; oe- kbuild-all@lists.linux.dev; Jonathan
> > > Cameron <Jonathan.Cameron@huawei.com>
> > > Subject: Re: [jic23-iio:testing 6/10] drivers/iio/adc/max14001.c:135:13:
> > > warning: result of comparison of constant 18446744073709551615 with
> > > expression of type 'typeof (_Generic((mask), char: (unsigned char)0,
> > > unsigned
> > > char: (unsigned char)0, signed char: (unsi...
> > >
> > > [External]
> > >
> > > On Wed, Jun 21, 2023 at 10:19 AM kernel test robot <lkp@intel.com>
> wrote:
> > > >
> > > > tree:
> > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/ker
> > > nel/git/ji
> > > c23/iio.git__;!!A3Ni8CS0y2Y!45o_-MMr4xq4e_9PWpK-sQ_qHBbFbbS7Q2J-
> > > fNmTvSPAQXjYhpLYDteGHSeWEbdIAv364HiQBQy2tXMdnz3oesPJvyDEVg$
> > > testing
> > > > head:   25e201cc6ff270abc062e13ff912292097cb2827
> > > > commit: d3e93b67f934a477c5851d575a2278f07c6242fb [6/10] iio: adc:
> > > > max14001: New driver
> > > > config: x86_64-allyesconfig
> > > > (https://urldefense.com/v3/__https://download.01.org/0day-ci/archi
> > > > ve/2
> > > > 0230621/202306211545.7b6CdqsL-
> > > lkp@intel.com/config__;!!A3Ni8CS0y2Y!45o
> > > > _-MMr4xq4e_9PWpK-sQ_qHBbFbbS7Q2J-
> > > fNmTvSPAQXjYhpLYDteGHSeWEbdIAv364HiQB
> > > > Qy2tXMdnz3oesOgKhx9ZQ$ )
> > > > compiler: clang version 15.0.7
> > > > (https://urldefense.com/v3/__https://github.com/llvm/llvm-project.
> > > > git_
> > > > _;!!A3Ni8CS0y2Y!45o_-MMr4xq4e_9PWpK-sQ_qHBbFbbS7Q2J-
> > > fNmTvSPAQXjYhpLYDt
> > > > eGHSeWEbdIAv364HiQBQy2tXMdnz3oesOx97mL0Q$
> > > > 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a)
> > > > reproduce:
> > > > (https://urldefense.com/v3/__https://download.01.org/0day-ci/archi
> > > > ve/2
> > > > 0230621/202306211545.7b6CdqsL-
> > > lkp@intel.com/reproduce__;!!A3Ni8CS0y2Y!
> > > > 45o_-MMr4xq4e_9PWpK-sQ_qHBbFbbS7Q2J-
> > > fNmTvSPAQXjYhpLYDteGHSeWEbdIAv364H
> > > > iQBQy2tXMdnz3oesODMiAFrg$ )
> > > >
> > > > If you fix the issue in a separate patch/commit (i.e. not just a
> > > > new version of the same patch/commit), kindly add following tags
> > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > | Closes:
> > > > | https://urldefense.com/v3/__https://lore.kernel.org/oe-kbuild-al
> > > > | l/20
> > > > | 2306211545.7b6CdqsL-lkp@intel.com/__;!!A3Ni8CS0y2Y!45o_-
> > > MMr4xq4e_9PW
> > > > | pK-sQ_qHBbFbbS7Q2J-
> > > fNmTvSPAQXjYhpLYDteGHSeWEbdIAv364HiQBQy2tXMdnz3oe
> > > > | sOVGB0hTQ$
> > > >
> > > > All warnings (new ones prefixed by >>):
> > >
> > > Okay, you even haven't compiled your code :-( This should probably
> > > use one of the functions from bitfield.h.
> > > Like u32_encode_bits().
> >
> > I wasn’t able to encounter and trigger this kind of warning in my
> > build. I built and tested the code with rpi4 and linux kernel source tree before
> sending the patch.
> > Perhaps I missed something. I will check and try to resolve this warning.
> 
> Also passed my (admittedly limited these days as 0-day does such a good job)
> local build tests.
> I guess some / most compilers could see it is constant, but a less observant one
> apparently doesn't.
> 
> It's only called from one place, I'd just put the code inline so that the constant
> nature of that variable is explicit.  Or pass in the FIELD_PREP() value rather than
> computing it in the function.
> 
> Send a new version and I'll switch it in for the one in the tree currently.
> 
> However, it looks like that code was meant to do a read modify write cycle and
> doesn't use the value read.  So probably a bug there anyway.

I think I found the problem, the code directly assign a bit without retaining the 
cfg reg default value. There should be a bitwise OR in the operands. This might 
resolve the warning. However, I found it difficult to replicate the build process of 0-day. 
I will send the new version later.

Thanks and best regards,

Kim Seer Paller