From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jesse Barnes <jesse.barnes@intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Robert Hancock <hancockr@shaw.ca>,
linux-pci@atrey.karlin.mff.cuni.cz,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Possible issue with dangling PCI BARs
Date: Fri, 14 Dec 2007 07:51:06 +1100 [thread overview]
Message-ID: <1197579066.15741.167.camel@pasglop> (raw)
In-Reply-To: <200712131204.18227.jesse.barnes@intel.com>
On Thu, 2007-12-13 at 12:04 -0800, Jesse Barnes wrote:
>
> Yeah, that seems like a reasonable compromise. Though in practice
> I'd
> expect the full disable decode approach to work fairly well too. I
> mean, if we really end up failing to allocate space for the device
> with
> the root drive on it, there are probably bigger issues than just
> failing to get a few bytes of I/O space for it...
>
The really bad scenario would be something like the Sil680 that Alan
talked about setup by a BIOS that "knows" about the unused BAR when
MMIO_EN is not set.
If the device is behind a P2P bridge and the BIOS has set the windows of
that bridge so tightly that there is no room to allocate the MMIO BAR,
then a full disable/full enable would fail on a device that would
otherwise work using only PIO.
However, I'd be curious to see that happening in practice :-)
But I think it's fair enough to do an IO only / MEM only approach. I've
seen cases where IO is just not useable because of other constraints and
so I expect the MEM-only case to be more common, especially on non-x86.
Ben.
next prev parent reply other threads:[~2007-12-13 20:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.YfTvVN5C3e6zwXPW5biWgeZ9XXc@ifi.uio.no>
[not found] ` <fa.EhUqlM3V3y3HCcQkLBLSEKTJxBs@ifi.uio.no>
[not found] ` <fa.4FjaYKIciOijtgO+0DDrMkrLjv0@ifi.uio.no>
2007-12-13 4:22 ` Possible issue with dangling PCI BARs Robert Hancock
2007-12-13 5:26 ` Benjamin Herrenschmidt
2007-12-13 9:14 ` Ivan Kokshaysky
2007-12-13 9:29 ` Benjamin Herrenschmidt
2007-12-13 9:04 ` Ivan Kokshaysky
2007-12-13 10:24 ` Alan Cox
2007-12-13 11:17 ` Benjamin Herrenschmidt
2007-12-13 11:20 ` Benjamin Herrenschmidt
2007-12-13 20:04 ` Jesse Barnes
2007-12-13 20:51 ` Benjamin Herrenschmidt [this message]
2007-12-13 21:12 ` Ivan Kokshaysky
2007-12-13 23:09 ` Benjamin Herrenschmidt
2007-12-13 21:02 ` Ivan Kokshaysky
2007-12-13 13:27 ` Alan Cox
2007-12-13 3:00 Benjamin Herrenschmidt
2007-12-13 3:04 ` Benjamin Herrenschmidt
2007-12-13 3:40 ` Benjamin Herrenschmidt
2007-12-14 11:52 ` Jon Masters
2007-12-14 22:11 ` Benjamin Herrenschmidt
2007-12-15 2:18 ` Jon Masters
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=1197579066.15741.167.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hancockr@shaw.ca \
--cc=ink@jurassic.park.msu.ru \
--cc=jesse.barnes@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=torvalds@linux-foundation.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 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.