From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alan <alan@lxorguk.ukuu.org.uk>
Cc: David Woodhouse <dwmw2@infradead.org>,
Jeff Garzik <jgarzik@pobox.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers
Date: Thu, 25 Jan 2007 09:56:19 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org> (raw)
In-Reply-To: <20070125172739.0c990a9a@localhost.localdomain>
On Thu, 25 Jan 2007, Alan wrote:
>
> If you want to put your bmdma address at zero then libata-sff won't help
> you at the moment, and assumes zero is a safe "not in use" value because
> the PCI layer also takes a similar view in places.
Indeed. Zero means "not in use". It really is that simple.
And I'm sorry, David, but 99% of the world _is_ a PC, and that is where
PCI and ATA came from, so anybody who thinks that zero is a valid PCI
address is just sadly mistaken and has a bug. In fact, even on a hardware
level, a lot of devices will literally have "zero means disabled".
Broken architectures that put PCI things at some "PCI physical address
zero" need to map their PCI addresses to something else. It's part of why
we have the whole infrastructure for doing things like
pcibios_bus_to_resource()
pcibios_resource_to_bus()
etc - not just because a resource having zero in "start" means that it is
disabled, but because normally such broken setups have *other* problems
too (ie they don't have a 1:1 mapping between PCI addresses and physical
addresses _anyway_, so they need to address translations).
This has come up before. For example: for an IRQ, 0 means "does not
exist", it does _not_ mean "physical irq 0", and we test for whether a
device has a valid irq by doing "if (dev->irq)" rather than having some
insane archiecture-specific "IRQ_NONE". And if you validly really have an
irq at the hardware level that is zero, then that just means that the irq
numbers you should tell the kernel should be translated some way.
(On a PC, hardware irq 0 is a real irq too, but it's a _special_ irq, and
it is set up by architecture-specific code. So as far as the generic
kernel and all devices are concerned, "!dev->irq" means that the irq
doesn't exist or hasn't been mapped for that device yet).
So there are three issues:
- we always need a way of saying "not mapped"/"nonexistent", and using
the value zero is the one that GIVES THE CLEANEST SOURCE CODE! It's why
NULL pointers are zero too. Sure, virtual address zero is a real
virtual address, but that doesn't change the fact that C made 0 be
special on a language level. If you want to access that virtual
address, and use NULL as a "doesn't exist" at the same time, you need
to swizzle your pointer somehow.
- the x86[-64] architecture is the one that gets tested the most. So
everybody else should try to look like it, rather than say "we are
different/better/strange". Don't have any special IO instructions?
Tough. You'd better do "inb/outb" anyway, and map them onto your
memory-mapped IO somehow.
- per-architecture magic values is a bad idea. If you need a magic value
(and things like this _do_ need one, unless we always want to carry a
separate flag around saying "valid" or "not valid"), it's a lot better
to just say "everybody uses this value" and then have the _small_
architecture-specific code work around it, than have everybody have to
work around a lot of architectures doing things differently.
All these issues boil down to the same thing: whenever at all physically
possible, we make sure that everything looks as much as a PC as possible.
Only when that literally isn't an option do we add other abstractions.
Linus
next prev parent reply other threads:[~2007-01-25 17:56 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 15:09 [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers Alan
2007-01-25 16:14 ` David Woodhouse
2007-01-25 16:17 ` Jeff Garzik
2007-01-25 16:19 ` David Woodhouse
2007-01-25 16:22 ` Russell King
2007-01-25 16:26 ` David Woodhouse
2007-01-25 17:27 ` Alan
2007-01-25 17:56 ` Linus Torvalds [this message]
2007-01-26 0:23 ` David Woodhouse
2007-01-26 1:28 ` Linus Torvalds
2007-01-26 1:45 ` Jeff Garzik
2007-01-26 2:01 ` Linus Torvalds
2007-01-26 2:11 ` Jeff Garzik
2007-01-26 10:37 ` Alan
2007-01-28 23:01 ` Benjamin Herrenschmidt
2007-01-28 22:57 ` Benjamin Herrenschmidt
2007-01-26 2:23 ` David Woodhouse
2007-01-26 2:58 ` Linus Torvalds
2007-01-26 3:28 ` David Woodhouse
2007-01-26 4:00 ` Linus Torvalds
2007-01-26 4:19 ` David Woodhouse
2007-01-26 4:48 ` Linus Torvalds
2007-01-26 5:09 ` David Woodhouse
2007-01-26 6:01 ` Linus Torvalds
2007-01-26 6:18 ` Linus Torvalds
2007-01-26 8:17 ` David Miller
2007-01-26 8:20 ` David Miller
2007-01-26 4:53 ` Jeff Garzik
2007-01-26 15:32 ` Mark Lord
2007-01-26 15:29 ` Mark Lord
2007-01-28 23:04 ` Benjamin Herrenschmidt
2007-01-28 22:49 ` Benjamin Herrenschmidt
2007-01-25 23:36 ` Jeff Garzik
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=Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dwmw2@infradead.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).