On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <[email protected]> wrote:
>
>
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on wsa/i2c/for-next]
> [also build test ERROR on linus/master v5.19-rc7 next-20220718]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> i2c/for-next
> config: hexagon-randconfig-r026-20220718
> (https://download.01.org/0day-ci/archive/20220719/[email protected]/config)
> compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
> d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review
> Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> git checkout 9732240c23a365c0590f05ce83196869235a2ea7
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <[email protected]>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> st->send = i2c_master_send;
> ^ ~~~~~~~~~~~~~~~
> >> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> st->recv = i2c_master_recv;
> ^ ~~~~~~~~~~~~~~~
> 2 errors generated.
Wolfram and Jonathan,
Writing a patch to fix the new warnings generated by my I2C patch is
simple enough, but I'd like some help coordinating getting both
patches landed. Should I wait for the I2C patch to land in "for-next"
before sending the IIO fix, or would it be preferred to send the IIO
fix right now so that both patches can be reviewed simultaneously?
On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <[email protected]> wrote:
>
> On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <[email protected]> wrote:
> >
> >
> > Hi Jason,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on wsa/i2c/for-next]
> > [also build test ERROR on linus/master v5.19-rc7 next-20220718]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >
> > url:
> > https://github.com/intel-lab-lkp/linux/commits/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> > i2c/for-next
> > config: hexagon-randconfig-r026-20220718
> > (https://download.01.org/0day-ci/archive/20220719/[email protected]/config)
> > compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
> > d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
> > reproduce (this is a W=1 build):
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> > -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > #
> > https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
> > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > git fetch --no-tags linux-review
> > Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> > git checkout 9732240c23a365c0590f05ce83196869235a2ea7
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> > O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <[email protected]>
> >
> > All errors (new ones prefixed by >>):
> >
> > >> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> > st->send = i2c_master_send;
> > ^ ~~~~~~~~~~~~~~~
> > >> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> > st->recv = i2c_master_recv;
> > ^ ~~~~~~~~~~~~~~~
> > 2 errors generated.
>
> Wolfram and Jonathan,
>
> Writing a patch to fix the new warnings generated by my I2C patch is
> simple enough, but I'd like some help coordinating getting both
> patches landed. Should I wait for the I2C patch to land in "for-next"
> before sending the IIO fix, or would it be preferred to send the IIO
> fix right now so that both patches can be reviewed simultaneously?
It's been pretty quiet, so asking again for any thoughts on how to
best address this tangle...
Jason
On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <[email protected]> wrote:
> On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <[email protected]> wrote:
> > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <[email protected]> wrote:
> > Writing a patch to fix the new warnings generated by my I2C patch is
> > simple enough, but I'd like some help coordinating getting both
> > patches landed. Should I wait for the I2C patch to land in "for-next"
> > before sending the IIO fix, or would it be preferred to send the IIO
> > fix right now so that both patches can be reviewed simultaneously?
>
> It's been pretty quiet, so asking again for any thoughts on how to
> best address this tangle...
The rule of thumb is not to introduce an additional warning or compile error.
I haven't looked deeply into this case, but it smells to me as if you need a new
version of your initial patch that includes a fix to IIO.
--
With Best Regards,
Andy Shevchenko
On Thu, Jul 28, 2022 at 1:48 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <[email protected]> wrote:
> > On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <[email protected]> wrote:
> > > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <[email protected]> wrote:
>
> > > Writing a patch to fix the new warnings generated by my I2C patch is
> > > simple enough, but I'd like some help coordinating getting both
> > > patches landed. Should I wait for the I2C patch to land in "for-next"
> > > before sending the IIO fix, or would it be preferred to send the IIO
> > > fix right now so that both patches can be reviewed simultaneously?
> >
> > It's been pretty quiet, so asking again for any thoughts on how to
> > best address this tangle...
>
> The rule of thumb is not to introduce an additional warning or compile error.
> I haven't looked deeply into this case, but it smells to me as if you need a new
> version of your initial patch that includes a fix to IIO.
>
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks! Since the patch would touch both IIO and I2C I assume I would
submit it to both mailinglists. And that whichever maintainer gets to
it first would just give their Reviewed-by (if all looks good) and the
second applies the Signed-off-by and handles the merge?
I'll work on the updated combined patch...
Jason
On Thu, 28 Jul 2022 15:48:59 -0700
Jason Gerecke <[email protected]> wrote:
> On Thu, Jul 28, 2022 at 1:48 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <[email protected]> wrote:
> > > On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <[email protected]> wrote:
> > > > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <[email protected]> wrote:
> >
> > > > Writing a patch to fix the new warnings generated by my I2C patch is
> > > > simple enough, but I'd like some help coordinating getting both
> > > > patches landed. Should I wait for the I2C patch to land in "for-next"
> > > > before sending the IIO fix, or would it be preferred to send the IIO
> > > > fix right now so that both patches can be reviewed simultaneously?
> > >
> > > It's been pretty quiet, so asking again for any thoughts on how to
> > > best address this tangle...
> >
> > The rule of thumb is not to introduce an additional warning or compile error.
> > I haven't looked deeply into this case, but it smells to me as if you need a new
> > version of your initial patch that includes a fix to IIO.
> >
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> Thanks! Since the patch would touch both IIO and I2C I assume I would
> submit it to both mailinglists. And that whichever maintainer gets to
> it first would just give their Reviewed-by (if all looks good) and the
> second applies the Signed-off-by and handles the merge?
>
> I'll work on the updated combined patch...
I suspect this will be likely to create merge conflicts, so submit it like
that and I'll probably ask Wolfram to do an immutable branch that I can
then pull into IIO. Hence we'll have exactly the same commits (IDs and all)
in both IIO and I2C trees.
Jonathan
>
> Jason