[i2c] [patch/rfc 2.6.26-rc5] i2c: schedule legacy gpio driver removal

[David Brownell]

Just sending this as an RFC ... clearly it shouldn't merge until
the GPIO_SYSFS code merges, which I'm assuming is 2.6.27.  And
presumably Jean will want to be the "who removes this"?

I think the only other blocking issue would be a way to configure
such new-style drivers from sysfs, primarily for one-off hardware
hacking usage (in at least this case).  Teaching the two new-style
drivers to use dynamic GPIO number allocation when there's no
platform_data is trivial, and not otherwise desirable.

- Dave


=========== CUT HERE
--- a/Documentation/feature-removal-schedule.txt	2008-06-11 12:00:20.000000000 -0700
+++ b/Documentation/feature-removal-schedule.txt	2008-06-11 13:10:44.000000000 -0700
@@ -312,3 +312,21 @@ When:	2.6.26
 Why:	Implementation became generic; users should now include
 	linux/semaphore.h instead.
 Who:	Matthew Wilcox <willy at linux.intel.com>
+
+---------------------------
+
+What:	drivers/i2c/chips/{pca9539,pcf8574,pcf8575}.c
+When:	January 2010
+Why:	replaced by gpiolib and GPIO_SYSFS with
+	drivers/gpio/{pca953x,pcf857x}.c
+
+	The gpiolib I2C adapter drivers support more chips and moved
+	away from legacy driver binding.  From the embedded systems
+	perspective, they provide a critical capability missing in
+	those now-obsoleted drivers:  GPIOs are now accessible to
+	in-kernel code for common uses like LED control, switching
+	power domains, and chip configuration.
+
+	With GPIO_SYSFS the userspace interface is a bit different,
+	but is more generic and is available for use with all GPIO
+	controllers.