handler/ interrupt controller entry). It is low level code and the function expects that interrupts are disabled at entry point.
This isn't the case for invocations from tasklets, workqueues or the primary interrupt handler on PREEMPT_RT. Once this gets noticed a "local_irq_disable|safe()" is added. To avoid further confusion this series adds generic_handle_irq_safe() which can be used from any context and adds a few user.
v2…v4: - Correct kernel doc for generic_handle_irq_safe() as per Wolfram Sang. - Use "misc" instead of "mfd" for the hi6421-spmi-pmic driver.
v2…v1: https://lore.kernel.org/all/20220131123404.175438-1-bigeasy@linutronix.de/ - Redo kernel-doc for generic_handle_irq_safe() in #1. - Use generic_handle_irq_safe() instead of generic_handle_irq() in the patch description where I accidently used the wrong one. v1: https://lore.kernel.org/all/20220127113303.3012207-1-bigeasy@linutronix.de/
Provide generic_handle_irq_safe() which can used from any context.
Suggested-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de Reviewed-by: Hans de Goede hdegoede@redhat.com Reviewed-by: Oleksandr Natalenko oleksandr@natalenko.name Reviewed-by: Wolfram Sang wsa+renesas@sang-engineering.com --- include/linux/irqdesc.h | 1 + kernel/irq/irqdesc.c | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+)
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h index 93d270ca0c567..a77584593f7d1 100644 --- a/include/linux/irqdesc.h +++ b/include/linux/irqdesc.h @@ -160,6 +160,7 @@ static inline void generic_handle_irq_desc(struct irq_desc *desc)
int handle_irq_desc(struct irq_desc *desc); int generic_handle_irq(unsigned int irq); +int generic_handle_irq_safe(unsigned int irq);
#ifdef CONFIG_IRQ_DOMAIN /* diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index 2267e6527db3c..346d283d2da14 100644 --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -662,6 +662,29 @@ int generic_handle_irq(unsigned int irq) } EXPORT_SYMBOL_GPL(generic_handle_irq);
+/** + * generic_handle_irq_safe - Invoke the handler for a particular irq from any + * context. + * @irq: The irq number to handle + * + * Returns: 0 on success, a negative value on error. + * + * This function can be called from any context (IRQ or process context). It + * will report an error if not invoked from IRQ context and the irq has been + * marked to enforce IRQ-context only. + */ +int generic_handle_irq_safe(unsigned int irq) +{ + unsigned long flags; + int ret; + + local_irq_save(flags); + ret = handle_irq_desc(irq_to_desc(irq)); + local_irq_restore(flags); + return ret; +} +EXPORT_SYMBOL_GPL(generic_handle_irq_safe); + #ifdef CONFIG_IRQ_DOMAIN /** * generic_handle_domain_irq - Invoke the handler for a HW irq belonging
The i2c-i801 driver invokes i2c_handle_smbus_host_notify() from his interrupt service routine. On PREEMPT_RT i2c-i801's handler is forced threaded with enabled interrupts which leads to a warning by handle_irq_event_percpu() assuming that irq_default_primary_handler() enabled interrupts.
i2c-i801's interrupt handler can't be made non-threaded because the interrupt line is shared with other devices.
Use generic_handle_irq_safe() which can invoked with disabled and enabled interrupts.
Reported-by: Michael Below below@judiz.de Link: https://bugs.debian.org/1002537 Cc: Salvatore Bonaccorso carnil@debian.org Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de Reviewed-by: Oleksandr Natalenko oleksandr@natalenko.name Acked-by: Wolfram Sang wsa@kernel.org --- drivers/i2c/i2c-core-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 2c59dd748a49f..3f9e5303b6163 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1424,7 +1424,7 @@ int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short addr) if (irq <= 0) return -ENXIO;
- generic_handle_irq(irq); + generic_handle_irq_safe(irq);
return 0; }
On Fri, Feb 11, 2022 at 07:14:55PM +0100, Sebastian Andrzej Siewior wrote:
The i2c-i801 driver invokes i2c_handle_smbus_host_notify() from his interrupt service routine. On PREEMPT_RT i2c-i801's handler is forced threaded with enabled interrupts which leads to a warning by handle_irq_event_percpu() assuming that irq_default_primary_handler() enabled interrupts.
i2c-i801's interrupt handler can't be made non-threaded because the interrupt line is shared with other devices.
Use generic_handle_irq_safe() which can invoked with disabled and enabled interrupts.
Reported-by: Michael Below below@judiz.de Link: https://bugs.debian.org/1002537 Cc: Salvatore Bonaccorso carnil@debian.org Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de Reviewed-by: Oleksandr Natalenko oleksandr@natalenko.name Acked-by: Wolfram Sang wsa@kernel.org
Is this 5.17 material? Or is 5.18 fine, too?
On 2022-02-23 14:21:32 [+0100], Wolfram Sang wrote:
Is this 5.17 material? Or is 5.18 fine, too?
5.18 is fine. I intend to push into the RT-stable trees and this can't be backported without 1/7 and it does not affect !RT so I wouldn't bother.
Sebastian
On Fri, Feb 25, 2022 at 11:26:46PM +0100, Sebastian Andrzej Siewior wrote:
On 2022-02-23 14:21:32 [+0100], Wolfram Sang wrote:
Is this 5.17 material? Or is 5.18 fine, too?
5.18 is fine. I intend to push into the RT-stable trees and this can't be backported without 1/7 and it does not affect !RT so I wouldn't bother.
Ok, applied to for-next then. Thanks for the heads up!
Instead of manually disabling interrupts before invoking use generic_handle_irq_safe() which can be invoked with enabled and disabled interrupts.
Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de Reviewed-by: Hans de Goede hdegoede@redhat.com Acked-by: Wolfram Sang wsa@kernel.org --- drivers/i2c/busses/i2c-cht-wc.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c index 1cf68f85b2e11..8ccf0c928bb44 100644 --- a/drivers/i2c/busses/i2c-cht-wc.c +++ b/drivers/i2c/busses/i2c-cht-wc.c @@ -99,15 +99,8 @@ static irqreturn_t cht_wc_i2c_adap_thread_handler(int id, void *data) * interrupt handler as well, so running the client irq handler from * this thread will cause things to lock up. */ - if (reg & CHT_WC_EXTCHGRIRQ_CLIENT_IRQ) { - /* - * generic_handle_irq expects local IRQs to be disabled - * as normally it is called from interrupt context. - */ - local_irq_disable(); - generic_handle_irq(adap->client_irq); - local_irq_enable(); - } + if (reg & CHT_WC_EXTCHGRIRQ_CLIENT_IRQ) + generic_handle_irq_safe(adap->client_irq);
return IRQ_HANDLED; }
On Fri, Feb 11, 2022 at 07:14:56PM +0100, Sebastian Andrzej Siewior wrote:
Instead of manually disabling interrupts before invoking use generic_handle_irq_safe() which can be invoked with enabled and disabled interrupts.
Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de Reviewed-by: Hans de Goede hdegoede@redhat.com Acked-by: Wolfram Sang wsa@kernel.org
Applied to for-next, thanks!
generic_handle_irq() is invoked from a regular interrupt service routine. This handler will become a forced-threaded handler on PREEMPT_RT and will be invoked with enabled interrupts. The generic_handle_irq() must be invoked with disabled interrupts in order to avoid deadlocks.
Instead of manually disabling interrupts before invoking use generic_handle_irq_safe() which can be invoked with enabled and disabled interrupts.
Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de --- drivers/misc/hi6421v600-irq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/hi6421v600-irq.c b/drivers/misc/hi6421v600-irq.c index 1c763796cf1fa..caa3de37698b0 100644 --- a/drivers/misc/hi6421v600-irq.c +++ b/drivers/misc/hi6421v600-irq.c @@ -117,8 +117,8 @@ static irqreturn_t hi6421v600_irq_handler(int irq, void *__priv) * If both powerkey down and up IRQs are received, * handle them at the right order */ - generic_handle_irq(priv->irqs[POWERKEY_DOWN]); - generic_handle_irq(priv->irqs[POWERKEY_UP]); + generic_handle_irq_safe(priv->irqs[POWERKEY_DOWN]); + generic_handle_irq_safe(priv->irqs[POWERKEY_UP]); pending &= ~HISI_IRQ_POWERKEY_UP_DOWN; }
@@ -126,7 +126,7 @@ static irqreturn_t hi6421v600_irq_handler(int irq, void *__priv) continue;
for_each_set_bit(offset, &pending, BITS_PER_BYTE) { - generic_handle_irq(priv->irqs[offset + i * BITS_PER_BYTE]); + generic_handle_irq_safe(priv->irqs[offset + i * BITS_PER_BYTE]); } }
Instead of manually disabling interrupts before invoking use generic_handle_irq_safe() which can be invoked with enabled and disabled interrupts.
Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de --- drivers/mfd/ezx-pcap.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mfd/ezx-pcap.c b/drivers/mfd/ezx-pcap.c index 70fa18b04ad2b..b14d3f98e1ebd 100644 --- a/drivers/mfd/ezx-pcap.c +++ b/drivers/mfd/ezx-pcap.c @@ -193,13 +193,11 @@ static void pcap_isr_work(struct work_struct *work) ezx_pcap_write(pcap, PCAP_REG_MSR, isr | msr); ezx_pcap_write(pcap, PCAP_REG_ISR, isr);
- local_irq_disable(); service = isr & ~msr; for (irq = pcap->irq_base; service; service >>= 1, irq++) { if (service & 1) - generic_handle_irq(irq); + generic_handle_irq_safe(irq); } - local_irq_enable(); ezx_pcap_write(pcap, PCAP_REG_MSR, pcap->msr); } while (gpio_get_value(pdata->gpio)); }
Instead of manually disabling interrupts before invoking use generic_handle_irq_safe() which can be invoked with enabled and disabled interrupts.
Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de --- drivers/net/usb/lan78xx.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c index b8e20a3f2b84e..415f16662f88e 100644 --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -1537,11 +1537,8 @@ static void lan78xx_status(struct lan78xx_net *dev, struct urb *urb) netif_dbg(dev, link, dev->net, "PHY INTR: 0x%08x\n", intdata); lan78xx_defer_kevent(dev, EVENT_LINK_RESET);
- if (dev->domain_data.phyirq > 0) { - local_irq_disable(); - generic_handle_irq(dev->domain_data.phyirq); - local_irq_enable(); - } + if (dev->domain_data.phyirq > 0) + generic_handle_irq_safe(dev->domain_data.phyirq); } else { netdev_warn(dev->net, "unexpected interrupt: 0x%08x\n", intdata);
Instead of manually disabling interrupts before invoking use generic_handle_irq_safe() which can be invoked with enabled and disabled interrupts.
Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de Acked-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Acked-by: Johan Hovold johan@kernel.org --- drivers/staging/greybus/gpio.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c index 7e6347fe93f99..8a7cf1d0e9688 100644 --- a/drivers/staging/greybus/gpio.c +++ b/drivers/staging/greybus/gpio.c @@ -391,10 +391,7 @@ static int gb_gpio_request_handler(struct gb_operation *op) return -EINVAL; }
- local_irq_disable(); - ret = generic_handle_irq(irq); - local_irq_enable(); - + ret = generic_handle_irq_safe(irq); if (ret) dev_err(dev, "failed to invoke irq handler\n");
On Fri, 11 Feb 2022, Sebastian Andrzej Siewior wrote:
handler/ interrupt controller entry). It is low level code and the function expects that interrupts are disabled at entry point.
This isn't the case for invocations from tasklets, workqueues or the primary interrupt handler on PREEMPT_RT. Once this gets noticed a "local_irq_disable|safe()" is added. To avoid further confusion this series adds generic_handle_irq_safe() which can be used from any context and adds a few user.
v2…v4:
- Correct kernel doc for generic_handle_irq_safe() as per Wolfram Sang.
- Use "misc" instead of "mfd" for the hi6421-spmi-pmic driver.
v2…v1: https://lore.kernel.org/all/20220131123404.175438-1-bigeasy@linutronix.de/
- Redo kernel-doc for generic_handle_irq_safe() in #1.
- Use generic_handle_irq_safe() instead of generic_handle_irq() in the patch description where I accidently used the wrong one.
v1: https://lore.kernel.org/all/20220127113303.3012207-1-bigeasy@linutronix.de/
Please use the official cover-letter format (--cover-letter).
It would have been nice to at least find a diff stat here.
...
Do we really need to coordinate this series cross-subsystem?
Can we first apply the API, then have each of the subsystems adapted separately? Does the change-over all need to happen concurrently?
If the latter is the case, is this set bisectable?
On Tue, 15 Feb 2022, Sebastian Andrzej Siewior wrote:
On 2022-02-15 14:36:01 [+0000], Lee Jones wrote:
Do we really need to coordinate this series cross-subsystem?
I would suggest to merge it via irq subsystem but I leave the logistics to tglx.
Could you answer by other questions too please?
On 2022-02-15 15:16:36 [+0000], Lee Jones wrote:
On Tue, 15 Feb 2022, Sebastian Andrzej Siewior wrote:
On 2022-02-15 14:36:01 [+0000], Lee Jones wrote:
Do we really need to coordinate this series cross-subsystem?
I would suggest to merge it via irq subsystem but I leave the logistics to tglx.
Could you answer by other questions too please?
I don't think that I can answer them. I said I leave the logistics to tglx.
This can go via one merge via irq. This can also go differently i.e. feature branch on top of 5.17-rc1 (with 1/7) which is merge into each subsystem and then the "feature" on top.
Either way it remains bisect-able since each driver is changed individually. There is no need to merge them in one go but since it is that small it probably makes sense. But I don't do the logistics here.
Sebastian
On Tue, 15 Feb 2022, Sebastian Andrzej Siewior wrote:
On 2022-02-15 15:16:36 [+0000], Lee Jones wrote:
On Tue, 15 Feb 2022, Sebastian Andrzej Siewior wrote:
On 2022-02-15 14:36:01 [+0000], Lee Jones wrote:
Do we really need to coordinate this series cross-subsystem?
I would suggest to merge it via irq subsystem but I leave the logistics to tglx.
Could you answer by other questions too please?
I don't think that I can answer them. I said I leave the logistics to tglx.
This can go via one merge via irq. This can also go differently i.e. feature branch on top of 5.17-rc1 (with 1/7) which is merge into each subsystem and then the "feature" on top.
Apologies for the confusion.
I'm not asking you about merge strategies.
We can handle that without issue.
Either way it remains bisect-able since each driver is changed individually. There is no need to merge them in one go but since it is that small it probably makes sense. But I don't do the logistics here.
Okay, this is what I was asking.
So there aren't any hard dependencies between the driver changes?
Only the drivers are dependent on the API.
So, if we choose to do so, we can merge the API and then subsequently add the users one by one into their respective subsystem, in any order. This would save on creating an immutable topic branch which we all pull from.
What is your preference Thomas?
Lee,
On Tue, Feb 15 2022 at 15:42, Lee Jones wrote:
On Tue, 15 Feb 2022, Sebastian Andrzej Siewior wrote:
Either way it remains bisect-able since each driver is changed individually. There is no need to merge them in one go but since it is that small it probably makes sense. But I don't do the logistics here.
Okay, this is what I was asking.
So there aren't any hard dependencies between the driver changes?
Only the drivers are dependent on the API.
Correct.
So, if we choose to do so, we can merge the API and then subsequently add the users one by one into their respective subsystem, in any order. This would save on creating an immutable topic branch which we all pull from.
What is your preference Thomas?
I suggest doing it the following way:
1) I apply 1/7 on top of -rc5 and tag it
2) Driver maintainers who want to merge via their trees pull that tag apply the relevant driver changes
3) I collect the leftovers and merge them via irq/core
Does that make sense?
Thanks,
tglx
Lee & al!
On Mon, Feb 21 2022 at 10:57, Thomas Gleixner wrote:
On Tue, Feb 15 2022 at 15:42, Lee Jones wrote:
What is your preference Thomas?
I suggest doing it the following way:
- I apply 1/7 on top of -rc5 and tag it
That's what I did now. The tag to pull from is:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-api-2022-02-21
Driver maintainers who want to merge via their trees pull that tag apply the relevant driver changes
I collect the leftovers and merge them via irq/core
So everyone who wants to merge the relevant driver changes, please pull and let me know which driver patch(es) you merged. I'll pick up the leftovers after -rc6.
Thanks,
tglx
On Mon, 21 Feb 2022, Thomas Gleixner wrote:
Lee & al!
On Mon, Feb 21 2022 at 10:57, Thomas Gleixner wrote:
On Tue, Feb 15 2022 at 15:42, Lee Jones wrote:
What is your preference Thomas?
I suggest doing it the following way:
- I apply 1/7 on top of -rc5 and tag it
That's what I did now. The tag to pull from is:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-api-2022-02-21
Driver maintainers who want to merge via their trees pull that tag apply the relevant driver changes
I collect the leftovers and merge them via irq/core
So everyone who wants to merge the relevant driver changes, please pull and let me know which driver patch(es) you merged. I'll pick up the leftovers after -rc6.
Ideal. Thanks Thomas.
-
Lee Jones -
Sebastian Andrzej Siewior -
Thomas Gleixner -
Wolfram Sang