dongbo (E | 28 Jun 10:12 2016

[PATCH] Exchange the Assignments of `MEMORYs' and `CFGs/IOs' in Designware PCIe Driver

From: Dong Bo <dongbo4 <at>>

In designware PCIe driver, the iatu0 is used for both CFG and IO accesses.
When sending CFGs to peripherals (e.g. lspci), iatu0 frequently switches
between CFG and IO alternatively.

A MEMORY probably be sent as an IOs by mistake. Considering the following
MEMORY          ->      BASE_ADDR: 0xb4100000, LIMIT: 0xb4100FFF, TYPE=mem
CFG             ->      BASE_ADDR: 0xb4000000, LIMIT: 0xb4000FFF, TYPE=cfg
IO              ->      BASE_ADDR: 0xFFFFFFFF, LIMIT: 0xFFFFFFFE, TYPE=io

Suppose PCIe has just completed a CFG access, to switch back to IO, it set
the BASE_ADDR to 0xFFFFFFFF, LIMIT 0xFFFFFFFE and TYPE to io. When another
CFG comes, the BASE_ADDR is set to 0xb4000000 to switch to CFG. At this
moment, a MEMORY access shows up, since it matches with iatu0
(due to 0xb4000000 <= MEMORY BASE_ADDR <= MEMORY LIMIE <= 0xFFFFFFF), it
is treated as an IO access by mistake, then sent to perpheral.

This patch fixes the problem by exchanging the assignments of `MEMORYs'
and `CFGs/IOs', which assigning MEMEORYs to iatu0, CFGs and IOs to iatu1.

Signed-off-by: Dong Bo <dongbo4 <at>>
 drivers/pci/host/pcie-designware.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index aafd766..1bd88d9 100644
--- a/drivers/pci/host/pcie-designware.c
(Continue reading)

Tomasz Nowicki | 28 Jun 09:53 2016

[RFC PATCH v4 0/5] ECAM quirks handling for ARM64 platforms

Quirk handling relies on an idea of matching MCFG OEM ID, TABLE ID and
revision (the ones from standard header of MCFG table).

Static array is used to keep quirk entries. Each entry consist of
metioned MCFG IDs along with custom pci_ops structure and initialization call.

As an example, last patch presents quirk handling mechanism usage for
ThunderX PEM driver.

Tomasz Nowicki (5):
  PCI: Embed pci_ecam_ops in pci_config_window structure
  PCI/ACPI: Move ACPI ECAM mapping to generic MCFG driver
  PCI: Check platform specific ECAM quirks
  ARM64/PCI: Start using quirks handling for ACPI based PCI host
  PCI: thunder: Add ThunderX PEM MCFG quirk to the list

 arch/arm64/kernel/pci.c            | 42 +----------------
 drivers/acpi/pci_mcfg.c            | 40 ++++++++++++++++
 drivers/pci/ecam.c                 |  6 +--
 drivers/pci/host/Makefile          |  1 +
 drivers/pci/host/mcfg-quirks.c     | 95 +++++++++++++++++++++++++++++++++++++
 drivers/pci/host/mcfg-quirks.h     | 24 ++++++++++
 drivers/pci/host/pci-thunder-pem.c | 96 ++++++++++++++++++++++++++++++++------
 include/linux/pci-acpi.h           |  5 ++
 include/linux/pci-ecam.h           |  2 +-
 9 files changed, 254 insertions(+), 57 deletions(-)
 create mode 100644 drivers/pci/host/mcfg-quirks.c
 create mode 100644 drivers/pci/host/mcfg-quirks.h

(Continue reading)

Hariprasad Shenai | 25 Jun 06:08 2016

[PATCH] pci: Use same logic in pci_vpd_read as that of pci_vpd_write

The new implementation of pci_read_vpd() silently fails to perform a VPD
read and allows the caller to use random stack garbage in the read buffer
without knowing that it's not really VPD contents. If any portion of the
VPD read isn't going to be performed, we should signal that back to the
caller.  We could either return an error or we could return the number of
bytes actually read. The problem with the latter is that it would require
changing every single caller to check for Requested Read Length == Actual
Read Length. Returning an error is the more conservative fix and allows
for rapid diagnosis of problems.

Signed-off-by: Casey Leedom <leedom <at>>
Signed-off-by: Hariprasad Shenai <hariprasad <at>>
 drivers/pci/access.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index d11cdbb8fba3..113637de79bf 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
 <at>  <at>  -405,13 +405,8  <at>  <at>  static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
 	if (vpd->len == 0)
 		return -EIO;

-	if (pos > vpd->len)
-		return 0;
-	if (end > vpd->len) {
-		end = vpd->len;
-		count = end - pos;
(Continue reading)

Bjorn Helgaas | 24 Jun 04:36 2016

[GIT PULL] PCI fixes for v4.7

Hi Linus,

Here's a small fix for v4.7.  This problem was actually introduced in v4.6
when we unified Kconfig, making PCIe support available everywhere including
sparc, where config reads into unaligned buffers cause warnings.  This fix
is from Dave Miller.

As a reminder, any future PCI fixes for v4.7 will probably come from Alex
Williamson, since I'll be on vacation for most of the rest of this cycle.
I should be back about the time the merge window opens.


The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

are available in the git repository at:

  git:// tags/pci-v4.7-fixes-1

for you to fetch changes up to ef0dab4aae14e25efddf1577736f8450132800c5:

  PCI: Fix unaligned accesses in VC code (2016-06-20 13:24:20 -0500)

PCI updates for v4.7:

    Fix unaligned accesses in VC code (David Miller)
(Continue reading)

Bjorn Helgaas | 24 Jun 00:16 2016


Hi Ralf, et al,

Lorenzo is doing some nice cleanup of the PCI_PROBE_ONLY case.  Previous

  - PCI_PROBE_ONLY: all PCI BARs and windows are immutable, and we don't
    put those resources in the iomem_resource tree, and they don't show up
    in /proc/iomem.

  - !PCI_PROBE_ONLY: we use whatever existing BAR settings may have been
    done by firmware, we change them if we find conflicts, and we insert
    them all in the iomem_resource tree.

Lorenzo is changing the PCI_PROBE_ONLY case so the BARs and windows remain
immutable, but we insert the resources into the iomem_resource tree.

The ideal thing would be to remove the use of PCI_PROBE_ONLY completely,
and allow Linux to program BARs as necessary.  If the firmware *has*
programmed the BARs, we don't change them unless we find something broken,
so in most cases PCI_PROBE_ONLY is unnecessary.

There are several MIPS platforms (bcm1480, ip27, sb1250, virtio_guest, xlp,
xlr) that set PCI_PROBE_ONLY for reasons I don't know.  These were added

    Andrew Isaacson <adi <at>>
    dc41f94f7709 ("Support for the BCM1480 on-chip PCI-X bridge.")

(Continue reading)

Yijing Wang | 23 Jun 13:42 2016

[PATCH] PCI: release pci_host_bridge resource after remove root bus

pci_host_bridge holds the top resources(IO port/Mem/bus),
now we release pci_host_bridge resources in
acpi_pci_root_release_info() which would be called when
pci_host_bridge device refcount reach 0. In some cases,
pci_host_bridge refcount cannot reach 0 after we remove
pci root bus in pci_remove_root_bus(). Then if we want to
hot add pci root bus, we cannot use pci_host_bridge
resources because of conflicts with old resources which are
still in system. I think this is not reasonable.

1. For pci devices, we would release their resources in
   pci_destroy_dev() regardless of pci device refcount.
2. When we try to remove pci root bus, there is no devices
   need to use the pci_host_bridge resources again, release
   pci_host_bridge resources is safe.
3. In some cases, users woule make mistake, for example,
   user get a pci device(increase refcount), but forget to
   put this device, then if we do hotplug pci root bus,
   it would make all pci devices cannot work after hot add.

I found this issue in the following case:
1. I have a raid pci device in my system;
2. I mount a disk which connect to this raid.
3. hot remove the pci root bus.
4. hot add the pci root bus.
5. found the resource conflicts for the children pci devices under this root bus.

pci_root_bus increase a refcount at pci_host_bridge.
pci_root_bus decrease a refcount at pci_host_bridge in
  release_pcibus_dev() when pci_root_bus device refcount reach 0.
(Continue reading)

Lorenzo Pieralisi | 23 Jun 12:36 2016

[PATCH v3][UPDATE] ARM/PCI: claim bus resources on PCI_PROBE_ONLY set-ups

The PCI bios API does not reassign bus resources on systems
that require the BARs set-up to be immutable (ie PCI_PROBE_ONLY) since
that would trigger system failures. Nonetheless, PCI bus resources
allocated to PCI bridge and devices must be claimed in order to be
validated and inserted in the kernel resource tree, but the current
code omits the resources claiming and relies on arch specific kludges
to prevent probing failure (ie preventing resources enablement on
PCI_PROBE_ONLY systems).

Add code to the ARM PCI bios kernel layer that correctly claims bus
resources upon probe on systems that are required to prevent
reassignment after bus enumeration, so that the allocated resources
can be enabled successfully upon PCI device drivers probing, without
resorting to arch back-ends workarounds.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi <at>>
Cc: Bjorn Helgaas <bhelgaas <at>>
Cc: Russell King <linux <at>>
Hi Bjorn,

I put together this patch as requested, I could not test this
specific path but I do not really see how this patch would
affect any existing set-up.

It completes (and should be inserted as patch 2 or 3 for
bisection reasons) this series:

(Continue reading)

Benjamin Herrenschmidt | 22 Jun 09:04 2016

PCI resource allocation not using pref 64-bit

Hi folks !

So on my POWER9 simulator, I noticed that the PCI code isn't assigning
any BAR to my 64-bit prefetchable window.

This is the trimmed log. Focus on domain 0000, the devices on domain
0001 are 32-bit only. I've also appended an lspci output and a
/proc/iomem output.

I think all that is needed but feel free to ask me if you want more. 

You can see that I pass 2 windows for the root bridge, a 32-bit
one and a prefetchable 64-bit one. It's PCIe so anything 64-bit should
be able to hit the prefetchable 64-bit one but that isn't happening.

Note that PCI_REASSIGN_ALL_RSRC is set, the original setup of the
bridges (including the root complex) is to have base > limit, we
expect Linux to fix them up.

Do you have any idea what's going on ? Is that expected ?


[    0.000000] Linux version 4.7.0-rc4-00029-gf55fbbe9-dirty (benh <at> pasglop) (gcc
 version 6.1.1 20160427 (Red Hat Cross 6.1.1-1) (GCC) ) #50 SMP Wed Jun 22 16:18
:18 AEST 2016
[    0.000000] Initializing IODA3 OPAL PHB /pciex <at> 600c3c0000000
[    0.000000] PCI host bridge /pciex <at> 600c3c0000000 (primary) ranges:
[    0.000000]  MEM 0x000600c000000000..0x000600c07ffeffff -> 0x0000000080000000
(Continue reading)

Koehrer Mathias (ETAS/ESW5 | 22 Jun 08:33 2016

[PATCH v2] Extending kernel option pci=resource_alignment to be able to specify PCI device/vendor IDs

Some uio based PCI drivers (e.g. uio_cif) do not work if the assigned 
PCI memory resources are not page aligned.
By using the kernel option "pci=resource_alignment" it is possible to force
single PCI boards to use page alignment for their memory resources.
However, this is fairly cumbersome if multiple of these boards are in use as 
the specification of the cards has to be done via PCI bus/slot/function number
which might change e.g. by adding another board.
This patch extends the kernel option "pci=resource_alignment" to allow to
specify the relevant boards via PCI device/vendor (and subdevice/subvendor) ids.
The specification of the devices via device/vendor is indicated by a leading
string "pci:" as argument to "pci=resource_alignment".
The format of the specification is

  pci=resource_alignment=4096 <at> pci:1234:abcd:1234:bcde

Signed-off-by: Mathias Koehrer <mathias.koehrer <at>>

 Documentation/kernel-parameters.txt |    2 +
 drivers/pci/pci.c                   |   66 +++++++++++++++++++++++++-----------
 2 files changed, 49 insertions(+), 19 deletions(-)

Index: linux-4.7-rc1/Documentation/kernel-parameters.txt
--- linux-4.7-rc1.orig/Documentation/kernel-parameters.txt
+++ linux-4.7-rc1/Documentation/kernel-parameters.txt
 <at>  <at>  -2998,12 +2998,17  <at>  <at>  bytes respectively. Such letter suffixes
(Continue reading)

Shawn Lin | 22 Jun 04:18 2016

[PATCH] PCI/MSI: Simplify the return value of arch_setup_msi_irqs

No any callers do care whether arch_setup_msi_irqs returns
-ENOSPC or other error numbers. That means they treat the
negative numbers in the same way. So there shouldn't make any
difference to directly return -ENOSPC if finding it's non-zero.

Signed-off-by: Shawn Lin <shawn.lin <at>>

 drivers/pci/msi.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a080f44..4a40b72 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
 <at>  <at>  -108,7 +108,7  <at>  <at>  int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	struct msi_controller *chip = dev->bus->msi;
 	struct msi_desc *entry;
-	int ret;
+	int ret = 0;

 	if (chip && chip->setup_irqs)
 		return chip->setup_irqs(chip, dev, nvec, type);
 <at>  <at>  -119,13 +119,10  <at>  <at>  int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	if (type == PCI_CAP_ID_MSI && nvec > 1)
 		return 1;

-	for_each_pci_msi_entry(entry, dev) {
+	for_each_pci_msi_entry(entry, dev)
(Continue reading)

Bjorn Helgaas | 21 Jun 19:01 2016

[PATCH 0/2] ARM/PCI: Make I/O port space optional

Currently we always require an I/O port resource for PCI host bridges.  Even
if the bridge doesn't actually support I/O port space, we add a default I/O
resource for it.

These patches make I/O port space optional on ARM.  Comments welcome.

If these look OK, I'll fold them into the series at [1], where they should
fix a resource conflict [2] in the R-Car driver.

[1] <at>
[2] <at>


Bjorn Helgaas (2):
      ARM: Make PCI I/O space optional
      PCI: rcar: Drop gen2 dummy I/O port region

 arch/arm/include/asm/mach/pci.h  |    1 +
 arch/arm/kernel/bios32.c         |   13 +++++++++++--
 drivers/pci/host/pci-rcar-gen2.c |   11 +----------
 3 files changed, 13 insertions(+), 12 deletions(-)