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

[dave.martin@linaro.org (Dave Martin)]

On Mon, Dec 05, 2011 at 02:47:29PM -0600, Rob Herring wrote:
> On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> > [...]
> >> At least for DT enabled platforms, we could force "no irq" to be 0 in
> >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> > 
> > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> > dev->irq and thus the thing that we pass into request_irq() is a
> > virtual IRQ thing, a "cookie".
> > 
> > While in device tree you see real HW IRQ numbers.
> > 
> > Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> > 
> 
> If this was all true, then there would be no discussion.
> 
> This is what we are working towards, but irq_chips all over the arm tree
> do not support any translation or have base fixed at compile time. Only
> a few have been converted. And some ARM platforms may never get
> converted to DT.
> 
> >> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
> >> should be fine currently as it doesn't use the of_irq_* functions to get
> >> the timer irq, but that is an issue as it skips any translation.
> >> VersatileAB should be okay with the VIC irqdomain support.
> > 
> > It shouldn't be an issue to use of_irq_*() functions for these IRQs.
> > of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
> > this currently, then it's a bug and should be fixed.
> 
> I think that's what I'm saying. It's either a bug or incomplete DT
> conversion for the platform. Either way, those should get fixed first.

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.


Otherwise, it feels like we might need a strategy for migrating pretty
much everything if we don't want to end up in a mess.

Cheers
---Dave