init_IRQ() have no prototype, add one in irq.h
Fix the following warnings (treated as error in W=1):
arch/mips/kernel/irq.c:52:13: error: no previous prototype for 'init_IRQ' [-Werror=missing-prototypes]
Signed-off-by: Pujin Shi <[email protected]>
---
arch/mips/include/asm/irq.h | 1 +
arch/mips/kernel/irq.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
index c5d351786416..992f8040d3d9 100644
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -21,6 +21,7 @@
#define IRQ_STACK_START (IRQ_STACK_SIZE - 16)
extern void *irq_stack[NR_CPUS];
+void init_IRQ(void);
/*
* The highest address on the IRQ stack contains a dummy frame put down in
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index 85b6c60f285d..07d2c86e7ff5 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -21,6 +21,7 @@
#include <linux/kallsyms.h>
#include <linux/kgdb.h>
#include <linux/ftrace.h>
+#include <asm/irq.h>
#include <linux/atomic.h>
#include <linux/uaccess.h>
--
2.18.1
On Wed, Sep 23, 2020 at 11:26:50AM +0800, Pujin Shi wrote:
> init_IRQ() have no prototype, add one in irq.h
>
> Fix the following warnings (treated as error in W=1):
> arch/mips/kernel/irq.c:52:13: error: no previous prototype for 'init_IRQ' [-Werror=missing-prototypes]
>
> Signed-off-by: Pujin Shi <[email protected]>
> ---
> arch/mips/include/asm/irq.h | 1 +
> arch/mips/kernel/irq.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
> index c5d351786416..992f8040d3d9 100644
> --- a/arch/mips/include/asm/irq.h
> +++ b/arch/mips/include/asm/irq.h
> @@ -21,6 +21,7 @@
> #define IRQ_STACK_START (IRQ_STACK_SIZE - 16)
>
> extern void *irq_stack[NR_CPUS];
> +void init_IRQ(void);
putting it here hasn't any value. If you want to fix this properly,
move the extern void init_IRQ(void) in init/main.c to a common header
file and check that every arch to uses it.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]