remove_clientdata_to_null-branch
Hi,
just wanted to announce that I put up a branch for removing the i2c_set_clientdata(..., NULL)-calls, so you can see what the current status is. It will be rebased, so don't work on it (why would you? :)).
http://git.pengutronix.de/?p=wsa/linux-2.6.git;a=shortlog;h=refs/heads/remove_clientdata_to_null
The main cleaning patch is a single patch scheduled for 2.6.35 as discuessed. I'd like to add another round of review before sending out a patch to this list, probably around -rc4. (Altough I still wonder if we shouldn't wait for 2.6.35-rc1, then we could also catch the calls sitting now in linux-next).
Jean, have you noticed this one for 2.6.34?
http://article.gmane.org/gmane.linux.drivers.i2c/5784
Kind regards,
Wolfram
Signature · 2 lines
Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Wolfram,
Quoted 6 lines · Wolfram Sang
just wanted to announce that I put up a branch for removing the
i2c_set_clientdata(..., NULL)-calls, so you can see what the current status is. It will be rebased, so don't work on it (why would you? :)).http://git.pengutronix.de/?p=wsa/linux-2.6.git;a=shortlog;h=refs/heads/remove_clientdata_to_null
Quoted 8 lines
The main cleaning patch is a single patch scheduled for 2.6.35 as discuessed. I'd like to add another round of review before sending out a patch to this list, probably around -rc4. (Altough I still wonder if we shouldn't wait for 2.6.35-rc1, then we could also catch the calls sitting now in linux-next).
Jean, have you noticed this one for 2.6.34?
I've seen it, but it is something for the power subsystem maintainer (or akpm if there is none) to apply. I did kill drivers/i2c/chips for a reason.
Signature · 1 line
Jean Delvare
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines
I've seen it, but it is something for the power subsystem maintainer (or akpm if there is none) to apply. I did kill
drivers/i2c/chipsfor a reason.
Oops, sorry my failure then. I asked Anton Vorontsov (power-maintainer) if he is fine with going this via the i2c-tree, so it will surely come after the needed modification of the core. That is why he "only" acked it. (I still think this sounds reasonable, the other cleaning-up patch should also go via i2c, right? Or am I missing something?)
Regards,
Wolfram
Signature · 2 lines
Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Wolfram Sang
Quoted 3 lines
I've seen it, but it is something for the power subsystem maintainer (or akpm if there is none) to apply. I did kill
drivers/i2c/chipsfor a reason.Oops, sorry my failure then. I asked Anton Vorontsov (power-maintainer) if he is fine with going this via the i2c-tree, so it will surely come after the needed modification of the core.
Both changes are independent. We all know that setting the driver data back to NULL is cosmetic only, so nothing wrong will happen if we don't. And the ds2782_battery fix is a no-op anyway (the code you're removing did nothing.) Let's not invent patch dependencies where they do not exist.
Quoted 3 lines
That is why he "only" acked it. (I still think
this sounds reasonable, the other cleaning-up patch should also go via i2c, right? Or am I missing something?)
I only pick patches in my i2c tree that touch other drivers if there is a strong dependency between the changes. As this is not the case here, I prefer the patch to go through the power subsystem tree.
Signature · 1 line
Jean Delvare