Patchwork [01/14] rtc: ab8500-rtc: IRQF_ONESHOT when requesting a threaded IRQ

login
register
mail settings
Submitter Lee Jones
Date June 12, 2012, 8:57 a.m.
Message ID <4FD70481.6020207@linaro.org>
Download mbox | patch
Permalink /patch/164353/
State New
Headers show

Comments

Lee Jones - June 12, 2012, 8:57 a.m.
From: Lee Jones <lee.jones@linaro.org>
Date: Tue, 22 May 2012 15:25:09 +0100
Subject: [PATCH 01/14] rtc: ab8500-rtc: IRQF_ONESHOT when requesting a
 threaded IRQ

The kernel now forces IRQs to be ONESHOT if no IRQ handler is passed.

Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: rtc-linux@googlegroups.com
Cc: stable@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/rtc/rtc-ab8500.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Andrew Morton - June 13, 2012, 10:25 p.m.
On Tue, 12 Jun 2012 09:57:37 +0100
Lee Jones <lee.jones@linaro.org> wrote:

> The kernel now forces IRQs to be ONESHOT if no IRQ handler is passed.

What does this mean.  The kernel crashes?  The registration fails?  A
warning is emitted?

When fixing a bug, please fully describe the consequences of that bug.

> Cc: stable@vger.kernel.org

Especially when suggesting a -stable backport.
Lee Jones - June 14, 2012, 7:14 a.m.
On 13/06/12 23:25, Andrew Morton wrote:
> On Tue, 12 Jun 2012 09:57:37 +0100
> Lee Jones<lee.jones@linaro.org>  wrote:
>
>> The kernel now forces IRQs to be ONESHOT if no IRQ handler is passed.
>
> What does this mean.  The kernel crashes?  The registration fails?  A
> warning is emitted?
>
> When fixing a bug, please fully describe the consequences of that bug.
>
>> Cc: stable@vger.kernel.org
>
> Especially when suggesting a -stable backport.

No problem. I'll try to remember that for next time.

I see that you've taken the patch into your tree however. So do you want 
me to update the commit log and resubmit, or are you going to 'let this 
one slide'?
Andrew Morton - June 14, 2012, 7:30 a.m.
On Thu, 14 Jun 2012 08:14:49 +0100 Lee Jones <lee.jones@linaro.org> wrote:

> On 13/06/12 23:25, Andrew Morton wrote:
> > On Tue, 12 Jun 2012 09:57:37 +0100
> > Lee Jones<lee.jones@linaro.org>  wrote:
> >
> >> The kernel now forces IRQs to be ONESHOT if no IRQ handler is passed.
> >
> > What does this mean.  The kernel crashes?  The registration fails?  A
> > warning is emitted?
> >
> > When fixing a bug, please fully describe the consequences of that bug.
> >
> >> Cc: stable@vger.kernel.org
> >
> > Especially when suggesting a -stable backport.
> 
> No problem. I'll try to remember that for next time.
> 
> I see that you've taken the patch into your tree however. So do you want 
> me to update the commit log and resubmit, or are you going to 'let this 
> one slide'?

Please read my emails - they're very nice!  "What does this mean.  The
kernel crashes?  The registration fails?  A warning is emitted?".  You
answer that, I copy-n-paste into changelog and we're done.
Lee Jones - June 14, 2012, 8:02 a.m.
On 14/06/12 08:30, Andrew Morton wrote:
> On Thu, 14 Jun 2012 08:14:49 +0100 Lee Jones<lee.jones@linaro.org>  wrote:
> 
>> On 13/06/12 23:25, Andrew Morton wrote:
>>> On Tue, 12 Jun 2012 09:57:37 +0100
>>> Lee Jones<lee.jones@linaro.org>   wrote:
>>>
>>>> The kernel now forces IRQs to be ONESHOT if no IRQ handler is passed.
>>>
>>> What does this mean.  The kernel crashes?  The registration fails?  A
>>> warning is emitted?
>>>
>>> When fixing a bug, please fully describe the consequences of that bug.
>>>
>>>> Cc: stable@vger.kernel.org
>>>
>>> Especially when suggesting a -stable backport.
>>
>> No problem. I'll try to remember that for next time.
>>
>> I see that you've taken the patch into your tree however. So do you want
>> me to update the commit log and resubmit, or are you going to 'let this
>> one slide'?
> 
> Please read my emails - they're very nice!  "What does this mean.  The
> kernel crashes?  The registration fails?  A warning is emitted?".  You
> answer that, I copy-n-paste into changelog and we're done.

Ah, you're a star!

Registration fails:

> __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
> {
<snip>
> 	if (new->flags & IRQF_ONESHOT) {
<snip>
> 	} else if (new->handler == irq_default_primary_handler) {
> 		/*
> 		 * The interrupt was requested with handler = NULL, so
> 		 * we use the default primary handler for it. But it
> 		 * does not have the oneshot flag set. In combination
> 		 * with level interrupts this is deadly, because the
> 		 * default primary handler just wakes the thread, then
> 		 * the irq lines is reenabled, but the device still
> 		 * has the level irq asserted. Rinse and repeat....
> 		 *
> 		 * While this works for edge type interrupts, we play
> 		 * it safe and reject unconditionally because we can't
> 		 * say for sure which type this interrupt really
> 		 * has. The type flags are unreliable as the
> 		 * underlying chip implementation can override them.
> 		 */
> 		pr_err("Threaded irq requested with handler=NULL and !ONESHOT for irq %d\n", irq);
> 		ret = -EINVAL;
> 		goto out_mask;
> 	}
<snip>

Patch

diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
index 4bcf9ca..b11a2ec 100644
--- a/drivers/rtc/rtc-ab8500.c
+++ b/drivers/rtc/rtc-ab8500.c
@@ -422,7 +422,7 @@  static int __devinit ab8500_rtc_probe(struct platform_device *pdev)
 	}
 
 	err = request_threaded_irq(irq, NULL, rtc_alarm_handler,
-		IRQF_NO_SUSPEND, "ab8500-rtc", rtc);
+		IRQF_NO_SUSPEND | IRQF_ONESHOT, "ab8500-rtc", rtc);
 	if (err < 0) {
 		rtc_device_unregister(rtc);
 		return err;