[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZFtK3DydE24Qijle@surfacebook>
Date: Wed, 10 May 2023 10:42:20 +0300
From: andy.shevchenko@...il.com
To: Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc: linus.walleij@...aro.org, brgl@...ev.pl, mkshah@...eaurora.org,
Ben Brown <ben.brown@...iedtelesis.co.nz>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpiolib: Don't implicitly disable irq when masking
Wed, May 10, 2023 at 12:11:51PM +1200, Chris Packham kirjoitti:
> When preparing to kexec into a new kernel the kexec code will mask all
> interrupts for all interrupt domains before disabling them. In the case
> of a gpio chip which has a mix of gpio and irq pins a warning would be
> triggered as follows
> [root@...alhost ~]# echo c >/proc/sysrq-trigger
Besides the very noisy traceback in the commit message (read
https://kernel.org/doc/html/latest/process/submitting-patches.html#backtraces-in-commit-messages)
see below.
> This is because gpiochip_irq_mask was being used to mask all possible
We refer to the functions in the form as follows gpiochip_irq_mask().
> irqs in the domain but gpiochip_disable_irq will WARN if any of those
IRQs
gpiochip_disable_irq()
> gpios haven't been requested as interrupts yet. Remove the call to
GPIOs
> gpiochip_disable_irq to stop the warning.
gpiochip_disable_irq()
> Fixes: a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable")
> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> ---
> drivers/gpio/gpiolib.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 8c041a8dd9d8..903f5185ae55 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1451,7 +1451,6 @@ static void gpiochip_irq_mask(struct irq_data *d)
>
> if (gc->irq.irq_mask)
> gc->irq.irq_mask(d);
> - gpiochip_disable_irq(gc, d->hwirq);
> }
At the same time the gpiochip_irq_unmask() has the symmetrical call. Why?
Also it's obvious that you have used outdated repository. You need to rebase
against subsystem tree for-next branch.
P.S. It's also makes sense to Cc to Marc Zyngier <maz@...nel.org>.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists