some overdue I2C driver removal
Subsystems (3)
PATCH 1/1 some overdue I2C driver removal
This patch contains the overdue removal of three I2C drivers.
---
Documentation/feature-removal-schedule.txt | 8 drivers/i2c/busses/Kconfig | 59 ------ drivers/i2c/busses/Makefile | 3 drivers/i2c/busses/i2c-ixp2000.c | 167 ------------------- drivers/i2c/busses/i2c-ixp4xx.c | 178 --------------------- drivers/i2c/busses/scx200_i2c.c | 131 --------------- 6 files changed, 546 deletions(-)
6a8e0e37019c0ffeb0071fae30210baf2c3bdd75
Documentation/feature-removal-schedule.txt +0 -8
@@ -218,14 +218,6 @@ Who: Len Brown <[email protected]> --------------------------- -What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers -When: September 2007 -Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific - I2C-over-GPIO drivers. -Who: Jean Delvare <[email protected]> - ---------------------------- - What: 'time' kernel boot parameter When: January 2008 Why: replaced by 'printk.time=<value>' so that printk timestamps can be
drivers/i2c/busses/Kconfig +0 -59
71 lines not on this page · raw message
drivers/i2c/busses/Makefile +0 -3
@@ -19,8 +19,6 @@ obj-$(CONFIG_I2C_I801) += i2c-i801.o obj-$(CONFIG_I2C_I810) += i2c-i810.o obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o -obj-$(CONFIG_I2C_IXP2000) += i2c-ixp2000.o -obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o obj-$(CONFIG_I2C_POWERMAC) += i2c-powermac.o obj-$(CONFIG_I2C_MPC) += i2c-mpc.o obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
@@ -52,7 +50,6 @@ obj-$(CONFIG_I2C_VIA) += i2c-via.o obj-$(CONFIG_I2C_VIAPRO) += i2c-viapro.o obj-$(CONFIG_I2C_VOODOO3) += i2c-voodoo3.o obj-$(CONFIG_SCx200_ACB) += scx200_acb.o -obj-$(CONFIG_SCx200_I2C) += scx200_i2c.o ifeq ($(CONFIG_I2C_DEBUG_BUS),y) EXTRA_CFLAGS += -DDEBUG
drivers/i2c/busses/i2c-ixp2000.c deleted +0 -167
167 lines not on this page · raw message
drivers/i2c/busses/i2c-ixp4xx.c deleted +0 -178
178 lines not on this page · raw message
drivers/i2c/busses/scx200_i2c.c deleted +0 -131
131 lines not on this page · raw message
Quoted 20 lines · Adrian Bunk
This patch contains the overdue removal of three I2C drivers.
Signed-off-by Adrian Bunk <[email protected]>---
Documentation/feature-removal-schedule.txt | 8 drivers/i2c/busses/Kconfig | 59 ------ drivers/i2c/busses/Makefile | 3 drivers/i2c/busses/i2c-ixp2000.c | 167 ------------------- drivers/i2c/busses/i2c-ixp4xx.c | 178 --------------------- drivers/i2c/busses/scx200_i2c.c | 131 --------------- 6 files changed, 546 deletions(-)
6a8e0e37019c0ffeb0071fae30210baf2c3bdd75Documentation/feature-removal-schedule.txt +0
-0
Documentation/feature-removal-schedule.txt Who: Len Brown <[email protected]> · line 227
Quoted 10 lines
Documentation/feature-removal-schedule.txt +0
-7@@ -218,14 +218,6 @@ Who: Len Brown <[email protected]> --------------------------- -What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers -When: September 2007 -Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific - I2C-over-GPIO drivers. -Who: Jean Delvare <[email protected]> - ----------------------------
Did anyone ever write a driver that does i2c on the scx200 using the new i2c-gpio method? I sure haven't seen it, although I am still running 2.6.18 (since that is what debian stable uses) on my scx200 systems. I certainly haven't found any useful instructions on how to use the new i2c-gpio driver on an scx200.
--
Len Sorensen
Quoted 24 lines · Lennart Sorensen
Quoted 23 lines · Adrian Bunk
This patch contains the overdue removal of three I2C drivers.
Signed-off-by Adrian Bunk <[email protected]>---
Documentation/feature-removal-schedule.txt | 8 drivers/i2c/busses/Kconfig | 59 ------ drivers/i2c/busses/Makefile | 3 drivers/i2c/busses/i2c-ixp2000.c | 167 ------------------- drivers/i2c/busses/i2c-ixp4xx.c | 178 --------------------- drivers/i2c/busses/scx200_i2c.c | 131 --------------- 6 files changed, 546 deletions(-)
6a8e0e37019c0ffeb0071fae30210baf2c3bdd75Documentation/feature-removal-schedule.txt +0
-0@@ -218,14 +218,6 @@ Who: Len Brown <[email protected]> ---------------------------
Quoted 13 lines
Documentation/feature-removal-schedule.txt Who: Len Brown <[email protected]> · line 227
Quoted 7 lines
Documentation/feature-removal-schedule.txt +0
-7-What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers -When: September 2007 -Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific - I2C-over-GPIO drivers. -Who: Jean Delvare <[email protected]> - ----------------------------Did anyone ever write a driver that does i2c on the scx200 using the new i2c-gpio method? I sure haven't seen it, although I am still running 2.6.18 (since that is what debian stable uses) on my scx200 systems. I certainly haven't found any useful instructions on how to use the new i2c-gpio driver on an scx200.
There's no driver to write (i2c-gpio is the driver). Instead, the scx200 platform needs to implement the standard GPIO API. I don't think that it has happened yet, and last time this was discussed, someone (can't remember who, sorry), complained that the GPIO API "sucked" and that the scx200 platform would not be updated to use it. I didn't buy the claim due to a lack of argumentation and the fact that the GPIO infrastructure seems to work well enough for many other platforms.
As far as I can see, the ixp2000 platform also doesn't implement the standard GPIO API yet, so of the 3 drivers that are about to be removed, only i2c-ixp4xx can be removed without functionality loss at the moment. Lennert, Russell, are there any plans to convert the ixp2000 platform to use the generic GPIO layer?
Maybe I shouldn't have added this entry in feature-removal-schedule.txt in the first place: these drivers should ideally be dropped in favor of i2c-gpio, but it can only happen for platforms that implement the standard GPIO API. As I am not the one who will convert these platforms, and some of them might as well never be converted (I don't know how active they are nowadays), there's not much I can do.
Thanks,
Signature · 1 line
Jean Delvare
Quoted 14 lines · Jean Delvare
There's no driver to write (i2c-gpio is the driver). Instead, the scx200 platform needs to implement the standard GPIO API. I don't think that it has happened yet, and last time this was discussed, someone (can't remember who, sorry), complained that the GPIO API "sucked" and that the scx200 platform would not be updated to use it. I didn't buy the claim due to a lack of argumentation and the fact that the GPIO infrastructure seems to work well enough for many other platforms.
As far as I can see, the ixp2000 platform also doesn't implement the standard GPIO API yet, so of the 3 drivers that are about to be removed, only i2c-ixp4xx can be removed without functionality loss at the moment. Lennert, Russell, are there any plans to convert the ixp2000 platform to use the generic GPIO layer?
Quoted 6 lines
Maybe I shouldn't have added this entry in feature-removal-schedule.txt in the first place: these drivers should ideally be dropped in favor of i2c-gpio, but it can only happen for platforms that implement the standard GPIO API. As I am not the one who will convert these platforms, and some of them might as well never be converted (I don't know how active they are nowadays), there's not much I can do.
Well if I get a chance I might try to do it for the scx200 at some point (since I do use it) although given the current i2c driver works just fine and I have no need for the rest of the gpio lines what so ever there isn't that much insentive to do so yet.
Removing the existing i2c driver would seem like a mistake at this time though.
--
Len Sorensen
Quoted 22 lines · Lennart Sorensen
Quoted 14 lines · Jean Delvare
There's no driver to write (i2c-gpio is the driver). Instead, the scx200 platform needs to implement the standard GPIO API. I don't think that it has happened yet, and last time this was discussed, someone (can't remember who, sorry), complained that the GPIO API "sucked" and that the scx200 platform would not be updated to use it. I didn't buy the claim due to a lack of argumentation and the fact that the GPIO infrastructure seems to work well enough for many other platforms.
As far as I can see, the ixp2000 platform also doesn't implement the standard GPIO API yet, so of the 3 drivers that are about to be removed, only i2c-ixp4xx can be removed without functionality loss at the moment. Lennert, Russell, are there any plans to convert the ixp2000 platform to use the generic GPIO layer?
Quoted 6 lines
Maybe I shouldn't have added this entry in feature-removal-schedule.txt in the first place: these drivers should ideally be dropped in favor of i2c-gpio, but it can only happen for platforms that implement the standard GPIO API. As I am not the one who will convert these platforms, and some of them might as well never be converted (I don't know how active they are nowadays), there's not much I can do.
Quoted 7 lines
Well if I get a chance I might try to do it for the scx200 at some point (since I do use it) although given the current i2c driver works just fine and I have no need for the rest of the gpio lines what so ever there isn't that much insentive to do so yet.
Removing the existing i2c driver would seem like a mistake at this time though.
Hasn't their been a one year notice that these drivers were going to be removed? How about removing them and putting them into a tarball on the i2c web site with a note explaining about how they need to be updated to use the gpio driver? Then if someone really wants to use the old drivers they can use them out of tree.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 28 lines · Jon Smirl
Quoted 27 lines · Lennart Sorensen
Quoted 14 lines · Jean Delvare
There's no driver to write (i2c-gpio is the driver). Instead, the scx200 platform needs to implement the standard GPIO API. I don't think that it has happened yet, and last time this was discussed, someone (can't remember who, sorry), complained that the GPIO API "sucked" and that the scx200 platform would not be updated to use it. I didn't buy the claim due to a lack of argumentation and the fact that the GPIO infrastructure seems to work well enough for many other platforms.
As far as I can see, the ixp2000 platform also doesn't implement the standard GPIO API yet, so of the 3 drivers that are about to be removed, only i2c-ixp4xx can be removed without functionality loss at the moment. Lennert, Russell, are there any plans to convert the ixp2000 platform to use the generic GPIO layer?
Quoted 6 lines
Maybe I shouldn't have added this entry in feature-removal-schedule.txt in the first place: these drivers should ideally be dropped in favor of i2c-gpio, but it can only happen for platforms that implement the standard GPIO API. As I am not the one who will convert these platforms, and some of them might as well never be converted (I don't know how active they are nowadays), there's not much I can do.
Well if I get a chance I might try to do it for the scx200 at some point (since I do use it) although given the current i2c driver works just fine and I have no need for the rest of the gpio lines what so ever there isn't that much insentive to do so yet.
Quoted 8 lines
Quoted 2 lines
Removing the existing i2c driver would seem like a mistake at this time though.
Hasn't their been a one year notice that these drivers were going to be removed? How about removing them and putting them into a tarball on the i2c web site with a note explaining about how they need to be updated to use the gpio driver? Then if someone really wants to use the old drivers they can use them out of tree.
There's no "i2c web site". And no, I'm not breaking people's setup for fun. The drivers in question are small, I don't care that much if they stick around. If we can remove them (as is the case for i2c-ixp4xx), great, let's go, but if not, there's really no reason to make gratuitous trouble.
The patch I have in my tree now removes i2c-ixp4xx and leaves i2c-ixp2000 and scx200_i2c alone. They can always be removed later if the respective platforms are updated to use the generic GPIO layer.
Signature · 1 line
Jean Delvare
Quoted 5 lines · Jon Smirl
Hasn't their been a one year notice that these drivers were going to be removed? How about removing them and putting them into a tarball on the i2c web site with a note explaining about how they need to be updated to use the gpio driver? Then if someone really wants to use the old drivers they can use them out of tree.
It hasn't been a year - they were added to feature-removal on May 1st.
However, not all the relevant people were made aware of that fact. Yes, Deepak was copied on that message, but I think he's moved on to other things. On the other hand, Lennert (who is listed as IXP2000 maintainer) is completely unaware of these drivers being marked obsolete.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 5 lines · Jon Smirl
Hasn't their been a one year notice that these drivers were going to be removed? How about removing them and putting them into a tarball on the i2c web site with a note explaining about how they need to be updated to use the gpio driver? Then if someone really wants to use the old drivers they can use them out of tree.
Why remove a working driver? Who gets to decide that everyone must go use this gpio api based system that isn't yet supported by all platforms? If someone thinks the old drivers should be replaced by new ones using the new GPIO API then they should go implement it, and then when it works they can remove the old one. You can't just declare that you think the old one sucks and should be removed and if anyone else cares they should go make a working driver to replace it.
--
Len Sorensen
Quoted 7 lines · Jean Delvare
There's no driver to write (i2c-gpio is the driver). Instead, the scx200 platform needs to implement the standard GPIO API. I don't think that it has happened yet, and last time this was discussed, someone (can't remember who, sorry), complained that the GPIO API "sucked" and that the scx200 platform would not be updated to use it. I didn't buy the claim due to a lack of argumentation and the fact that the GPIO infrastructure seems to work well enough for many other platforms.
There's actually a number of people who aren't thrilled by the concept of a GPIO API. The current API is quite limiting in that it isn't actually a "generic" GPIO API - you can't address GPIOs on a GPIO expander with it for instance.
Some of those issues are in the process of being resolved, but I suspect that this is a classic case where you can not satisfy everyone. There'll always be people who refuse to use whatever GPIO API.
Quoted 5 lines
As far as I can see, the ixp2000 platform also doesn't implement the standard GPIO API yet, so of the 3 drivers that are about to be removed, only i2c-ixp4xx can be removed without functionality loss at the moment. Lennert, Russell, are there any plans to convert the ixp2000 platform to use the generic GPIO layer?
It's really for Lennert to comment on; while you may consider I'm the overall ARM maintainer, that doesn't mean that I have access to the entire set of ARM hardware. Bit like expecting Linus to write working drivers for SH4 without ever having had a SH4 platform... ;)
Quoted 4 lines
Maybe I shouldn't have added this entry in feature-removal-schedule.txt in the first place: these drivers should ideally be dropped in favor of i2c-gpio, but it can only happen for platforms that implement the standard GPIO API.
... especially as those who need to comment on it don't get to see Adrian's patches to remove them.
I think it's quite wrong to mark something "obsolete" and scheduling it for removal unless there's an actual functioning replacement.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 23 lines · Jean Delvare
Quoted 9 lines
Quoted 9 lines
6a8e0e37019c0ffeb0071fae30210baf2c3bdd75Documentation/feature-removal-schedule.txt +0
-0@@ -218,14 +218,6 @@ Who: Len Brown <[email protected]> ---------------------------Quoted 13 lines
Documentation/feature-removal-schedule.txt Who: Len Brown <[email protected]> · line 227
Quoted 7 lines
Documentation/feature-removal-schedule.txt +0
-7-What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers -When: September 2007 -Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific - I2C-over-GPIO drivers. -Who: Jean Delvare <[email protected]> - ----------------------------Did anyone ever write a driver that does i2c on the scx200 using the new i2c-gpio method? I sure haven't seen it, although I am still running 2.6.18 (since that is what debian stable uses) on my scx200 systems. I certainly haven't found any useful instructions on how to use the new i2c-gpio driver on an scx200.
Quoted 7 lines
There's no driver to write (i2c-gpio is the driver). Instead, the scx200 platform needs to implement the standard GPIO API. I don't think that it has happened yet, and last time this was discussed, someone (can't remember who, sorry), complained that the GPIO API "sucked" and that the scx200 platform would not be updated to use it. I didn't buy the claim due to a lack of argumentation and the fact that the GPIO infrastructure seems to work well enough for many other platforms.
I expressed some concerns about the GPIO API some time ago, but that was in the context of ep93xx.
Quoted 5 lines
As far as I can see, the ixp2000 platform also doesn't implement the standard GPIO API yet, so of the 3 drivers that are about to be removed, only i2c-ixp4xx can be removed without functionality loss at the moment. Lennert, Russell, are there any plans to convert the ixp2000 platform to use the generic GPIO layer?
No plans at this point from my side.
I'm not entirely sold on the GPIO API, but nevertheless I expect that ixp2000 will be converted sooner rather than later.
If you don't want people to use i2c-ixp2000 as an example for new code, maybe you can stick in a comment at the top of the file that says that what i2c-ixp2000 does isn't the Preferred(TM) way of doing it?
Quoted 6 lines
Maybe I shouldn't have added this entry in feature-removal-schedule.txt in the first place: these drivers should ideally be dropped in favor of i2c-gpio, but it can only happen for platforms that implement the standard GPIO API. As I am not the one who will convert these platforms, and some of them might as well never be converted (I don't know how active they are nowadays), there's not much I can do.
Sorry, I seem to have missed the addition of i2c-ixp2000 to feature-removal-schedule.txt. I would have spoken up earlier if I had been aware of it being in there.
It seems odd to me to advocate removal of something which works fine and for which no functional replacement is available just because it doesn't conform to the Latest And Greatest API(TM). That's like suggesting that Jan 1st 2009 we should rm -f all .c files that still reference the big kernel lock, or rm -f all ARM ports that don't use the clocksource/clockevent mechanism yet (which includes ixp2000 as well.)
Let's just remove i2c-ixp2000 when the GPIO API conversion happens, ok?
Quoted 10 lines · Lennert Buytenhek
On Wed, Nov 28, 2007 at 11:23:57AM +0100, Jean Delvare wrote:
(...)Quoted 5 lines
As far as I can see, the ixp2000 platform also doesn't implement the standard GPIO API yet, so of the 3 drivers that are about to be removed, only i2c-ixp4xx can be removed without functionality loss at the moment. Lennert, Russell, are there any plans to convert the ixp2000 platform to use the generic GPIO layer?
No plans at this point from my side.
Quoted 7 lines
I'm not entirely sold on the GPIO API, but nevertheless I expect that ixp2000 will be converted sooner rather than later.
If you don't want people to use i2c-ixp2000 as an example for new code, maybe you can stick in a comment at the top of the file that says that what i2c-ixp2000 does isn't the Preferred(TM) way of doing it?
The driver is tagged DEPRECATED in Kconfig, that should be enough. Not to mention that any new i2c bus driver has to go through me so I'd intercept the offender anyway.
Quoted 13 lines
(...)
Sorry, I seem to have missed the addition of i2c-ixp2000 to feature-removal-schedule.txt. I would have spoken up earlier if I had been aware of it being in there.It seems odd to me to advocate removal of something which works fine and for which no functional replacement is available just because it doesn't conform to the Latest And Greatest API(TM). That's like suggesting that Jan 1st 2009 we should rm -f all .c files that still reference the big kernel lock, or rm -f all ARM ports that don't use the clocksource/clockevent mechanism yet (which includes ixp2000 as well.)
Quoted 1 line
Let's just remove i2c-ixp2000 when the GPIO API conversion happens, ok?
That's the plan, yes.
Signature · 1 line
Jean Delvare