From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Alex Chiang <achiang@hp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 0/12] pci: update pci bridge resources
Date: Mon, 21 Dec 2009 12:47:04 -0800 [thread overview]
Message-ID: <4B2FDEC8.9000700@kernel.org> (raw)
In-Reply-To: <1261370692.26429.78.camel@dc7800.home>
Bjorn Helgaas wrote:
> On Sun, 2009-12-20 at 17:42 -0800, Yinghai Lu wrote:
>> Bjorn Helgaas wrote:
>>> On Fri, 2009-12-18 at 12:54 -0800, Yinghai Lu wrote:
>>>> this patche set is trying to update pci bridge BAR when that BAR is big enough.
>>>>
>>>> default it is disabled.
>>>>
>>>> could use pci=try=2 to enable it.
>>> I think you mean "when the BAR is *not* big enough." And strictly
>>> speaking, I think you're concerned with the bridge *window*, which isn't
>>> actually a bridge BAR.
>> in PCI bridge to bridge spec 1.1, page 38, 3.2.5.1 still call them bridge "Base Address Registers"
>>
>> so should be fine we call them Bridge BAR,
>>
>> and we still have device BAR...
>
> PCI bridges have optional BARs, described as you point out in section
> 3.2.5.1. These work the same as BARs on any other PCI device, and your
> patches aren't concerned with these.
>
> Your patch series is primarily concerned with the bridge Base & Limit
> registers described in sections 3.2.5.6 (I/O), 3.2.5.8 (memory), and
> 3.2.5.9 (prefetchable memory). These define the address ranges
> forwarded from one bridge interface to the other. The spec doesn't have
> a nice term for these ranges, but they're often referred to as "windows"
> or "apertures" because they are the areas where you can "see through"
> the bridge to devices on the other side.
I have following patch. how to format the "bar reading" ?
[PATCH] pci: reject mmio range start from 0 on pci_bridge read
that is wrong.
exposed by that patch that doesn't shrink pci bridge res.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/probe.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/pci/probe.c
===================================================================
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -316,13 +316,17 @@ void __devinit pci_read_bridge_bases(str
limit |= (io_limit_hi << 16);
}
- if (base <= limit) {
+ if (base <= limit && base) {
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
if (!res->start)
res->start = base;
if (!res->end)
res->end = limit + 0xfff;
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
+ } else {
+ dev_printk(KERN_DEBUG, &dev->dev,
+ " bridge window [io %04lx - %04lx] bar reading\n",
+ base, limit);
}
res = child->resource[1];
@@ -330,11 +334,15 @@ void __devinit pci_read_bridge_bases(str
pci_read_config_word(dev, PCI_MEMORY_LIMIT, &mem_limit_lo);
base = (mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16;
limit = (mem_limit_lo & PCI_MEMORY_RANGE_MASK) << 16;
- if (base <= limit) {
+ if (base <= limit && base) {
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xfffff;
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
+ } else {
+ dev_printk(KERN_DEBUG, &dev->dev,
+ " bridge window [mem 0x%08lx - 0x%08lx] bar reading\n",
+ base, limit + 0xfffff);
}
res = child->resource[2];
@@ -366,7 +374,7 @@ void __devinit pci_read_bridge_bases(str
#endif
}
}
- if (base <= limit) {
+ if (base <= limit && base) {
res->flags = (mem_base_lo & PCI_PREF_RANGE_TYPE_MASK) |
IORESOURCE_MEM | IORESOURCE_PREFETCH;
if (res->flags & PCI_PREF_RANGE_TYPE_64)
@@ -374,6 +382,10 @@ void __devinit pci_read_bridge_bases(str
res->start = base;
res->end = limit + 0xfffff;
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
+ } else {
+ dev_printk(KERN_DEBUG, &dev->dev,
+ " bridge window [mem 0x%016lx - %016lx pref] bar reading\n",
+ base, limit + 0xfffff);
}
}
prev parent reply other threads:[~2009-12-21 20:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-18 20:54 [PATCH 0/12] pci: update pci bridge resources Yinghai Lu
2009-12-20 23:44 ` Bjorn Helgaas
2009-12-21 1:42 ` Yinghai Lu
2009-12-21 4:44 ` Bjorn Helgaas
2009-12-21 20:47 ` Yinghai Lu [this message]
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=4B2FDEC8.9000700@kernel.org \
--to=yinghai@kernel.org \
--cc=achiang@hp.com \
--cc=bjorn.helgaas@hp.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jbarnes@virtuousgeek.org \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@elte.hu \
--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.