linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Alan <alan@lxorguk.ukuu.org.uk>, 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 20:00:12 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701251932250.25027@woody.linux-foundation.org> (raw)
In-Reply-To: <1169782107.3593.219.camel@shinybook.infradead.org>



On Fri, 26 Jan 2007, David Woodhouse wrote:
> 
> It's not just "my laptop", I believe. It's the generic resource code,
> which is happy to assign address zero since it's never been taught that
> zero is now a special case. If we're not going to ask for the bug I
> observed to be fixed -- if we're going to declare that driver authors
> don't have to sober up and clean up their code -- then the resource code
> should be modified accordingly.

The resource code really is totally agnostic, and you're barking up the 
wrong tree there. In many ways, the resource code isn't even about "IO 
resources", it could do other things too.

[ In practice, of course, IO resources is all it does and what it was 
  designed for, since there really aren't a lot of hierarchical things 
  that need to be able to nest and handle byte-range-like things. ]

It's really up to the architecture-specific PCI initialization what the 
PCI resources look like. The resource code just takes whatever resource 
layout it is given. Yes, there's a "root" ioport_resource, but that's just 
the container for the whole PCI resource tree, and generally you'd show 
the different PCI domains exposed with their buses in that tree.

Of course, for all the historical reasons (a single domain, and it was 
written for a PC), on PC's, the root PCI bus just points directly to the 
root io port resource. But the way things work is that you cardbus card 
doesn't just allocate space from that "ioport_resource" itself. No, it 
allocates space from the cardbus controller resources, which in turn have 
allocated space from the PCI bridge controller resources, etc etc all the 
way up to whatever is the PCI root resource.

There *are* drivers that use the "ioport_resource" directly, but they are 
system devices (where "ISA" counts as a system device - augh: it's not 
enumerable or discoverable) which know where they go. But a normal driver 
never does in any modern world.

So the way to make sure that PCI devices get allocated in the proper area 
is not to change the resource manager, but to make sure that the 
architecture initializes the root bridges for all the domains properly.

(A lot of them do the "PC thing", of course: they just make the ioport 
resource the direct parent of the root bridge, and that's ok if the root 
really _is_ supposed to cover everything from zero. On a PC, that's 
actually the right thing to do, because the system devices will insert 
themselves into the low area, and then PCIBIOS_MIN_IO - 0x1000 on a PC - 
is used as the minimum for any *dynamic* allocation.)

PCI PIO/IOMEM resource allocation is actually fairly complicated, and most 
people really *really* never need to care. It should be considered a sign 
of how well the resource code works that it all usually works without most 
people ever really needing to understand it.

			Linus

  reply	other threads:[~2007-01-26  4:00 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
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 [this message]
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.0701251932250.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).