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/[email protected]/
- 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/[email protected]/
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 <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Johan Hovold <[email protected]>
---
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");
--
2.34.1
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 <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
---
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;
}
--
2.34.1
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 <[email protected]>
---
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);
--
2.34.1
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 <[email protected]>
---
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));
}
--
2.34.1
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/[email protected]/
> - 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/[email protected]/
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?
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
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?
--
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
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 Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
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.
Sebastian
On 2022-02-15 15:42:13 [+0000], Lee Jones wrote:
> So there aren't any hard dependencies between the driver changes?
Correct. #2 - #7 depend on #1. The order of #2+ is not relevant.
Sebastian
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:
>
> 1) 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
> 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
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:
> >
> > 1) 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
>
> > 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
>
> 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 [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
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
> 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
Thanks! Pulled into i2c/for-mergewindow.
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 <[email protected]>
> Reviewed-by: Hans de Goede <[email protected]>
> Acked-by: Wolfram Sang <[email protected]>
Applied to for-next, thanks!
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 83d9b7e3955d32d3e4e3321029f655716cb21c99
Gitweb: https://git.kernel.org/tip/83d9b7e3955d32d3e4e3321029f655716cb21c99
Author: Sebastian Andrzej Siewior <[email protected]>
AuthorDate: Fri, 11 Feb 2022 19:14:58 +01:00
Committer: Thomas Gleixner <[email protected]>
CommitterDate: Wed, 02 Mar 2022 22:28:50 +01:00
mfd: ezx-pcap: Use generic_handle_irq_safe().
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 <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
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 70fa18b..b14d3f9 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));
}
The following commit has been merged into the irq/core branch of tip:
Commit-ID: bfe6b967948c251955bcf175cb2d4e8d169102ca
Gitweb: https://git.kernel.org/tip/bfe6b967948c251955bcf175cb2d4e8d169102ca
Author: Sebastian Andrzej Siewior <[email protected]>
AuthorDate: Fri, 11 Feb 2022 19:14:59 +01:00
Committer: Thomas Gleixner <[email protected]>
CommitterDate: Wed, 02 Mar 2022 22:28:50 +01:00
net: usb: lan78xx: Use generic_handle_irq_safe().
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 <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Woojung Huh <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Jakub Kicinski <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
---
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 b8e20a3..415f166 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);
The following commit has been merged into the irq/core branch of tip:
Commit-ID: ff8dcfebe08dfb2524041116d4afce53ffe0b015
Gitweb: https://git.kernel.org/tip/ff8dcfebe08dfb2524041116d4afce53ffe0b015
Author: Sebastian Andrzej Siewior <[email protected]>
AuthorDate: Fri, 11 Feb 2022 19:15:00 +01:00
Committer: Thomas Gleixner <[email protected]>
CommitterDate: Wed, 02 Mar 2022 22:28:51 +01:00
staging: greybus: gpio: Use generic_handle_irq_safe().
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 <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Johan Hovold <[email protected]>
Cc: Alex Elder <[email protected]>
Cc: Rui Miguel Silva <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
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 7e6347f..8a7cf1d 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");