[PATCH] ata: Don't use NO_IRQ in pata_of_platform driver

[Alan Cox]

> 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:

>> 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