Skip to contentSkip to conversation

sh: convert to asm-generic/hardirq.h

PATCH Applied Christoph Hellwig 2 participants 6 messages Aug 4, 2009 – Dec 17, 2009 SuperH

lore
Share & tools
lore

Christoph Hellwig

author
#0 lore raw

PATCH 1/1 sh: convert to asm-generic/hardirq.h

Signed-off-by Christoph Hellwig <[email protected]>
arch/sh/include/asm/hardirq.h +3 -10
Index: linux-2.6/arch/sh/include/asm/hardirq.h
===================================================================
@@ -1,16 +1,9 @@
 #ifndef __ASM_SH_HARDIRQ_H
 #define __ASM_SH_HARDIRQ_H
 
-#include <linux/threads.h>
-#include <linux/irq.h>
-
-/* entry.S is sensitive to the offsets of these fields */
-typedef struct {
-	unsigned int __softirq_pending;
-} ____cacheline_aligned irq_cpustat_t;
-
-#include <linux/irq_cpustat.h>	/* Standard mappings for irq_cpustat_t above */
-
 extern void ack_bad_irq(unsigned int irq);
+#define ack_bad_irq ack_bad_irq
+
+#include <asm-generic/hardirq.h>
 
 #endif /* __ASM_SH_HARDIRQ_H */
#3 lore raw
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · Paul Mundt
Quoted 3 lines · Christoph Hellwig
Signed-off-by Christoph Hellwig <[email protected]>

Applied, thanks.

Did this cause problems in the end? Still doesn't seem to be in Linus' tree.

Nope, it was in Linus' tree for awhile, but then I needed to add an nmi_count and had to switch back to an arch-specific one.

author
#4 lore raw
Quoted 6 lines · Paul Mundt
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Paul Mundt
Quoted 3 lines · Christoph Hellwig
Signed-off-by Christoph Hellwig <[email protected]>
Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Applied, thanks.

Did this cause problems in the end? Still doesn't seem to be in Linus' tree.

Nope, it was in Linus' tree for awhile, but then I needed to add an nmi_count and had to switch back to an arch-specific one.

Is there a good reason to overload the irq_cpustat with that? It seems like a quite horrible way to duplicate per-cpu data in a less efficient way.

#5 lore raw
Quoted 12 lines · Christoph Hellwig
Quoted 11 lines · Paul Mundt
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · Paul Mundt
Quoted 3 lines · Christoph Hellwig
Signed-off-by Christoph Hellwig <[email protected]>

Applied, thanks.

Did this cause problems in the end? Still doesn't seem to be in Linus' tree.

Quoted 6 lines
Quoted 2 lines

Nope, it was in Linus' tree for awhile, but then I needed to add an nmi_count and had to switch back to an arch-specific one.

Is there a good reason to overload the irq_cpustat with that? It seems like a quite horrible way to duplicate per-cpu data in a less efficient way.

I suppose not, but there didn't seem like a lot of good alternatives either. Shoving it in irq_cpustat is what is presently done by at least mn10300, x86, and xtensa. sparc chose stashing it in its cpuinfo struct, but then also has a meaningful per-cpu storage area. If you have any better ideas I'll certainly consider moving it.