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!
