irqnr fallout in gpiolib on sparc32

irqnr fallout in gpiolib on sparc32

[Sam Ravnborg]

I hit the following build error on sparc:

drivers/gpio/gpiolib.c: In function `gpiolib_dbg_show':
drivers/gpio/gpiolib.c:1146: error: implicit declaration of function `irq_to_desc'
drivers/gpio/gpiolib.c:1146: warning: initialization makes pointer from integer without a cast


This is with an allmodconfig where I did:

make ARCH=sparc vmlinux

sparc do _not_ have GENERIC_HARDIRQS set to 'y'.

I did a simple:
#include <linux/irqnr.h> but that did not help.

I have not investigated further atm.

It is preproduceable with HEAD equal fe0bdec68b77020281dc814805edfe594ae89e0f
[latest -linus when writing this]

	Sam

Re: irqnr fallout in gpiolib on sparc32

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> I hit the following build error on sparc:
> 
> drivers/gpio/gpiolib.c: In function `gpiolib_dbg_show':
> drivers/gpio/gpiolib.c:1146: error: implicit declaration of function `irq_to_desc'
> drivers/gpio/gpiolib.c:1146: warning: initialization makes pointer from integer without a cast
> 
> 
> This is with an allmodconfig where I did:
> 
> make ARCH=sparc vmlinux
> 
> sparc do _not_ have GENERIC_HARDIRQS set to 'y'.
>
> I did a simple:
> #include <linux/irqnr.h> but that did not help.

yeah. Does the patch below do the trick?

btw., i'm curious, does the unification of the sparc architectures mean 
that sparc32 will be using genirq too some time in the future?

	Ingo

---------------->
>From 08522e214542b4afc6c2401bb02900cfca76f600 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 5 Jan 2009 14:34:42 +0100
Subject: [PATCH] genirq: provide irq_to_desc() to non-genirq architectures too

Impact: build fix on non-genirq architectures

Sam Ravnborg reported this build failure on sparc32 allmodconfig,
the GPIO drivers assume the presence of irq_to_desc():

 drivers/gpio/gpiolib.c: In function `gpiolib_dbg_show':
 drivers/gpio/gpiolib.c:1146: error: implicit declaration of function 'irq_to_desc'

Add it in the !genirq case too.

Reported-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/irqnr.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/linux/irqnr.h b/include/linux/irqnr.h
index 5504a5c..6b719fa 100644
--- a/include/linux/irqnr.h
+++ b/include/linux/irqnr.h
@@ -8,7 +8,12 @@
 
 #ifndef CONFIG_GENERIC_HARDIRQS
 #include <asm/irq.h>
-# define nr_irqs		NR_IRQS
+
+/*
+ * Wrappers for non-genirq architectures:
+ */
+#define nr_irqs			NR_IRQS
+#define irq_to_desc(irq)	irq_desc[irq]
 
 # define for_each_irq_desc(irq, desc)		\
 	for (irq = 0; irq < nr_irqs; irq++)

Re: irqnr fallout in gpiolib on sparc32

[Sam Ravnborg]

On Mon, Jan 05, 2009 at 02:38:19PM +0100, Ingo Molnar wrote:
> 
> * Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > I hit the following build error on sparc:
> > 
> > drivers/gpio/gpiolib.c: In function `gpiolib_dbg_show':
> > drivers/gpio/gpiolib.c:1146: error: implicit declaration of function `irq_to_desc'
> > drivers/gpio/gpiolib.c:1146: warning: initialization makes pointer from integer without a cast
> > 
> > 
> > This is with an allmodconfig where I did:
> > 
> > make ARCH=sparc vmlinux
> > 
> > sparc do _not_ have GENERIC_HARDIRQS set to 'y'.
> >
> > I did a simple:
> > #include <linux/irqnr.h> but that did not help.
> 
> yeah. Does the patch below do the trick?

Needed a small fix - see below.

> 
> btw., i'm curious, does the unification of the sparc architectures mean 
> that sparc32 will be using genirq too some time in the future?

Dave has mentioned this but we are not working actively on it yet.

> 
> 	Ingo
> 
> ---------------->
> From 08522e214542b4afc6c2401bb02900cfca76f600 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@elte.hu>
> Date: Mon, 5 Jan 2009 14:34:42 +0100
> Subject: [PATCH] genirq: provide irq_to_desc() to non-genirq architectures too
> 
> Impact: build fix on non-genirq architectures
> 
> Sam Ravnborg reported this build failure on sparc32 allmodconfig,
> the GPIO drivers assume the presence of irq_to_desc():
> 
>  drivers/gpio/gpiolib.c: In function `gpiolib_dbg_show':
>  drivers/gpio/gpiolib.c:1146: error: implicit declaration of function 'irq_to_desc'
> 
> Add it in the !genirq case too.
> 
> Reported-by: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  include/linux/irqnr.h |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/irqnr.h b/include/linux/irqnr.h
> index 5504a5c..6b719fa 100644
> --- a/include/linux/irqnr.h
> +++ b/include/linux/irqnr.h
> @@ -8,7 +8,12 @@
>  
>  #ifndef CONFIG_GENERIC_HARDIRQS
>  #include <asm/irq.h>
> -# define nr_irqs		NR_IRQS
> +
> +/*
> + * Wrappers for non-genirq architectures:
> + */
> +#define nr_irqs			NR_IRQS
> +#define irq_to_desc(irq)	irq_desc[irq]

irq_to_desc(irq) return a pointer to a struct irq_desc
so we need to take the address.

> +#define irq_to_desc(irq)	&irq_desc[irq]
                                ^
With this small fix the build continues.

Thanks,
	Sam

Re: irqnr fallout in gpiolib on sparc32

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> > > I did a simple:
> > > #include <linux/irqnr.h> but that did not help.
> > 
> > yeah. Does the patch below do the trick?
> 
> Needed a small fix - see below.
> 
> > btw., i'm curious, does the unification of the sparc architectures 
> > mean that sparc32 will be using genirq too some time in the future?
> 
> Dave has mentioned this but we are not working actively on it yet.

would be cool to do it - i think sparc32 is one of the last major physical 
architectures to not be on genirq - if we did this conversion we could do 
a good number of nice cleanups by eliminating all the genirq/non-genirq 
differences.

> > +#define nr_irqs			NR_IRQS
> > +#define irq_to_desc(irq)	irq_desc[irq]
> 
> irq_to_desc(irq) return a pointer to a struct irq_desc
> so we need to take the address.
> 
> > +#define irq_to_desc(irq)	&irq_desc[irq]
>                                 ^
> With this small fix the build continues.

oops, indeed. I fixed it, added your Tested-by and pushed it into 
tip/irq/urgent. Thanks Sam!

	Ingo

Re: irqnr fallout in gpiolib on sparc32

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 5 Jan 2009 14:55:08 +0100

> * Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > Dave has mentioned this but we are not working actively on it yet.
> 
> would be cool to do it - i think sparc32 is one of the last major physical 
> architectures to not be on genirq -

m68k remains to be converted over to genirq as well

Re: irqnr fallout in gpiolib on sparc32

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Mon, 5 Jan 2009 14:55:08 +0100
> 
> > * Sam Ravnborg <sam@ravnborg.org> wrote:
> > 
> > > Dave has mentioned this but we are not working actively on it yet.
> > 
> > would be cool to do it - i think sparc32 is one of the last major 
> > physical architectures to not be on genirq -
> 
> m68k remains to be converted over to genirq as well

yeah - but m68k has been a holdout from pretty much every optional core 
kernel facility that has been introduced in the past 5-10 years. So if 
sparc32 converts to genirq we have a stronger case for saying:

   "Convert, else ..."

[ where the three dots stands for something not nice. ]

Sparc32 on the other hand had a clean IRQ layer long before x86 found its 
desire for a clean genirq layer - so genirq is a nuisance for Sparc32 at 
best and it deserves none of the not nice actions. What i am hoping for is 
that perhaps the Sparc unification changed that equation.

	Ingo

Re: irqnr fallout in gpiolib on sparc32

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 6 Jan 2009 13:57:04 +0100

> Sparc32 on the other hand had a clean IRQ layer long before x86 found its 
> desire for a clean genirq layer - so genirq is a nuisance for Sparc32 at 
> best and it deserves none of the not nice actions. What i am hoping for is 
> that perhaps the Sparc unification changed that equation.

Not really, the unificiation didn't change much in this area.  That
doesn't change the fact that I do intend to genirq'ify sparc32 some
time soon. :-)

Re: irqnr fallout in gpiolib on sparc32

[KOSAKI Motohiro]

> >  #ifndef CONFIG_GENERIC_HARDIRQS
> >  #include <asm/irq.h>
> > -# define nr_irqs		NR_IRQS
> > +
> > +/*
> > + * Wrappers for non-genirq architectures:
> > + */
> > +#define nr_irqs			NR_IRQS
> > +#define irq_to_desc(irq)	irq_desc[irq]
> 
> irq_to_desc(irq) return a pointer to a struct irq_desc
> so we need to take the address.
> 
> > +#define irq_to_desc(irq)	&irq_desc[irq]
>                                 ^
> With this small fix the build continues.

maybe my fault.
very thanks.

Re: irqnr fallout in gpiolib on sparc32

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Tue, 6 Jan 2009 13:57:04 +0100
> 
> > Sparc32 on the other hand had a clean IRQ layer long before x86 found its 
> > desire for a clean genirq layer - so genirq is a nuisance for Sparc32 at 
> > best and it deserves none of the not nice actions. What i am hoping for is 
> > that perhaps the Sparc unification changed that equation.
> 
> Not really, the unificiation didn't change much in this area. [...]

Yeah, i mean - "changed the equation" psychologically, the same way it did 
it on x86.

There's now two files close to each other in the namespace:

 earth4:~/tip> ls -l arch/sparc/kernel/irq*.c
 -rw-rw-r-- 1 mingo mingo 16122 2009-01-07 13:50 arch/sparc/kernel/irq_32.c
 -rw-rw-r-- 1 mingo mingo 26556 2009-01-07 12:34 arch/sparc/kernel/irq_64.c

Each of them crying out loud to be unified. Every time you open irq_64.c 
you'll think "why that ugly _64.c postfix, shouldnt this be irq.c 
instead?" ;-)

That kind of gentle pressure to unify comes straight from the fact that 
there's _32.c and _64.c postfixes around and the postfixes mess up command 
completion when those files are opened, so we notice the non-unified-ness 
again and again.

At least this was what drove many of the x86 unifications. (Mind you, 
irq_32/irq_64.c is still not fully unified on x86 ;)

> [...] That doesn't change the fact that I do intend to genirq'ify 
> sparc32 some time soon. :-)

Cool! :-)

	Ingo

Re: irqnr fallout in gpiolib on sparc32

[Sam Ravnborg]

On Wed, Jan 07, 2009 at 02:02:13PM +0100, Ingo Molnar wrote:
> 
> * David Miller <davem@davemloft.net> wrote:
> 
> > From: Ingo Molnar <mingo@elte.hu>
> > Date: Tue, 6 Jan 2009 13:57:04 +0100
> > 
> > > Sparc32 on the other hand had a clean IRQ layer long before x86 found its 
> > > desire for a clean genirq layer - so genirq is a nuisance for Sparc32 at 
> > > best and it deserves none of the not nice actions. What i am hoping for is 
> > > that perhaps the Sparc unification changed that equation.
> > 
> > Not really, the unificiation didn't change much in this area. [...]
> 
> Yeah, i mean - "changed the equation" psychologically, the same way it did 
> it on x86.
> 
> There's now two files close to each other in the namespace:
> 
>  earth4:~/tip> ls -l arch/sparc/kernel/irq*.c
>  -rw-rw-r-- 1 mingo mingo 16122 2009-01-07 13:50 arch/sparc/kernel/irq_32.c
>  -rw-rw-r-- 1 mingo mingo 26556 2009-01-07 12:34 arch/sparc/kernel/irq_64.c
> 
> Each of them crying out loud to be unified. Every time you open irq_64.c 
> you'll think "why that ugly _64.c postfix, shouldnt this be irq.c 
> instead?" ;-)
> 
> That kind of gentle pressure to unify comes straight from the fact that 
> there's _32.c and _64.c postfixes around and the postfixes mess up command 
> completion when those files are opened, so we notice the non-unified-ness 
> again and again.

I most remind you how you eat an elephant ;-)
You eat it bite by bite.
And you start with the easy bits first to harden your stommach.

Try to do a:
git shortlog --since=2-months arch/sparc/

I for one is very happy with what we have achieved so far.

irq_* unification will come when we reach that part.

	Sam

Re: irqnr fallout in gpiolib on sparc32

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Wed, 7 Jan 2009 14:02:13 +0100

> Each of them crying out loud to be unified. Every time you open irq_64.c 
> you'll think "why that ugly _64.c postfix, shouldnt this be irq.c 
> instead?" ;-)

Doesn't work very well when you have sun4c_irq.c, sun4m_irq.c,
and sun4d_irq.c sitting right next to them.

Sparc32 is miles away from sparc64 in terms of being easy to make
use generic IRQs.

It's a lot of hard work and testing of which I have to rely upon
helpers to perform.  The sparc arch directory consolidation in no way
makes me want to do that work any more or any less, no matter how many
times I open up irq_64.c :-)