From: Arnd Bergmann <arnd@arndb.de>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Sunil Kovvuri <sunil.kovvuri@gmail.com>,
LAKML <linux-arm-kernel@lists.infradead.org>,
Robert Richter <rric@kernel.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-pci" <linux-pci@vger.kernel.org>,
Liviu Dudau <liviu.dudau@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Robert Richter <rrichter@cavium.com>,
Sunil Goutham <sgoutham@cavium.com>
Subject: Re: [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree bindings
Date: Thu, 25 Sep 2014 22:22:23 +0200 [thread overview]
Message-ID: <201409252222.23825.arnd@arndb.de> (raw)
In-Reply-To: <CAErSpo5rhL7pLha-yWt7sZUBmAnwA6FkacL+sWXBKkSzsuC7Sg@mail.gmail.com>
On Thursday 25 September 2014, Bjorn Helgaas wrote:
> OK. You said "a range that has the nonrelocatable flag set should be
> used for IORESOURCE_PCI_FIXED mappings." I thought you meant that the
> range was a bridge window, and somehow PCI_FIXED BARs should be put in
> that window.
>
> But maybe you meant that nonrelocatable ranges should have the
> IORESOURCE_PCI_FIXED bit set in their struct resources. That would
> mean we couldn't move the window, but we could put relocatable BARs
> inside the window.
>
> What needs to be implemented? Just the code that would set
> IORESOURCE_PCI_FIXED for nonrelocatable ranges?
It might be more complex than I thought. Let's see what the original
hack does:
+/*
+ * All PCIe devices in Thunder have fixed resources, shouldn't be reassigned.
+ * Also claim the device's valid resources to set 'res->parent' hierarchy.
+ */
+static void pci_dev_resource_fixup(struct pci_dev *dev)
+{
+ struct resource *res;
+ int resno;
+
+ for (resno = 0; resno < PCI_NUM_RESOURCES; resno++)
+ dev->resource[resno].flags |= IORESOURCE_PCI_FIXED;
+
+ for (resno = 0; resno < PCI_BRIDGE_RESOURCES; resno++) {
+ res = &dev->resource[resno];
+ if (res->parent || !(res->flags & IORESOURCE_MEM))
+ continue;
+ pci_claim_resource(dev, resno);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID,
+ pci_dev_resource_fixup);
This actually looks harmful, because it means that any kernel that contains
the thunder host controller driver will do the above for any device made
by Cavium, whether it's connected to this bridge or not.
What I think we want instead is to mark any resource whose parent
resource is IORESOURCE_PCI_FIXED to have the same flag, and mark
the PCI host controller resources IORESOURCE_PCI_FIXED when the
nonrelocatable flag is set, and that should all be done in core
code, not in a driver fixup.
The part that still looks weird is the pci_claim_resource() that
Sunil mentioned. This is currently done for resources that do not
have a parent, but AFAICT all PCI device resources should have a
parent that connects it to the upstream bridge.
Arnd
next prev parent reply other threads:[~2014-09-25 20:23 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 15:37 [PATCH 0/6] pci, thunder: Add Cavium Thunder PCIe host controller Robert Richter
2014-09-24 15:37 ` [PATCH 1/6] pci, thunder: Add support for " Robert Richter
2014-09-24 16:12 ` Arnd Bergmann
2014-09-24 16:49 ` Will Deacon
2014-09-30 9:14 ` Sunil Kovvuri
2014-09-24 15:37 ` [PATCH 2/6] GICv3: Add ITS entry to THUNDER dts Robert Richter
2015-06-25 23:19 ` Chalamarla, Tirumalesh
2015-06-26 9:00 ` Marc Zyngier
2014-09-24 15:37 ` [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree bindings Robert Richter
2014-09-24 16:06 ` Arnd Bergmann
2014-09-24 18:04 ` Sunil Kovvuri
2014-09-24 18:34 ` Arnd Bergmann
2014-09-24 19:07 ` Sunil Kovvuri
2014-09-25 7:31 ` Arnd Bergmann
2014-09-25 16:16 ` Bjorn Helgaas
2014-09-25 19:26 ` Arnd Bergmann
2014-09-25 20:10 ` Bjorn Helgaas
2014-09-25 20:22 ` Arnd Bergmann [this message]
2014-09-25 20:49 ` Bjorn Helgaas
2014-09-26 18:26 ` Rob Herring
2014-09-30 9:11 ` Sunil Kovvuri
2014-10-07 14:27 ` Robert Richter
2014-10-07 15:01 ` Liviu Dudau
2014-10-08 8:49 ` Robert Richter
2014-10-08 16:44 ` Liviu Dudau
2014-10-09 6:23 ` Robert Richter
2014-09-24 15:37 ` [PATCH 4/6] pci, thunder: Document " Robert Richter
2014-09-24 15:37 ` [PATCH 5/6] arm64, defconfig: Enable PCI Robert Richter
2014-09-24 16:14 ` Arnd Bergmann
2014-09-24 16:26 ` Robert Richter
2014-09-24 17:10 ` Catalin Marinas
2014-09-24 18:40 ` Arnd Bergmann
2014-09-25 9:35 ` Catalin Marinas
2014-09-25 10:45 ` Arnd Bergmann
2014-09-24 15:37 ` [PATCH 6/6] pci, thunder: Enable Cavium Thunder PCIe host controller Robert Richter
2014-09-24 17:12 ` Catalin Marinas
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=201409252222.23825.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=rric@kernel.org \
--cc=rrichter@cavium.com \
--cc=sgoutham@cavium.com \
--cc=sunil.kovvuri@gmail.com \
--cc=will.deacon@arm.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