| Message ID | 20090105133819.GE6014@elte.hu |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* 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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* 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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. :-) -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > #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. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* 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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 :-) -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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++)