public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>,
	Matthew Wilcox <matthew@wil.cx>,
	David Howells <dhowells@redhat.com>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Russell King <rmk@arm.linux.org.uk>,
	Ian Molton <spyro@f2s.com>
Subject: Re: [PATCH 4/5] Centralise NO_IRQ definition
Date: Tue, 22 Nov 2005 09:06:42 +1100	[thread overview]
Message-ID: <1132610802.26560.44.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.64.0511211339450.13959@g5.osdl.org>


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

It's not the case on various non-x86 architectures, not the case in the
PCI spec neither.

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

And ?

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

That register is mostly useless on a wide range of architectures tho :)

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

No, it's not.

>  - 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 must have lost a lot of neurons in the past few years then.

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

Very few driver bother at all about the irq value. Most don't test it,
they just use it and be done with it, and that's the way it works. Some
drivers, mostly ISA stuff or legacy stuff or drivers that deal with old
weird chipsets actually look at the irq value, and those can be easily
fixed to use NO_IRQ. I really don't understand why you are making such a
fuss about this...



  reply	other threads:[~2005-11-21 22:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-21  1:14 [PATCH 4/5] Centralise NO_IRQ definition Matthew Wilcox
2005-11-21 11:12 ` David Howells
2005-11-21 12:14   ` Matthew Wilcox
2005-11-21 18:55     ` Linus Torvalds
2005-11-21 19:06       ` Matthew Wilcox
2005-11-21 19:27         ` Linus Torvalds
2005-11-21 19:43           ` Matthew Wilcox
2005-11-21 19:59             ` Linus Torvalds
2005-11-21 21:15               ` Ingo Molnar
2005-11-21 21:25                 ` Paul Mackerras
2005-11-21 21:35                   ` Ingo Molnar
2005-11-21 21:51                     ` Linus Torvalds
2005-11-21 22:09                       ` Benjamin Herrenschmidt
2005-11-21 22:34                         ` Linus Torvalds
2005-11-21 23:00                           ` Benjamin Herrenschmidt
2005-11-21 21:49                   ` Linus Torvalds
2005-11-21 22:06                     ` Benjamin Herrenschmidt [this message]
2005-11-21 22:28                       ` Linus Torvalds
2005-11-21 22:58                         ` Benjamin Herrenschmidt
2005-11-21 23:20                     ` Paul Mackerras
2005-11-22  1:26                       ` Linus Torvalds
2005-11-22  2:45                     ` Matthew Wilcox
2005-11-21 21:50                   ` Benjamin Herrenschmidt
2005-11-21 22:20                   ` Alan Cox
2005-11-22 11:13                     ` David Woodhouse
2005-11-22 14:15                       ` Alan Cox
2005-11-22 14:04                         ` Matthew Wilcox
2005-11-22 17:03                         ` Linus Torvalds
2005-11-22 18:20                           ` Matthew Wilcox
2005-11-22 18:37                           ` David Howells
2005-11-22 19:03                             ` David Woodhouse
2005-11-22 19:21                               ` Linus Torvalds
2005-11-22 23:58                                 ` David Woodhouse
2005-11-22 19:05                             ` Linus Torvalds
2005-11-22 19:38                               ` David Howells
2005-11-22 19:51                                 ` Linus Torvalds
2005-11-23  1:45                 ` Pavel Machek
2005-11-21 21:16               ` Benjamin Herrenschmidt
2005-11-21 21:38                 ` Linus Torvalds
2005-11-21 21:53                   ` Benjamin Herrenschmidt
2005-11-21 22:18                     ` Linus Torvalds
2005-11-21 22:20                       ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1132610802.26560.44.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=spyro@f2s.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox