Re: i2c: Make remove callback return void

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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!