From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
Alex Williamson <alex.williamson@hp.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Grant Grundler <grundler@parisc-linux.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Alex Chiang <achiang@hp.com>
Subject: Re: [PATCH] pci: fix bridge 64bit flag setting
Date: Tue, 01 Dec 2009 10:28:29 -0800 [thread overview]
Message-ID: <4B15604D.2090202@kernel.org> (raw)
In-Reply-To: <200912010838.56945.bjorn.helgaas@hp.com>
Bjorn Helgaas wrote:
> On Tuesday 01 December 2009 12:03:57 am Yinghai Lu wrote:
>> Alex found one system that one pci bridge pref mmio 64 is not set correctly.
>> aka, the upper32 base/limit is not cleaned.
>> he found that bridge is supporting 64 bit pref mmio, but device under that
>> does not support that. so that IORESOURCE_MEM_64 get cleared in pbus_size_mem()
>
> I think it's wrong that pbus_size_mem() fiddles with IORESOURCE_MEM_64
> in bus resources based on where BARs of devices on that bus live. That
> feels fragile.
yes. need more clean up.
>
> The question of whether the bridge supports 64-bit apertures is
> strictly a hardware property of the bridge. It has nothing to do
> with where we place downstream devices.
>
> Is there really a problem with writing to PCI_PREF_BASE_UPPER32
> unconditionally? As Alex pointed out, per 3.2.5.10 of the bridge
> spec, the UPPER32 registers are read-only if only 32-bit apertures
> are supported. If you mentioned a problem with doing this
> unconditionally, I missed it.
remember that some x2apic registers say they are reserved, and read them could cause GP error.
and for pci devices, if it is read-only, for good design, then write it should be ok.
but if there is some design problem in devices, and they could say those are read-only.
why kernel write value to it?
>
> The only place we test IORESOURCE_MEM_64 for a bus resource is when
> we're programming PCI_PREF_BASE_UPPER32. If we think it's important
> to program it conditionally, why don't we skip IORESOURCE_MEM_64
IORESOURCE_MEM_64 is used to control if we can use MMIO > 4g.
> altogether, and just look at the bits in PCI_PREF_MEMORY_BASE directly?
> E.g., something like this:
>
> pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE, &l);
> if ((l & PCI_PREF_RANGE_TYPE_MASK) == PCI_PREF_RANGE_TYPE_64) {
> pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32, bu);
> pci_write_config_dword(bridge, PCI_PREF_LIMIT_UPPER32, lu);
> }
>
> Then we don't have to maintain flags at all, and it's easy to verify
> that the code corresponds to the spec.
that will have several extra read, and also we already store that bit in pci_read_bridge_bases()
but forget to set that in pci_check_bus_range()
YH
YH
next prev parent reply other threads:[~2009-12-01 18:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-30 21:22 [PATCH] PCI: Always set prefetchable base/limit upper32 registers Alex Williamson
2009-11-30 21:36 ` Yinghai Lu
2009-11-30 21:43 ` Alex Williamson
2009-11-30 21:52 ` Yinghai Lu
2009-11-30 22:01 ` Alex Williamson
2009-11-30 22:12 ` Yinghai Lu
2009-11-30 22:19 ` Alex Williamson
2009-11-30 23:32 ` Yinghai Lu
2009-11-30 23:53 ` Alex Williamson
2009-12-01 0:00 ` Yinghai Lu
2009-12-01 1:56 ` Alex Williamson
2009-12-01 2:26 ` Yinghai Lu
2009-12-01 2:50 ` Yinghai Lu
2009-12-01 3:23 ` Alex Williamson
2009-12-01 6:35 ` Yinghai Lu
2009-12-01 6:55 ` Alex Williamson
2009-12-01 7:03 ` [PATCH] pci: fix bridge 64bit flag setting Yinghai Lu
2009-12-01 15:38 ` Bjorn Helgaas
2009-12-01 18:28 ` Yinghai Lu [this message]
2009-12-01 19:15 ` Yinghai Lu
2009-12-01 0:22 ` [PATCH] PCI: Always set prefetchable base/limit upper32 registers Yinghai Lu
2009-12-01 0:00 ` Grant Grundler
2009-12-01 0:09 ` Yinghai Lu
2009-12-01 0:15 ` Grant Grundler
2009-11-30 23:58 ` Grant Grundler
2009-11-30 21:42 ` Grant Grundler
2009-11-30 21:43 ` Alex Williamson
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=4B15604D.2090202@kernel.org \
--to=yinghai@kernel.org \
--cc=achiang@hp.com \
--cc=alex.williamson@hp.com \
--cc=bjorn.helgaas@hp.com \
--cc=grundler@parisc-linux.org \
--cc=ink@jurassic.park.msu.ru \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@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 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.