[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111206093709.GB2274@linaro.org>
Date: Tue, 6 Dec 2011 09:37:09 +0000
From: Dave Martin <dave.martin@...aro.org>
To: Nicolas Pitre <nicolas.pitre@...aro.org>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Anton Vorontsov <cbouatmailru@...il.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Andrew Morton <akpm@...ux-foundation.org>,
devicetree-discuss@...ts.ozlabs.org,
LKML <linux-kernel@...r.kernel.org>, linux-ide@...r.kernel.org,
Randy Dunlap <rdunlap@...otime.net>,
linux-next@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Jeff Garzik <jgarzik@...hat.com>,
Pawel Moll <pawel.moll@....com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:
[...]
> > > > Unfortunately, NO_IRQ is often not spelled "NO_IRQ". It looks like the assumption
> > > > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > > > Since there's no specific thing we can grep for (and simply due to volume)
> > > > finding all such instances may be quite a bit harder.
> > > [...]
> > >
> > > ARgh.
> > >
> > > My point was about current actual usage of the IRQ numbered 0 which
> > > probably prompted the introduction of NO_IRQ in the first place. What I
> > > was saying is that the number of occurrences where IRQ #0 is currently
> > > used into drivers that would get confused if 0 would mean no IRQ is
> > > probably quite small.
> >
> > Ah, I misunderstood -- that's a separate issue, but also an important one.
> > I guess this applies to a fair number of older boards. One way of fixing
> > this would be to migrate those boards to use irq domains -- but those boards
> > may be sporadically maintained.
> >
> > > But as you illustrated, there is a large number of drivers that already
> > > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.
> > > That is a much bigger problem to fix.
> >
> > My concern is that as soon as we start to change this in significant
> > volume, a _lot_ of stuff is going to break. Everywhere that an irq value
> > is passed from one piece of code to another, there is a potential
> > interface mismatch -- there seems to be no single place where we can
> > apply a conversion and fix everything.
>
> No need to convert everything.
>
> First move is to make irq=0 meaning no IRQ. That means making things
> like:
>
> if (irq < 0)
> if (irq >= 0)
>
> into
>
> if (irq <= 0)
> if (irq > 0)
>
> And replace NO_IRQ with 0.
>
> That change shouldn't break anything, except those drivers which are 1)
> being passed an actual IRQ #0 and 2) testing for no IRQ. I suspect that
> those conditions aren't very common together.
To clarify, you're suggesting that the meanings of all other IRQ values
would not change initially? (i.e., we remap HW irq 0, if there is one,
to some other random number but have a 1:1 mapping for everything else).
That could make sense as an approach.
Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists