On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:

On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:

quoted

On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin [off-list ref] wrote:

quoted

This is now broken on ARM where, for good or bad, NO_IRQ currently is
used and is -1.

How do we resolve it?  If we are ready to eliminate NO_IRQ from
drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
that case, we should surely just do it... but I'm not confident I can
judge on that.

Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
as you notice breakage.

Agreed. In fact the whole hack in drivers/of/irq.c was to accomodate ARM
which still uses -1, powerpc changed to 0 a long time ago.

Now that we have a generic remapper between HW and "linux" IRQ numbers,
there is no reason to stick to -1 even on ARM.

quoted

Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
around as a marker of brokenness), just start removing it from all the
ARM drivers that use the OF infrastructure. Which is presumably not
all that many yet.

So whenever you find breakage, the fix now is to just remove NO_IRQ
tests, and replace them with "!irq".

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.

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.
 
If board code starts initialising platform data for non-OF-ised platform
drivers based on IRQ numbers fetched via the OF code, things will get
even more confused...

Cheers
---Dave