public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@debian.org>
To: Matthew Wilcox <willy@debian.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Andrew Morton <akpm@zip.com.au>, Greg KH <greg@kroah.com>,
	David Mosberger <davidm@hpl.hp.com>,
	linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: Re: [2/3] Use insert_resource in pci_claim_resource
Date: Fri, 19 Mar 2004 17:09:09 +0000	[thread overview]
Message-ID: <20040319170909.GR25059@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20040319153639.E14431@flint.arm.linux.org.uk>

On Fri, Mar 19, 2004 at 03:36:39PM +0000, Russell King wrote:
> On Fri, Mar 19, 2004 at 02:52:12PM +0000, Matthew Wilcox wrote:
> > But I do think insert_resource is the right call to make.  If the device has
> > the wrong resources, that means something's gone awfully wrong earlier in
> > the pci code.
> 
> Sure, but due to the request_resource semantics, it provides a good way
> to catch this should it occur.

Now that I try it, we lose.  ACPI allows us an unlimited number of resources
that can be routed to each bus, and pci_bus only has space for 4.  On my
rx2600 box, we have 5 resources pointing to bus 0x20:

# cat /proc/iomem /proc/ioports |grep :20
90000000-97ffffff : PCI Bus 0000:20
ff5e0000-ff5e0007 : PCI Bus 0000:20
ff5e2000-ff5e2007 : PCI Bus 0000:20
90004000000-90103fffffe : PCI Bus 0000:20
00002000-00002fff : PCI Bus 0000:20

Sure, you can argue that some of these should be coalesced and others
aren't used, but I'm not comfortable diddling with that in the kernel,
or asking firmware to change that.  And nobody knows what tomorrow will
bring in terms of PCI bus topologies.  So I'd like the insert_resource
patch to go in.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

  reply	other threads:[~2004-03-19 17:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-18 23:50 [0/3] Make pci resources show up in iomem/ioport on ia64 Matthew Wilcox
2004-03-18 23:51 ` [1/3] insert_resource can succeed and return an error Matthew Wilcox
2004-03-18 23:52 ` [2/3] Use insert_resource in pci_claim_resource Matthew Wilcox
2004-03-19  9:56   ` Russell King
2004-03-19 14:52     ` Matthew Wilcox
2004-03-19 15:36       ` Russell King
2004-03-19 17:09         ` Matthew Wilcox [this message]
2004-03-18 23:52 ` [3/3] claim PCI resources on ia64 Matthew Wilcox
2004-03-19  1:48   ` David Mosberger
2004-03-19 22:13 ` [0/3] Make pci resources show up in iomem/ioport " Greg KH

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=20040319170909.GR25059@parcelfarce.linux.theplanet.co.uk \
    --to=willy@debian.org \
    --cc=akpm@zip.com.au \
    --cc=davidm@hpl.hp.com \
    --cc=greg@kroah.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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