lkml.org 
[lkml]   [2011]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
On Tue, Dec 06, 2011 at 09:30:00AM +0000, Dave Martin wrote:
> Do we expect there to be any platform drivers which are shared between
> legacy platforms and newer DT-ised platforms?
>
> Those drivers would be pain points since they would need to understand
> both conventions.
>
> So far as I can see, only boards which are not DT-ised, which do not use
> DT-ised drivers and which do not use drivers which use interrupts and
> are either used by DT-ised boards or by arches with a non-zero NO_IRQ
> could safely carry on using a non-zero NO_IRQ. Tracking down exactly
> which boards and drivers this applies to could be hard. We could have a
> CONFIG_NO_IRQ and make them depend on it, but we still have to find that
> list of boards and drivers in the first place.

You're digging too deeply into this.

Drivers which need to know whether an IRQ is valid need to know this if
they wish to do something different for 'this device doesn't have an IRQ
wired'. These are the drivers which have problems because of the -1 vs
0 thing.

That is different from 'this is an invalid IRQ number', which is what
you find out when you call request_irq().

So please, stop thinking 'we need to convert drivers to check for <= 0'.
We don't. We just need to make sure that we're not passing a zero IRQ
number to any driver.

On platforms where IRQ0 is special like x86, request_irq() will fail
with -EBUSY on drivers which don't care (or other kind of refusal to
initialize), and will cause 'polling mode' with the 8250 driver.

So, all that we need to do is to ensure that all the IRQ chip stuff is
fixed up so that IRQ0 is only used for the same purpose as x86 - the
PIC timer on systems with an ISA 8253 timer. Everything else should
not pass IRQ0 outside core platform code.


\
 
 \ /
  Last update: 2011-12-06 11:59    [W:0.265 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site