Skip to contentSkip to conversation

ixp4xx: fix compilation by adding gpiolib support

PATCH New Richard Cochran 6 participants 15 messages May 23, 2012 – May 28, 2012

Subsystems (3)
Arm (32-bit) Arm sub-architectures Arm/Intel IXP4XX Arm architecture
lore
Share & tools
lore

Richard Cochran

author
#0 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Once again, ixp4xx no longer even compiles. This patch fixes the issue by converting over to gpiolib. This patch was first made by Imre and posted by Marc, and I added in Russell's suggestion to empty the gpio header file.

This fix should also go for 3.1, 3.2, 3.3, and 3.4.

Signed-off-by Richard Cochran <[email protected]>
Cc <[email protected]>
---
 arch/arm/Kconfig                         |    2 +-
 arch/arm/mach-ixp4xx/common.c            |   48 +++++++++++++++++-
 arch/arm/mach-ixp4xx/include/mach/gpio.h |   79 +-----------------------------
 3 files changed, 48 insertions(+), 81 deletions(-)
arch/arm/Kconfig +1 -1
index 36586dba..7a8660a 100644
@@ -556,7 +556,7 @@ config ARCH_IXP4XX
 	select ARCH_HAS_DMA_SET_COHERENT_MASK
 	select CLKSRC_MMIO
 	select CPU_XSCALE
-	select GENERIC_GPIO
+	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
 	select MIGHT_HAVE_PCI
 	select NEED_MACH_IO_H
arch/arm/mach-ixp4xx/common.c +46 -2

78 lines not on this page · raw message

arch/arm/mach-ixp4xx/include/mach/gpio.h +1 -78

80 lines not on this page · raw message

Signature · 1 line
1.7.2.5
#1 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Hi Richard,

Quoted 1 line · Richard Cochran

Once again, ixp4xx no longer even compiles.

Awesome, thanks for your persistence.

Quoted 1 line

From [1] I see some details that would be useful for the commit message.

Could you include them?

This patch adds gpiolib support for the IXP4xx platform, which fixes the compilation of several ixp4xx platforms, e.g.:

In file included from arch/arm/mach-ixp4xx/include/mach/gpio.h:72,
from /home/frogger/projects/server/linux/arch/arm/include/asm/gpio.h:9, from include/linux/gpio.h:30,
from arch/arm/mach-ixp4xx/nslu2-setup.c:19:
include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep':
include/asm-generic/gpio.h:218: error: implicit declaration of function '__gpio_get_value' include/asm-generic/gpio.h: In function 'gpio_set_value_cansleep':
include/asm-generic/gpio.h:224: error: implicit declaration of function '__gpio_set_value'

And:

The problem was introduced with commit eb9ae7f2a381 ("gpio: fix build error in include/asm-generic/gpio.h").

[...]

Quoted 1 line

This fix should also go for 3.1, 3.2, 3.3, and 3.4.

If 3.1.y were still maintained, do I understand correctly that it would not need this because it lacks eb9ae7f2a381?

[...]

Quoted 4 lines
 arch/arm/Kconfig                         |    2 +-
 arch/arm/mach-ixp4xx/common.c            |   48 +++++++++++++++++-
 arch/arm/mach-ixp4xx/include/mach/gpio.h |   79 +-----------------------------
 3 files changed, 48 insertions(+), 81 deletions(-)

This is bigger than the usual stable-kernel-rules.txt standard (100 lines with context), but the gpio.h change leaves me so happy that I suspect it should be okay. :) If it isn't, we can cross that bridge later.

Hope that helps,
Jonathan

[1] http://thread.gmane.org/gmane.linux.kernel/1250585/focus=1250584

#2 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 2 lines · Jonathan Nieder

The problem was introduced with commit eb9ae7f2a381 ("gpio: fix build error in include/asm-generic/gpio.h").

[...]

Quoted 6 lines
Quoted 1 line · Richard Cochran

This fix should also go for 3.1, 3.2, 3.3, and 3.4.

If 3.1.y were still maintained, do I understand correctly that it would not need this because it lacks eb9ae7f2a381?

Quick correction: looks like[*] 3.1 is also affected due to 58c244009ef6 ("Input: ads7846 - cleanup GPIO initialization"). Sorry I missed that before.

drivers/input/touchscreen/ads7846.c: In function 'ads7846_setup_pendown':
drivers/input/touchscreen/ads7846.c:970: error: implicit declaration of function 'gpio_request_one'

Hope that helps,
Jonathan

[*] http://thread.gmane.org/gmane.linux.kernel/1250585/focus=1250984

author
#3 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 3 lines · Jonathan Nieder

Quick correction: looks like[*] 3.1 is also affected due to 58c244009ef6 ("Input: ads7846 - cleanup GPIO initialization"). Sorry I missed that before.

...

Quoted 1 line

Hope that helps,

Yes, it does. I appreciate your effort in testing this on the older versions.

Thanks,
Richard

#4 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

In reply to Richard Cochran
Quoted 9 lines · Richard Cochran

Once again, ixp4xx no longer even compiles. This patch fixes the issue by converting over to gpiolib. This patch was first made by Imre and posted by Marc, and I added in Russell's suggestion to empty the gpio header file.

This fix should also go for 3.1, 3.2, 3.3, and 3.4.

Signed-off-by Richard Cochran <[email protected]>
Cc <[email protected]>

So has every kernel since 3.1 been broken, or is it just broken now but a good idea to backport anyway?

Arnd

#5 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 6 lines · Arnd Bergmann
Quoted 5 lines · Richard Cochran

Once again, ixp4xx no longer even compiles. This patch fixes the issue by converting over to gpiolib. This patch was first made by Imre and posted by Marc, and I added in Russell's suggestion to empty the gpio header file.

Quoted 7 lines
Quoted 4 lines

This fix should also go for 3.1, 3.2, 3.3, and 3.4.

Signed-off-by Richard Cochran <[email protected]>
Cc <[email protected]>

So has every kernel since 3.1 been broken, or is it just broken now but a good idea to backport anyway?

every kernel since 3.1 (even 3.1-rc-something). Would be nice to see this issue fixed as similar patches have been sent from time to time but never been merged.

Arnaud

#6 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 13 lines · Arnaud Patard
Quoted 11 lines · Arnd Bergmann
Quoted 9 lines · Richard Cochran

Once again, ixp4xx no longer even compiles. This patch fixes the issue by converting over to gpiolib. This patch was first made by Imre and posted by Marc, and I added in Russell's suggestion to empty the gpio header file.

This fix should also go for 3.1, 3.2, 3.3, and 3.4.

Signed-off-by Richard Cochran <[email protected]>
Cc <[email protected]>
Quoted 6 lines
Quoted 2 lines

So has every kernel since 3.1 been broken, or is it just broken now but a good idea to backport anyway?

every kernel since 3.1 (even 3.1-rc-something). Would be nice to see this issue fixed as similar patches have been sent from time to time but never been merged.

Ok, thanks for the info. I'm sorry that it has come so far. I think Olof and I are generally doing a good job at picking up all the pull requests, but we sometimes miss single patches, especially when it's not clear that they are expected to go into the arm-soc tree.

I have to admit that I didn't even remember who maintains ixp4xx, since there hasn't been a single ixp4xx patch from Imre or Krzysztof that I've put into the kernel over this time frame.

I've put the patch into the fixes branch now, it should be part of the next round of submissions.

What is the plan for ixp4xx going forward? Is one of you planning to maintain a git tree and collect patches for inclusion in arm-soc? I would be more comfortable just knowing where to pull from than having to watch the mailing list and making sure the maintainers Ack all the patches.
If there is no tree, should we downgrade ixp4xx in the MAINTAINERS file from "Maintained" to "Odd fixes"?

Arnd

author
#7 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 9 lines · Arnd Bergmann

Ok, thanks for the info. I'm sorry that it has come so far. I think Olof and I are generally doing a good job at picking up all the pull requests, but we sometimes miss single patches, especially when it's not clear that they are expected to go into the arm-soc tree.

I have to admit that I didn't even remember who maintains ixp4xx, since there hasn't been a single ixp4xx patch from Imre or Krzysztof that I've put into the kernel over this time frame.

It seems like the maintainers are not very responsive.

Quoted 7 lines

What is the plan for ixp4xx going forward? Is one of you planning to maintain a git tree and collect patches for inclusion in arm-soc? I would be more comfortable just knowing where to pull from than having to watch the mailing list and making sure the maintainers Ack all the patches.
If there is no tree, should we downgrade ixp4xx in the MAINTAINERS file from "Maintained" to "Odd fixes"?

Yes, there should be some kind of plan.

Thanks,
Richard

#8 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 21 lines · Richard Cochran
Quoted 9 lines · Arnd Bergmann

Ok, thanks for the info. I'm sorry that it has come so far. I think Olof and I are generally doing a good job at picking up all the pull requests, but we sometimes miss single patches, especially when it's not clear that they are expected to go into the arm-soc tree.

I have to admit that I didn't even remember who maintains ixp4xx, since there hasn't been a single ixp4xx patch from Imre or Krzysztof that I've put into the kernel over this time frame.

It seems like the maintainers are not very responsive.

Quoted 7 lines

What is the plan for ixp4xx going forward? Is one of you planning to maintain a git tree and collect patches for inclusion in arm-soc? I would be more comfortable just knowing where to pull from than having to watch the mailing list and making sure the maintainers Ack all the patches.
If there is no tree, should we downgrade ixp4xx in the MAINTAINERS file from "Maintained" to "Odd fixes"?

Quoted 1 line

Yes, there should be some kind of plan.

So would you be available to help out as a maintainer if Imre and Krzysztof are no longer interested? You seem to be the only person who has pushed any non-janitorial patches over the last year here. I don't think it would be much work, mostly collecting the odd fixes and occasionally trying that the boards you have still boot.

Arnd

author
#9 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 6 lines · Arnd Bergmann

So would you be available to help out as a maintainer if Imre and Krzysztof are no longer interested? You seem to be the only person who has pushed any non-janitorial patches over the last year here. I don't think it would be much work, mostly collecting the odd fixes and occasionally trying that the boards you have still boot.

I might be able to help in this way. Let us wait to hear what Imre and Krzysztof have to say first.

Thanks,
Richard

#10 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

In reply to Arnd Bergmann

On Wed, 23 May 2012 21:39:49 +0200, Arnd Bergmann <[email protected]> wrote:

<snip>

Quoted 9 lines

Ok, thanks for the info. I'm sorry that it has come so far. I think Olof and I are generally doing a good job at picking up all the pull requests, but we sometimes miss single patches, especially when it's not clear that they are expected to go into the arm-soc tree.

I have to admit that I didn't even remember who maintains ixp4xx, since there hasn't been a single ixp4xx patch from Imre or Krzysztof that I've put
into the kernel over this time frame.

The gpiolib patch originated from me as well.

Quoted 2 lines

I've put the patch into the fixes branch now, it should be part of the next round of submissions.

Thanks.

Quoted 8 lines

What is the plan for ixp4xx going forward? Is one of you planning to maintain a git tree and collect patches for inclusion in arm-soc? I would be more comfortable just knowing where to pull from than having to watch the mailing list and making sure the maintainers Ack all the patches.

If there is no tree, should we downgrade ixp4xx in the MAINTAINERS file from "Maintained" to "Odd fixes"?

Quite some patches are still in the OpenWrt repo only. When I'll have time, I'll revisit those as well as migrate ixp4xx to DT. I'm overloaded with work, so I'll need a few more weeks and I guess the same is true for Krzysztof as well..

Imre

#11 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 1 line · Imre Kaloz

The gpiolib patch originated from me as well.

I've changed the author tag in the changeset to you now, and noted the fact that Richard submitted it.

Quoted 6 lines
Quoted 6 lines

What is the plan for ixp4xx going forward? Is one of you planning to maintain a git tree and collect patches for inclusion in arm-soc? I would be more comfortable just knowing where to pull from than having to watch the mailing list and making sure the maintainers Ack all the patches.

Quoted 7 lines
Quoted 2 lines

If there is no tree, should we downgrade ixp4xx in the MAINTAINERS file from "Maintained" to "Odd fixes"?

Quite some patches are still in the OpenWrt repo only. When I'll have time, I'll revisit those as well as migrate ixp4xx to DT. I'm overloaded with work, so I'll need a few more weeks and I guess the same is true for Krzysztof as well..

Ok, good to hear that you're still interested! I don't get the impression that migrating ixp4xx to DT is urgent in any way, but I also don't think it will be too much work. If all you want to do is allow the board files to be replaced with DT, then I assume you need bindings for the flash, ethernet and CF devices and convert the interrupt controller to use irq domains. For PCI, it should be enough to provide a generic map_irq function that uses the standard interrupt-maps property. That function can even be defined in a way that is usable independent of the platform.

Arnd

author
#12 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 5 lines · Arnd Bergmann
Quoted 1 line · Imre Kaloz

The gpiolib patch originated from me as well.

I've changed the author tag in the changeset to you now, and noted the fact that Richard submitted it.

I don't mind Imre getting the credit for this, but I changed this patch so much that it really would need Imre's ack.

Thanks,
Richard

#13 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

In reply to Arnaud Patard (Rtp)
Quoted 6 lines · Arnaud Patard (Rtp)
Quoted 2 lines

So has every kernel since 3.1 been broken, or is it just broken now but a good idea to backport anyway?

every kernel since 3.1 (even 3.1-rc-something). Would be nice to see this issue fixed as similar patches have been sent from time to time but never been merged.

Is it really that bad? I'm using IXP425 with 3.2 and it definitely compiles (and works). Extra patches maybe? I can't see anything obvious.

I can only promise I'll scan the mail backlog (which is huge) and fix the mess.

Signature · 1 line
Krzysztof Halasa
author
#14 lore raw

PATCH 1/1 ixp4xx: fix compilation by adding gpiolib support

Quoted 11 lines · Krzysztof Halasa
Quoted 6 lines · Arnaud Patard (Rtp)
Quoted 2 lines

So has every kernel since 3.1 been broken, or is it just broken now but a good idea to backport anyway?

every kernel since 3.1 (even 3.1-rc-something). Would be nice to see this issue fixed as similar patches have been sent from time to time but never been merged.

Is it really that bad? I'm using IXP425 with 3.2 and it definitely compiles (and works). Extra patches maybe? I can't see anything obvious.

[Sigh]

Yes, it is really that bad. Try the following:

1. export kernel with tag v3.2
2. make ixp4xx_defconfig
3. make

You will see:

CC arch/arm/mach-ixp4xx/nslu2-setup.o
In file included from arch/arm/mach-ixp4xx/include/mach/gpio.h:72,

                 from /tmp/linux-v3.2/arch/arm/include/asm/gpio.h:5,
                 from include/linux/gpio.h:30,
                 from arch/arm/mach-ixp4xx/nslu2-setup.c:19:

include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep':
include/asm-generic/gpio.h:212: error: implicit declaration of function '__gpio_get_value' include/asm-generic/gpio.h: In function 'gpio_set_value_cansleep':
include/asm-generic/gpio.h:218: error: implicit declaration of function '__gpio_set_value' make[1]: *** [arch/arm/mach-ixp4xx/nslu2-setup.o] Error 1

Richard