lkml.org 
[lkml]   [2007]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers


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
-
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: 2007-01-25 18:59    [W:0.125 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site