lkml.org 
[lkml]   [2006]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [-mm patch] struct i2c_algo_pcf_data: remove the mdelay member
Hi Adrian,

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm2:
> >...
> > +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
> >...
> > I2C tree updates
> >...
>
> This patch also removes the only usage of the mdelay member in
> struct i2c_algo_pcf_data, but doesn't remove the struct member itself.
>
> Is seems this patch was also intended?
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h.old 2006-08-27 04:01:35.000000000 +0200
> +++ linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h 2006-08-27 04:01:40.000000000 +0200
> @@ -35,7 +35,6 @@ struct i2c_algo_pcf_data {
>
> /* local settings */
> int udelay;
> - int mdelay;
> int timeout;
> };

I removed mdelay from i2c-elektor thinking that it was using
i2c-algo-bit, I didn't realize it was using a different i2c algorithm.
And I didn't know i2c-algo-pcf also had an unused mdelay.

I will send an updated i2c-algo-bit-kill-mdelay.patch to Greg which
doesn't affect i2c-elektor. Then we can stack a second patch doing the
same for i2c-algo-pcf, which will include your change above, and my
change to i2c-elektor.

I agree it doesn't matter much, in the end we end up removing
everything and it was dead code anyway, but let's still have clean
separate patches doing just one thing at a time.

I just found that i2c-algo-ite has the same unused mdelay member in its
algorithm data structure... But I wouldn't bother cleaning it up, given
that it is planed for removal next month anyway.

Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-27 10:47    [W:0.147 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site