From: David Howells <dhowells@redhat.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Woodhouse <dwmw2@infradead.org>,
Jeff Garzik <jgarzik@pobox.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
David Howells <dhowells@redhat.com>,
Al Viro <viro@ftp.linux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] restore libata build on frv
Date: Tue, 26 Sep 2006 18:25:28 +0100 [thread overview]
Message-ID: <7848.1159291528@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0609260909470.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> Zero _is_ an appropriate choice, dammit!
> ...
> and then, if your actual _hardware_ things that the bit-pattern with all
> bits clear is a valid irq that can be used for normal devices,
PCI, for example. According to the spec, 0x00 is valid in the Interrupt Line
register and 0xFF indicates unconnected or unset.
> then what you do is you add a irq number translation layer (WHICH WE NEED
> AND HAVE _ANYWAY_) and make sure that nobody sees that on a _software_
> level.
So, by your argument, if you _have_ to have an IRQ translation layer anyway,
then what's the problem with having zero as a valid IRQ and using some other
value to indicate an invalid IRQ? As you say, you have a translation layer
anyway...
That would mean the arch maintainer could make the optimal choice for their
arch - perhaps picking 255 which would be consistent with PCI.
As far as FRV goes, I'm quite happy with 0 as being NO_IRQ, since the 0 bit in
the primary PIC registers is the master switch, not a per-level bit (there are
no source indicators unfortunately).
However, x86, x86_64, and others *do* treat IRQ 0 as being valid, and expose
it to userspace in various ways:
warthog>cat /proc/interrupts
CPU0
0: 287035291 IO-APIC-edge timer
...
So on *that* basis, using IRQ 0 to indicate unset/invalid/etc would seem to be
bad.
David
next prev parent reply other threads:[~2006-09-26 17:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 22:39 [PATCH] restore libata build on frv Al Viro
2006-09-25 10:44 ` David Howells
2006-09-25 11:26 ` Alan Cox
2006-09-25 11:04 ` Russell King
2006-09-25 11:28 ` David Howells
2006-09-25 11:27 ` David Howells
2006-09-25 12:19 ` Alan Cox
2006-09-25 12:18 ` David Howells
2006-09-25 14:20 ` Al Viro
2006-09-25 14:39 ` David Howells
2006-09-25 15:46 ` Alan Cox
2006-09-25 16:04 ` David Howells
2006-09-25 16:21 ` Al Viro
2006-09-26 8:06 ` David Woodhouse
2006-09-26 8:52 ` Jeff Garzik
2006-09-26 8:56 ` David Woodhouse
2006-09-26 11:25 ` Alan Cox
2006-09-26 11:30 ` Alan Cox
2006-09-26 16:15 ` Linus Torvalds
2006-09-26 17:25 ` David Howells [this message]
2006-09-26 20:21 ` David Woodhouse
2006-09-27 7:05 ` David Woodhouse
2006-09-25 15:39 ` Alan Cox
2006-09-25 15:45 ` David Howells
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=7848.1159291528@warthog.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dwmw2@infradead.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.