[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <921FE7F4-279D-4470-982A-18A871D6209C@mac.com>
Date: Sat, 30 Sep 2006 12:20:21 -0500
From: Mark Rustad <mrustad@....com>
To: Matthew Wilcox <matthew@....cx>
Cc: James Bottomley <James.Bottomley@...elEye.com>,
Frederik Deweerdt <deweerdt@...e.fr>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
"J.A. Magall??n" <jamagallon@....com>,
Andrew Morton <akpm@...l.org>,
"Linux-Kernel," <linux-kernel@...r.kernel.org>,
linux-scsi@...r.kernel.org
Subject: Re: 2.6.18-mm2
On Sep 30, 2006, at 11:21 AM, Matthew Wilcox wrote:
> On Sat, Sep 30, 2006 at 10:26:22AM -0500, James Bottomley wrote:
>> On Fri, 2006-09-29 at 23:50 +0000, Frederik Deweerdt wrote:
>>> + if (!pdev->irq)
>>> + return -ENODEV;
>>> +
>>
>> Don't I remember that 0 is a valid IRQ on some platforms?
>>
>> i.e. shouldn't this be
>>
>> if (pdev->irq == NO_IRQ)
>> return -ENODEV;
>>
>> ?
>>
>> I think this won't quite work because only the platforms that
>> actually
>> have a valid zero irq define it, but there must be something else
>> that
>> works.
>
> Linus threw a hissy fit and declared that platforms which use 0 as a
> valid IRQ are broken and wrong. Despite PCI using 255 to mean no IRQ
> and 0 as a valid IRQ ;-)
Having gone down the path of creating a platform that had IRQ 0 as a
valid interrupt some time ago with the 2.4 kernel, all I can say is
that while it can be made to work, things go much more smoothly if
you don't use IRQ 0. Every driver added to the environment pretty
much had to be tweaked. Of course that mainly meant adding to the
#ifdef's that were already there for other architectures that had
also made that mistake.
The biggest pain is admitting the mistake (of using IRQ 0) and
changing it. Making a clear statement on the issue will help prevent
others from making the same mistake again. I know that I wish that I
had known not to do that from the beginning. Having been there and
done that, I don't need any convincing.
--
Mark Rustad, MRustad@....com
-
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