On Mon, May 31, 2010 at 10:48:32PM +0100, Richard Purdie wrote: > On Mon, 2010-05-31 at 12:09 -0700, Dmitry Torokhov wrote: > > On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: > > > I2C-drivers can use the clientdata-pointer to point to private data. As I2C > > > devices are not really unregistered, but merely detached from their driver, it > > > used to be the drivers obligation to clear this pointer during remove() or a > > > failed probe(). As a couple of drivers forgot to do this, it was agreed that it > > > was cleaner if the i2c-core does this clearance when appropriate, as there is > > > no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. > > > This feature was added to the core with commit > > > e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. > > > > > > As there is no need anymore to clear the clientdata-pointer, remove all current > > > occurrences in the drivers to simplify the code and prevent confusion. > > > > > > Signed-off-by: Wolfram Sang <w.sang@xxxxxxxxxxxxxx> > > > Cc: Jean Delvare <khali@xxxxxxxxxxxx> > > > --- > > > > > > Some more notes: > > > > > > I waited for rc1 as I knew there were some drivers/patches coming along which > > > needed to be processed, too. > > > > > > I'd suggest that this goes via the i2c-tree, so we get rid of all occurences at > > > once. > > > > > > > Frankly I'd prefer taking input stuff through my tree with the goal of > > .36 merge window just to minimize potential merge issues. This is a > > simple cleanup patch that has no dependencies, so there is little gain > > from doing it all in one go. > > How about asking Linus to take this one now, then its done and we can > all move on rather than queuing up problems for the next merge window? > That should work. Acked-by: Dmitry Torokhov <dtor@xxxxxxx> > Acked-by: Richard Purdie <rpurdie@xxxxxxxxxxxxxxx> > -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html