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

[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-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+
+---------------------------
+
+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.

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

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

[Jean Delvare]

Hi David,

On Wed, 11 Jun 2008 13:17:20 -0700, David Brownell wrote:
> 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.

Certainly.

> And presumably Jean will want to be the "who removes this"?

Not necessarily.

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

This is the problem. Until there is a way to instantiate new-style
drivers from user-space, we just can't remove the deprecated drivers.
Even tagging it as deprecated is dishonest to some extent. So I see no
point in adding these drivers to the feature removal list for now. We
can do that later, when we really offer an alternative with the same
features.

You shouldn't fear that we forget to remove these drivers. They are the
dust in my eye, I can't forget them.

>                                       Teaching the two new-style
> drivers to use dynamic GPIO number allocation when there's no
> platform_data is trivial,

Good to know...

>                           and not otherwise desirable.

I'm confused now.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

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

[David Brownell]

On Thursday 12 June 2008, Jean Delvare wrote:
> > 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).
> 
> This is the problem. Until there is a way to instantiate new-style
> drivers from user-space, we just can't remove the deprecated drivers.
> Even tagging it as deprecated is dishonest to some extent.

Not really; anyone who *can* use the newer stuff should do so.
If they can't, the older stuff is still there.


> So I see no 
> point in adding these drivers to the feature removal list for now. We
> can do that later, when we really offer an alternative with the same
> features.
> 
> You shouldn't fear that we forget to remove these drivers. They are the
> dust in my eye, I can't forget them.

OK.  :)

 
> >                                       Teaching the two new-style
> > drivers to use dynamic GPIO number allocation when there's no
> > platform_data is trivial,
> 
> Good to know...
> 
> >                           and not otherwise desirable.
> 
> I'm confused now.

The GPIOs can't really be used in-kernel without platform data.


_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c