Re: [PATCH v4] MIPS: Remove repetitive increase irq_err_count

[Thomas Bogendoerfer]

On Fri, Jun 10, 2022 at 07:14:20PM +0800, Genjian Zhang wrote:
> From: huhai <huhai@xxxxxxxxxx>
> 
> commit 979934da9e7a ("[PATCH] mips: update IRQ handling for vr41xx") added
> a function irq_dispatch, and it'll increase irq_err_count when the get_irq
> callback returns a negative value, but increase irq_err_count in get_irq
> was not removed.
> 
> And also, modpost complains once gpio-vr41xx drivers become modules.
>   ERROR: modpost: "irq_err_count" [drivers/gpio/gpio-vr41xx.ko] undefined!
> 
> So it would be a good idea to remove repetitive increase irq_err_count in
> get_irq callback.
> 
> Fixes: 27fdd325dace ("MIPS: Update VR41xx GPIO driver to use gpiolib")
> Fixes: 979934da9e7a ("[PATCH] mips: update IRQ handling for vr41xx")
> Reported-by: k2ci <kernel-bot@xxxxxxxxxx>
> Signed-off-by: huhai <huhai@xxxxxxxxxx>
> Signed-off-by: Genjian Zhang <zhanggenjian@xxxxxxxxxx>
> ---
>  arch/mips/vr41xx/common/icu.c | 2 --
>  drivers/gpio/gpio-vr41xx.c    | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/arch/mips/vr41xx/common/icu.c b/arch/mips/vr41xx/common/icu.c
> index 7b7f25b4b057..9240bcdbe74e 100644
> --- a/arch/mips/vr41xx/common/icu.c
> +++ b/arch/mips/vr41xx/common/icu.c
> @@ -640,8 +640,6 @@ static int icu_get_irq(unsigned int irq)
>  
>  	printk(KERN_ERR "spurious ICU interrupt: %04x,%04x\n", pend1, pend2);
>  
> -	atomic_inc(&irq_err_count);
> -
>  	return -1;
>  }
>  
> diff --git a/drivers/gpio/gpio-vr41xx.c b/drivers/gpio/gpio-vr41xx.c
> index 98cd715ccc33..8d09b619c166 100644
> --- a/drivers/gpio/gpio-vr41xx.c
> +++ b/drivers/gpio/gpio-vr41xx.c
> @@ -217,8 +217,6 @@ static int giu_get_irq(unsigned int irq)
>  	printk(KERN_ERR "spurious GIU interrupt: %04x(%04x),%04x(%04x)\n",
>  	       maskl, pendl, maskh, pendh);
>  
> -	atomic_inc(&irq_err_count);
> -
>  	return -EINVAL;
>  }
>  
> -- 
> 2.25.1

applied to mips-fixes.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]