All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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 \
    --subject='Re: [PATCH] libata-sff: Don'\''t call bmdma_stop on non DMA capable controllers' \
    /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

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.