Russell, do you know whether it would make sense to set a timeline for 
removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
case?  I'm assuming that this mainly involves migrating existing hard-wired
code that deals with interrupt numbers to use irq domains.

The timelime was several years ago. Several years of complete inaction
later the chickens have come home to roost.

I refer you to Linus mail of 26 Sept 2006 to linux-kernel ('restore
libata build on frv')

Quoting Linus email:

quoted

That's fine -- but don't use zero to mean none. We have NO_IRQ for
that, and zero isn't an appropriate choice.

Zero _is_ an appropriate choice, dammit!

That NO_IRQ thing should be zero, and any architecture that thinks that
zero is a valid IRQ just needs to fix its own irq mapping so that the
"cookie" doesn't work.

The thing is, it's zero. Get over it. It can't be "-1" or some other
random value like people have indicated, because that thing is often read
from places where "-1" simply isn't a possible value (eg it gets its
default value initialized from a "unsigned char" in MMIO space on x86).

So instead of making everybody and their dog to silly things with some
NO_IRQ define that they haven't historically done, the rule is simple: "0"
means "no irq", so that you can test for it with obvious code like

if (!dev->irq)
	..

and then, if your actual _hardware_ things that the bit-pattern with all
bits clear is a valid irq that can be used for normal devices, then what
you do is you add a irq number translation layer (WHICH WE NEED AND HAVE
_ANYWAY_) and make sure that nobody sees that on a _software_ level.

----------

On 15th October 2008 Linus said the following to linux-next

Grr. Can we please just get rid of that IDIOTIC thing instead?

NO_IRQ was a bad idea to begin with. Let's not add more.

I assume that broken driver is some ARM-specific thing. I certainly don't 
want to see NO_IRQ in any general drivers. So instead of having that 
NO_IRQ insanity spread any more, I'd much rather see the driver either 
fixed to not use it, or just marked ARM-only.

The proper way to test for whether an interrupt is valid or not is to do

	if (dev->irq) {
	...
and no other. There is no spoon. That NO_IRQ was insane. And
architectures or drivers that still think otherwise should fix themselves.

------------

So there we are.. ARM spent years ignoring clear direction. If ARM breaks
for a release now so be it. You've had *YEARS* to get off your collective
backsides and sort it out.

I worry that if we just change the convention for the OF case, we'll end
up with OF-ised platform drivers which have to deal with a different no-
irq convention depending on whether they are probed as platform drivers
or through the OF framework ... and these ported or semi-ported drivers
will be intermixed with unported drivers, confusing maintainers

All drivers should assume that  if (!dev->irq) works. Zero is not an IRQ
except in certain buried internal invisible cases in arch code (legacy PC
timer being the obvious one).

Come to think about it we had a prior discussion about NO_IRQ in 2005
even!

The core kernel generic IRQ code knows about zero being special, many
common driver layer components such as serial and network phylib do, so
if anything it's going to fix bugs sorting the mess out on ARM.

Jut fix it. Other platforms have done so without problem.

Alan