From: Linus Torvalds <email@example.com> To: Alan <firstname.lastname@example.org> Cc: David Woodhouse <email@example.com>, Jeff Garzik <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com> 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.firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> 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 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.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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.