Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, Sep 2, 2016 at 3:46 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>
> Arm seems to define NO_IRQ. This is not available in other arch and one
> driver (moxart-dma) is using it. I don't see why this should be arm specific.

NO_IRQ is broken. We long long since agreed that 0 is "no irq", and
that the right way to test for it is just

   if (!irq) ...

which is what all the generic drivers use.

See for example

   git grep '(!.*irq)'

for how common that is.

(If you grep for NO_IRQ, you'll find a lot in particularly powerpc
drivers and platforms, but there NO_IRQ is actually just defined to
(0), so it ends up being the same thing).

The fact that ARM still has a NO_IRQ that seems to be defined to
((unsigned int)-1) just means that there are bugs hiding: if ARM
actually _uses_ that value for "no IRQ", then all the generic drivers
will be broken, and if ARM core doesn't, then the drivers that still
use NO_IRQ are broken. Either way you can't win.

So please make sure that NO_IRQ goes away entirely (or, if you insist
on having the confusing #define for some legacy reason, make it be 0
like powerpc, so that the real way of just testing "!irq" also works)

Some people have said "..but but but I have a real irq that has the
value 0", but that's irrelevant - the kernel "irq" value isn't
necessarily the same as the value that an interrupt _controller_ sees,
since the interrupt controller can be hiding behind various other
nested controllers etc. So an architecture might need to translate
"irq" into the actual hw interrupt controller value.

             Linus