[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091129102635.GA22653@pengutronix.de>
Date: Sun, 29 Nov 2009 11:26:35 +0100
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Jamie Lokier <jamie@...reable.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Rusty Russell <rusty@...tcorp.com.au>,
David Brownell <dbrownell@...rs.sourceforge.net>,
Eric Miao <eric.y.miao@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
John Stultz <johnstul@...ibm.com>,
Nicolas Pitre <nico@...vell.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] warn about shared irqs requesting IRQF_DISABLED
registered with setup_irq
Hello,
On Sun, Nov 29, 2009 at 02:31:18AM +0000, Jamie Lokier wrote:
> Thomas Gleixner wrote:
> > What about analysing the code and verifying that the setup order is
> > correct ?
> >
> > Adding save/restore_irq just because you have no clue what the code
> > does is utter nonsense.
>
> Wouldn't it be quite a lot nicer if generic setup moved the
> IRQF_DISABLED handler to be first in the list, if that actually works
> in a useful way rather than simply being a quirk that irqs are
> disabled for the first one?
Hmm, what happens if an ISR runs with irqs disabled even though it
doesn't expect it? I wouldn't bet that nothing breaks.
IMHO the best is if a warning is printed or registering fails if shared
irq actions don't agree about wanting IRQF_DISABLED.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists