lkml.org 
[lkml]   [2005]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/5] Centralise NO_IRQ definition


On Tue, 22 Nov 2005, Paul Mackerras wrote:
>
> Yes, G5 powermacs have the SATA controller on irq 0. So if we can't
> use irq 0, I can't get to my hard disk. :) Other powermacs also use
> irq 0 for various things, as do embedded PPC machines.

That doesn't change any of the logic. There already is no "1:1" mapping of
PCI interrupts to what the machine does.

On all PC hardware, having a zero in the PCI irq register basically means
that no irq is enabled. That's a _fact_. It's a fact however much you may
not like it. It's how the hardware comes up, and it's how the BIOS leaves
it. So "0" absolutely does mean "not allocated".

Now, the second part of the story is that when it comes to PCI, it doesn't
matter what Apple, Sun, or pretty much anybody else has done. The reason
PCI has a separate MMIO and IO space is that it comes from a PC
background, and the reason Apple and others use PCI is that through that,
there are thousands of controller cards that are sold for PC's that also
happen to work on non-PC's.

So PC usage really is a defining part of PCI. It's what defines basically
_all_ of the testing, even under Linux.

So let's face those facts:
- we have a 8-bit register (0-255) for firmware telling the kernel what
the pre-allocated interrupt is.
- all of those 256 numbers _may_ in fact be valid on some piece of
hardware.
- only one of those numbers (0) is de-facto the "no irq line set up"
value.
- pretty much all drivers have been tested mainly with 0 being the "no
irq" value.

Those are FACTS. Denying them is a sign of stupidity.

I'd suggest that if some architecture can't live with those facts, it
either:

- define it's own PCI_NO_IRQ value, and face the fact that it will have
to test the drivers and hope they work (and that a lot of them simply
will _not_ work).

This is what we have today. It mostly works. Maybe we shouldn't change
it.

- realize that 0 is special, and use another number for when firmware
tells it 0 _is_ actually a valid irq (maybe 256. Maybe "1u<<31". I
don't care.)

And I won't apply the "turn PCI_NO_IRQ" into -1 generally, because I
consider it to be strictly _worse_ than what we have now.

Comprende?

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.143 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site