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. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
