Ben Hutchings | 22 Apr 18:27 2014

[PATCH] PCI: Update my email address

Signed-off-by: Ben Hutchings <ben <at>>
 Documentation/ABI/testing/sysfs-bus-pci | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index a3c5a66..88cdd02 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
 <at>  <at>  -117,7 +117,7  <at>  <at>  Description:

 What:		/sys/bus/pci/devices/.../vpd
 Date:		February 2008
-Contact:	Ben Hutchings <bhutchings <at>>
+Contact:	Ben Hutchings <bwh <at>>
 		A file named vpd in a device directory will be a
 		binary file containing the Vital Product Data for the


Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein
Bjorn Helgaas | 22 Apr 17:57 2014

Re: Wheather the NVMe driver has been tried on the IBM or Lenovo server?

On Tue, Apr 22, 2014 at 5:33 AM, liaohengquan1986
<liaohengquan1986 <at>> wrote:
> Hi, everyone,
>             I want to ask that weather the NVMe driver has been tried on the
> IBM or Lenovo server?
>             I use it on IBM(Lenovo) server with suse 11 SP3, but the MSI-X
> irq is always could not be got by cpu(may be it is masked).
>             Has anyone got this kind of problem?

I think your original email contained non-plain text, so it won't
appear on the mailing list, and some recipients may auto-discard it as
well.  See

If you can reproduce the problem with an upstream kernel, this is the
right place to debug it.  We'd need a complete dmesg log and "lspci
-vv" output to start with.

If the problem only happens with SUSE, then you'd want to work with
SUSE to figure it out.

shiv prakash Agarwal | 22 Apr 11:50 2014

Intel NIC testing on ARM

Hi All,

Has anybody tested below Intel I210 NIC card using igb driver on ARM?

It hangs during configuration stage for me. Actually it shows BAR0
requirement as 0 which is non-zero for x86.
Jiang Liu | 22 Apr 09:07 2014

[RFC Patch Part3 V1 00/22] Enable Intel DMAR device hotplug

When hot plugging a descrete IOH or a physical processor with embedded
IIO, we need to handle DMAR(or IOMMU) unit in the PCIe host bridge if
DMAR is in use. This patch set tries to enhance current DMAR/IOMMU/IR
drivers to support hotplug and is based on latest mainstream kernel

Patch 1-9 are bugfixes and code improvement for current drivers.
Patch 10-13 enhances DMAR framework to support hotplug
Patch 14 enhances Intel interrupt remapping driver to support hotplug
Patch 15 enhances error handling in Intel IR driver
Patch 16 enhance Intel IOMMU to support hotplug
Patch 17 enhance ACPI pci_root driver to handle DMAR units
Patch 18-22 are bugfixes and code improvement again

This patch set has been tested on Intel development machine.
Appreciate any comments and tests.

Best Regards!

Jiang Liu (22):
  iommu/vt-d: match segment number when searching for dev_iotlb capable
  iommu/vt-d: use correct domain id to flush virtual machine domains
  iommu/vt-d: introduce helper functions to improve code readability
  iommu/vt-d: introduce helper functions to make code symmetric for
  iommu/vt-d: only dynamically allocate domain id for virtual domains
  iommu/vt-d: fix possible invalid memory access caused by
  iommu/vt-d: avoid freeing virtual machine domain in free_dmar_iommu()
(Continue reading)

Bjorn Helgaas | 22 Apr 00:17 2014

[PATCH 2] PNP: Work around BIOS defects in Intel MCH area reporting

Work around BIOSes that don't report the entire Intel MCH area.

MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a
PNP0C02 resource.  The MCH space was once 16KB, but is 32KB in newer parts.
Some BIOSes still report a PNP0C02 resource that is only 16KB, which means
the rest of the MCH space is consumed but unreported.

This can cause resource map sanity check warnings or (theoretically) a
device conflict if we assigned the unreported space to another device.

The Intel perf event uncore driver tripped over this when it claimed the
MCH region:

  resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
  Info: mapping multiple BARs. Your kernel is fine.

To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.

Link: <at> pd.tnic
Reported-by: Borislav Petkov <bp <at>>
Tested-by: Borislav Petkov <bp <at>>
Signed-off-by: Bjorn Helgaas <bhelgaas <at>>
Acked-by: Borislav Petkov <bp <at>>
 drivers/pnp/quirks.c |   75 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 75 insertions(+)

diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c
index 258fef272ea7..0d679068ef1b 100644
(Continue reading)

Alexander Duyck | 21 Apr 19:38 2014

[PATCH] pci: Save and restore VFs as a part of a reset

This fixes an issue I found in which triggering a reset via the PCI sysfs
reset would leave the VFs in a state in which the BME and MSI-X enable bits
were all cleared.

To correct that I have added code so that the VF state is saved and restored
as a part of the PF save and restore state functions.  By doing this the VF
state is restored as well as the IOV state allowing the VFs to resume function
following a reset.

Signed-off-by: Alexander Duyck <alexander.h.duyck <at>>
 drivers/pci/iov.c |   48 ++++++++++++++++++++++++++++++++++++++++++++++--
 drivers/pci/pci.c |    2 ++
 drivers/pci/pci.h |    5 +++++
 3 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index de7a747..645ed71 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
 <at>  <at>  -521,13 +521,57  <at>  <at>  resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno)

+ * pci_save_iov_state - Save the state of the VF configurations
+ *  <at> dev: the PCI device
+ */
+int pci_save_iov_state(struct pci_dev *dev)
+	struct pci_dev *vfdev = NULL;
(Continue reading)

Alexander Gordeev | 21 Apr 17:19 2014

[PATCH RESEND 0/2] : block: Use pci_enable_msix_exact()

Hi Jens,

The series is against v3.15-rc1. The patches complete converison
of block layer device drivers to the new MSI initialization API.


Cc: Jens Axboe <axboe <at>>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie <at>>
Cc: Kyungmin Park <kyungmin.park <at>>
Cc: Mike Miller <mike.miller <at>>
Cc: iss_storagedev <at>
Cc: linux-pci <at>

Alexander Gordeev (2):
  skd: Use pci_enable_msix_exact() instead of pci_enable_msix_range()
  cciss: Use pci_enable_msix_exact() instead of pci_enable_msix()

 drivers/block/cciss.c    |    6 +-----
 drivers/block/skd_main.c |    7 +++----
 2 files changed, 4 insertions(+), 9 deletions(-)



Alexander Gordeev | 21 Apr 17:06 2014

[PATCH v2 RESEND] portdrv: Use pci_enable_msix_exact() instead of pci_enable_msix()

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()

Signed-off-by: Alexander Gordeev <agordeev <at>>
Cc: Bjorn Helgaas <bhelgaas <at>>
Cc: linux-pci <at>
 drivers/pci/pcie/portdrv_core.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 986f8ea..0b1efb2 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
 <at>  <at>  -99,7 +99,7  <at>  <at>  static int pcie_port_enable_msix(struct pci_dev *dev, int *vectors, int mask)
 	for (i = 0; i < nr_entries; i++)
 		msix_entries[i].entry = i;

-	status = pci_enable_msix(dev, msix_entries, nr_entries);
+	status = pci_enable_msix_exact(dev, msix_entries, nr_entries);
 	if (status)
 		goto Exit;

 <at>  <at>  -171,7 +171,7  <at>  <at>  static int pcie_port_enable_msix(struct pci_dev *dev, int *vectors, int mask)

(Continue reading)

Ryan Desfosses | 19 Apr 02:13 2014

[PATCH 0/8] patch series

There are eight patches in this series.  All changes are trivial with no
dependencies or required order.
Bjorn Helgaas | 18 Apr 17:42 2014

[GIT PULL] PCI updates for v3.15

Hi Linus,

These are fixes for a powerpc NULL pointer dereference, an OF
interrupt mapping issue on some of the new host bridges, and a DesignWare
iATU issue.


The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:

  Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)

are available in the git repository at:

  git:// pci-v3.15-fixes-1

for you to fetch changes up to f5d3352b2751f8de7e06e23a04ac0b4c474075e9:

  PCI: tegra: Use new OF interrupt mapping when possible (2014-04-16 10:24:32 -0600)

PCI updates for v3.15:

  Host bridge drivers
    - Fix OF interrupt mapping for DesignWare, R-Car, Tegra (Lucas Stach)
    - Fix DesignWare iATU programming (Mohit Kumar)

    - Fix powerpc NULL dereference from list_for_each_entry() update (Mike Qiu)

(Continue reading)

Thomas Petazzoni | 18 Apr 14:19 2014

[PATCH 0/7] Fixes for Armada 370/XP PCIe


This set of commits fixes a number of problems in the PCIe support of
the Armada 370 and Armada XP SoCs, allowing to use PCIe devices that
were not properly supported until now.

Due to the interaction of PCIe with other subsystems, the fixes are
not limited to drivers/pci, but also touch drivers/bus and

Here are the details of the patches:

 * The first three patches are fixes in the MSI handling. They fix
   problems with PCIe device drivers trying to use MSI-X (which we
   don't support), and incorrect freeing of MSIs causing kernel panics
   when PCIe device drivers try to allocate/free MSIs several times.

   They touch drivers/irqchip/ only, and they are independent from the
   rest of the series, both from a build and a runtime point of view.

   These bugs exist since the MSI support was added, in v3.13. The
   commits carry the necessary Fixes and Cc to stable informations.

 * The fourth patch fixes an off-by-one in the computed size of MBus
   windows. This only worked because the mvebu-mbus driver was
   silently accepting invalid sizes. I've marked it for stable because
   it really is bug, but even though it's not visible by itself, it is
   needed for other patches in the series.

   This patch touches drivers/pci/host, and should probably be taken
(Continue reading)