i2c: Make remove callback return void

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux