[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1236076799.22914.31.camel@twins>
Date: Tue, 03 Mar 2009 11:39:58 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Ingo Molnar <mingo@...e.hu>, David Brownell <david-b@...bell.net>,
Andrew Morton <akpm@...ux-foundation.org>, me@...ipebalbi.com,
linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
felipe.balbi@...ia.com, dmitry.torokhov@...il.com,
sameo@...nedhand.com, tglx@...utronix.de
Subject: Re: lockdep and threaded IRQs (was: ...)
On Tue, 2009-03-03 at 10:30 +0000, Alan Cox wrote:
>
> > So there's no real technical problem here.
>
> In the long term no - but forcing people to make sudden changes to
> critical I/O drivers isn't the right way to do it.
My plan is:
1) find all drivers that do not use IRQF_DISABLED
2) add IRQF_LEGACY_ENABLED to those
3) make IRQF_DISABLED 0 and remove its functionality
while adding IRQF_LEGACY_ENABLED
4) make request_irq() print a warning for IRQF_LEGACY_ENABLED
5) make an actual IRQF_LEGACY_ENABLED irq firing taint the kernel
After that its cleanup time, and I'll try to help out converting some of
these to threaded IRQs where appropriate.
This will not break any driver, nor force sudden change. Stuff will
continue working as expected, just a little more boot noise for those
with crappy drivers/hardware.
--
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