remove_clientdata_to_null-branch

remove_clientdata_to_null-branch

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

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

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: remove_clientdata_to_null-branch

[Jean Delvare]

Hi Wolfram,

On Sat, 3 Apr 2010 19:36:46 +0200, Wolfram Sang wrote:
> 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

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.

-- 
Jean Delvare

Re: remove_clientdata_to_null-branch

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

> 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.

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

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: remove_clientdata_to_null-branch

[Jean Delvare]

On Sat, 3 Apr 2010 20:22:07 +0200, Wolfram Sang wrote:
> > 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.
> 
> 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.

> 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.

-- 
Jean Delvare