drivers: remove all i2c_set_clientdata(client, NULL)
in [Kernel]
|
Prev: perf, x86: Segregate PMU workaraunds into x86_pmu_quirk_ops structure
Next: [PATCH] netfilter: xtables: stackptr should be percpu
From: Mark Brown on 31 May 2010 09:10 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(a)pengutronix.de> Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 31 May 2010 13:10 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(a)pengutronix.de> > Cc: Jean Delvare <khali(a)linux-fr.org> Acked-by: Greg Kroah-Hartman <gregkh(a)suse.de> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 31 May 2010 15:10 Hi Wolfram, 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(a)pengutronix.de> > Cc: Jean Delvare <khali(a)linux-fr.org> > --- > > 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. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jean Delvare on 31 May 2010 17:00 Hi Dmitry, On Mon, 31 May 2010 12:09:12 -0700, Dmitry Torokhov wrote: > 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. If I take the patch in my i2c tree, the aim is to merge it upstream immediately, so merge issues won't exist. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Richard Purdie on 31 May 2010 18:00
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(a)pengutronix.de> > > Cc: Jean Delvare <khali(a)linux-fr.org> > > --- > > > > 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? Acked-by: Richard Purdie <rpurdie(a)linux.intel.com> Cheers, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |