i2c: Make remove callback return void

Hello,

I intend to send a patch that does 


and adapts all users accordingly once 5.20-rc1 (assuming Linus will be
able to count to 20 for 5.x :-) is out. The rationale is that returning
an error code doesn't make a relevant difference. The only effect is
that the i2c core emits a generic error message and still removes the
device.

To make this adaption of drivers easily reviewable, I created quite a
few patches to make all drivers always return zero in their remove
callback---so the adaption just drops "return 0" (or replaces them by
"return").
Most of them are already in Linus's tree, but some others (currently 18
as of next-20220608) are still in next and another bunch wasn't
processed by the respective maintainers yet (in a public way at least;
currently 15).

The tree with my current work-in-progress is available at

	https://git.pengutronix.de/git/ukl/linux i2c-remove-void

I intend to rebase that to the following -rc releases and adapt to
relevant changes there. Currently this tree is successfully build-tested
using allmodconfig on arm64, m68k, powerpc, riscv, s390, sparc64 and
x86_64. The current shortstat is:

	 633 files changed, 732 insertions(+), 1803 deletions(-)

Assuming you agree to this quest, it would be great if you accepted the
change (+ the then maybe still non-accepted driver changes) in the i2c
tree exposing them early after 5.20-rc1 in next. Maybe it will be
sensible to then create a signed tag for these changes to allow other
affected maintainers to pull this change into their trees.

For now this is just a note to let you know in advance of my plans. If
you have concerns or alternative suggestions for the next steps or their
timing, please let me know.

Best regards
Uwe

On Thu, Jun 09, 2022 at 11:10:18AM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> I intend to send a patch that does 
> 
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index fbda5ada2afc..066b541a0d5d 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -273,7 +273,7 @@ struct i2c_driver {
>  
>  	/* Standard driver model interfaces */
>  	int (*probe)(struct i2c_client *client, const struct i2c_device_id *id);
> -	int (*remove)(struct i2c_client *client);
> +	void (*remove)(struct i2c_client *client);
>  
>  	/* New driver model interface to aid the seamless removal of the
>  	 * current probe()'s, more commonly unused than used second parameter.
> 
> and adapts all users accordingly once 5.20-rc1 (assuming Linus will be
> able to count to 20 for 5.x :-) is out. The rationale is that returning
> an error code doesn't make a relevant difference. The only effect is
> that the i2c core emits a generic error message and still removes the
> device.
> 
> To make this adaption of drivers easily reviewable, I created quite a
> few patches to make all drivers always return zero in their remove
> callback---so the adaption just drops "return 0" (or replaces them by
> "return").
> Most of them are already in Linus's tree, but some others (currently 18
> as of next-20220608) are still in next and another bunch wasn't
> processed by the respective maintainers yet (in a public way at least;
> currently 15).
> 
> The tree with my current work-in-progress is available at
> 
> 	https://git.pengutronix.de/git/ukl/linux i2c-remove-void
> 
> I intend to rebase that to the following -rc releases and adapt to
> relevant changes there. Currently this tree is successfully build-tested
> using allmodconfig on arm64, m68k, powerpc, riscv, s390, sparc64 and
> x86_64. The current shortstat is:
> 
> 	 633 files changed, 732 insertions(+), 1803 deletions(-)
> 
> Assuming you agree to this quest, it would be great if you accepted the
> change (+ the then maybe still non-accepted driver changes) in the i2c
> tree exposing them early after 5.20-rc1 in next. Maybe it will be
> sensible to then create a signed tag for these changes to allow other
> affected maintainers to pull this change into their trees.
> 
> For now this is just a note to let you know in advance of my plans. If
> you have concerns or alternative suggestions for the next steps or their
> timing, please let me know.

No objection from me!

Hi UWe,

> Assuming you agree to this quest, it would be great if you accepted the
> change (+ the then maybe still non-accepted driver changes) in the i2c
> tree exposing them early after 5.20-rc1 in next. Maybe it will be
> sensible to then create a signed tag for these changes to allow other
> affected maintainers to pull this change into their trees.

Yes, I can do this. Your proposal makes sense to me.

Thank you for your work!

   Wolfram