From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Zhu, DengCheng" <dczhu@mips.com>,
"ralf@linux-mips.org" <ralf@linux-mips.org>,
"monstr@monstr.eu" <monstr@monstr.eu>,
"paulus@samba.org" <paulus@samba.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
"Barzilay, Eyal" <eyal@mips.com>,
"Fortuna, Zenon" <zenon@mips.com>,
"dengcheng.zhu@gmail.com" <dengcheng.zhu@gmail.com>
Subject: Re: [RESEND PATCH v3 0/2] Pass resources to pci_create_bus() and fix MIPS PCI resources
Date: Wed, 2 Nov 2011 14:14:10 -0700 [thread overview]
Message-ID: <20111102141410.4d44a4eb@jbarnes-desktop> (raw)
In-Reply-To: <CAErSpo5rU8aa=-joApUTYbsQrbrRz9x-7VA3V3H9gDg7k7nj+w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]
On Tue, 11 Oct 2011 10:15:34 -0600
Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Tue, Oct 11, 2011 at 1:48 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>
> > I must admit I don't completely understand what this patch is about,
> > other than it will most probably break the way we do resource management
> > on powerpc :-)
> >
> > I don't understand the point about conflicts in scan_slot and I don't
> > see what you win by "settling down early". Also keep in mind that the
> > resources read from the device need to be remapped on some archs like
> > powerpc which we do from a header quirk at the moment.
>
> These patches only deal with root bus resources, i.e., the
> non-architected PCI host bridge windows. They don't have anything to
> do with normal PCI BARs.
>
> MIPS sets up root buses differently than powerpc, so it has a problem
> that powerpc doesn't have. Here's the original MIPS flow (before this
> series):
>
> pci_scan_bus
> pci_scan_bus_parented
> pci_create_bus <-- A create root bus
> pci_scan_child_bus
> pci_scan_slot
> pci_scan_single_device
> pci_scan_device
> pci_setup_device
> pci_fixup_device (pci_fixup_early) <-- B
> pci_device_add
> pci_fixup_device (pci_fixup_header) <-- C
> pcibios_fixup_bus <-- D fill in root bus resources
>
> At point A, we allocate a struct pci_bus for the root bus.
> pci_create_bus() fills in defaults for the resources available on that
> bus: ioport_resource and iomem_resource, which cover all possible
> address space. Later at point D, we replace those defaults with the
> correct resources (hose->io_resource and hose->mem_resource in this
> MIPS case).
>
> The problem is that the root bus resources are wrong during the
> interval between A and D. Anything that looks at them may break. In
> the case Deng-Cheng found, the quirk_piix4_acpi() fixup at point C
> claimed a region, which incorrectly became the child of
> ioport_resource instead of host->io_resource.
>
> Deng-Cheng's patches close this window by basically combining the
> fixup at D with the root bus creation at A.
>
> Powerpc doesn't have the same problem because it calls
> pci_create_bus() directly so it can fix the root bus resources with
> pcibios_setup_phb_resources() *before* it scans the bus.
>
> Even though powerpc and many other architectures don't have the MIPS
> problem, I think it's worth changing the code because the existing
> pattern is poor. In almost all cases, we know what the host bridge
> apertures are before we create the root bus. It's error-prone to have
> pci_create_bus() fill in default resources, then rely on the
> architecture to fix that up later. I think it's better to supply the
> resources up front.
Ben, with the above explained are you ok with this change?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-11-02 21:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 2:48 [RESEND PATCH v3 0/2] Pass resources to pci_create_bus() and fix MIPS PCI resources Deng-Cheng Zhu
2011-09-01 2:48 ` [RESEND PATCH v3 1/2] PCI: Pass available resources into pci_create_bus() Deng-Cheng Zhu
2011-09-01 2:48 ` [RESEND PATCH v3 2/2] MIPS: PCI: Pass controller's resources to pci_create_bus() in pcibios_scanbus() Deng-Cheng Zhu
2011-10-07 21:50 ` [RESEND PATCH v3 0/2] Pass resources to pci_create_bus() and fix MIPS PCI resources Bjorn Helgaas
2011-10-10 21:04 ` Bjorn Helgaas
2011-10-10 23:49 ` Zhu, DengCheng
2011-10-11 7:48 ` Benjamin Herrenschmidt
2011-10-11 16:15 ` Bjorn Helgaas
2011-11-02 21:14 ` Jesse Barnes [this message]
2011-11-02 21:37 ` Bjorn Helgaas
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=20111102141410.4d44a4eb@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=davem@davemloft.net \
--cc=dczhu@mips.com \
--cc=dengcheng.zhu@gmail.com \
--cc=eyal@mips.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=monstr@monstr.eu \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=zenon@mips.com \
/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