Yijing Wang | 28 Mar 11:02 2015

Assign mem resource fail after remove and rescan

Hi Yinghai, Bjorn
   I found a memory resource assignment fail after I did remove and rescan a bridge device,
I don't know whether this is a kernel bug, I hope could get some advice from you, thanks!

My pci tree:
-[0000:00]-+-00.0  Intel Corporation 2nd Generation Core Processor Family DRAM Controller
...
           +-1c.0-[02-21]----00.0-[03-21]--+-01.0-[04-12]----00.0-[05-12]----19.0-[06-12]----00.0  PLX
Technology, Inc. Device 1009
           |                               +-05.0-[13]--
           |                               +-07.0-[14-20]----00.0-[15-20]--+-08.0-[16]--+-00.0  NVIDIA Corporation GT218 [GeForce 210]
           |                               |                               |            \-00.1  NVIDIA Corporation High Definition Audio Controller
           |                               |                               +-14.0-[17]----00.0  Intel Corporation Device 0953
           |                               |                               \-19.0-[18-20]----00.0  PLX Technology, Inc. Device 1009
           |                               \-09.0-[21]--

Reproduce action:
1. echo 1 > /sys/bus/pci/devices/0000:05:19.0/remove
2. echo 1 > /sys/bus/pci/rescan

After above operations, I found the memory resource assigned fail.

Fail log:
[  105.905480] pci_bus 0000:06: busn_res: [bus 06-12] is released
[  125.771655] pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
[  125.772519] pci 0000:05:19.0: [10b5:9797] type 01 class 0x060400
[  125.772846] pci 0000:05:19.0: PME# supported from D0 D3hot D3cold
[  125.778576] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-12] (conflicts with
(null) [bus 05-12])
[  125.778638] pci 0000:06:00.0: [10b5:1009] type 00 class 0x088000
(Continue reading)

Michael S. Tsirkin | 26 Mar 12:37 2015
Picon

[PATCH v4 00/10] pci: fix unhandled interrupt on shutdown

Fam Zheng noticed that pci shutdown disables msi and msix of a device while
device is still active. This was intended to fix kexec with fusion devices but
had the unintended effect of breaking even regular shutdown when using virtio.

The same problem would affect any driver which doesn't register
a level interrupt handler when using msix.

I think the fix is to avoid touching device on shutdown:
we clear bus master anyway, so we won't get any more
msi interrupts, and bus reset will clear the msi/msix
state eventually anyway.

Patches 1-6 work well for me.
Given they affect all pci devices, and the bug has been there since 2.6 times,
I think there's no rush: we can merge them for 4.1.

At the same time, once merged, patches 1-4 will likely make a good stable
candidate.

Patches 7-10 compiled only, will need maintainer ack.

Please review, and consider at least 1-6 for 4.1.

Changes from v3:
	fix a copy-and-paste error in
	  pci: drop some duplicate code
	other patches are unchanged
	drop Cc stable for now
Changes from v2:
	move code from probe to device enumeration
(Continue reading)

Wei Yang | 25 Mar 09:23 2015
Picon

[PATCH V16 00/20] Enable SRIOV on POWER8

This patchset enables the SRIOV on POWER8.

The general idea is put each VF into one individual PE and allocate required
resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
allocation and adjustment for PF's IOV BAR.

On P8, we use M64BT to cover a PF's IOV BAR, which could make an individual VF
sit in its own PE. This gives more flexiblity, while at the mean time it
brings on some restrictions on the PF's IOV BAR size and alignment.

To achieve this effect, we need to do some hack on pci devices's resources.
1. Expand the IOV BAR properly.
   Done by pnv_pci_ioda_fixup_iov_resources().
2. Shift the IOV BAR properly.
   Done by pnv_pci_vf_resource_shift().
3. IOV BAR alignment is calculated by arch dependent function instead of an
   individual VF BAR size.
   Done by pnv_pcibios_sriov_resource_alignment().
4. Take the IOV BAR alignment into consideration in the sizing and assigning.
   This is achieved by commit: "PCI: Take additional IOV BAR alignment in
   sizing and assigning"

Test Environment:
       The SRIOV device tested is Emulex Lancer(10df:e220) and
       Mellanox ConnectX-3(15b3:1003) on POWER8.

Examples on pass through a VF to guest through vfio:
	1. unbind the original driver and bind to vfio-pci driver
	   echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
	   echo  1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
(Continue reading)

Jiang Liu | 25 Mar 08:17 2015
Picon

[Bugfix v2] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716

Before commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
interfaces to simplify implementation"), arch/x86/pci/acpi.c applies
following rules when parsing ACPI resources for PCI host bridge:
1) Ignore IO port resources defined by acpi_resource_io and
   acpi_resource_fixed_io, which should be used to define resource
   for PCI device instead of PCI bridge.
2) Accept IOMEM resource defined by acpi_resource_memory24,
   acpi_resource_memory32 and acpi_resource_fixed_memory32.
   These IOMEM resources are accepted to workaround some BIOS issue,
   though they should be ignored. For example, PC Engines APU.1C
   platform defines PCI host bridge IOMEM resources as:
                Memory32Fixed (ReadOnly,
                    0x000A0000,         // Address Base
                    0x00020000,         // Address Length
                    )
                Memory32Fixed (ReadOnly,
                    0x00000000,         // Address Base
                    0x00000000,         // Address Length
                    _Y00)
3) Accept all IO port and IOMEM resources defined by
   acpi_resource_address{16,32,64,extended64}, no matter it's marked as
   ACPI_CONSUMER or ACPI_PRODUCER.

Commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces
to simplify implementation") accept all IO port and IOMEM resources
defined by acpi_resource_io, acpi_resource_fixed_io,
acpi_resource_memory24, acpi_resource_memory32,
acpi_resource_fixed_memory32 and
acpi_resource_address{16,32,64,extended64}, which causes IO port
resources consumed by host bridge itself are listed in host bridge
(Continue reading)

Ray Jui | 25 Mar 08:08 2015

[PATCH v2 0/2] iProc PCIe driver Kconfig changes

This patch series contains two patches to address iProc PCIe Kconfig related
issues. The first patch adds more protection to PCIE_IPROC so it cannot be
accidentally enabled for non-ARM based platforms. The second patch changes the
config name of the iProc PCIe platform driver from PCIE_IPROC_PLTFM to
PCIE_IPROC_PLATFORM. The driver name is also changed from pcie-iproc-pltfm.c
to pcie-iproc-platform.c so it's consistent with the config name change.

Changes from v1:
 - Changes the driver name from pcie-iproc-pltfm.c to pcie-iproc-platform.c

Ray Jui (2):
  pci: iproc: fix PCIE_IPROC in Kconfig
  pci: iproc: change PCIE_IPROC_PLTFM to PCIE_IPROC_PLATFORM

 drivers/pci/host/Kconfig                           |    4 +++-
 drivers/pci/host/Makefile                          |    2 +-
 .../{pcie-iproc-pltfm.c => pcie-iproc-platform.c}  |    0
 3 files changed, 4 insertions(+), 2 deletions(-)
 rename drivers/pci/host/{pcie-iproc-pltfm.c => pcie-iproc-platform.c} (100%)

--

-- 
1.7.9.5

Ray Jui | 25 Mar 07:42 2015

[PATCH 0/2] iProc PCIe driver Kconfig changes

This patch series contains two patches to address iProc PCIe Kconfig related
issues. The first patch adds more protection to PCIE_IPROC so it cannot be
accidentally enabled for non-ARM based platforms. The second patch changes the
config name of the iProc PCIe platform driver from PCIE_IPROC_PLTFM to
PCIE_IPROC_PLATFORM 

Ray Jui (2):
  pci: iproc: fix PCIE_IPROC in Kconfig
  pci: iproc: change PCIE_IPROC_PLTFM to PCIE_IPROC_PLATFORM

 drivers/pci/host/Kconfig  |    4 +++-
 drivers/pci/host/Makefile |    2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

--

-- 
1.7.9.5

Wei Yang | 25 Mar 06:44 2015
Picon

[PATCH V15 00/21] Enable SRIOV on POWER8

This patchset enables the SRIOV on POWER8.

The general idea is put each VF into one individual PE and allocate required
resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
allocation and adjustment for PF's IOV BAR.

On P8, we use M64BT to cover a PF's IOV BAR, which could make an individual VF
sit in its own PE. This gives more flexiblity, while at the mean time it
brings on some restrictions on the PF's IOV BAR size and alignment.

To achieve this effect, we need to do some hack on pci devices's resources.
1. Expand the IOV BAR properly.
   Done by pnv_pci_ioda_fixup_iov_resources().
2. Shift the IOV BAR properly.
   Done by pnv_pci_vf_resource_shift().
3. IOV BAR alignment is calculated by arch dependent function instead of an
   individual VF BAR size.
   Done by pnv_pcibios_sriov_resource_alignment().
4. Take the IOV BAR alignment into consideration in the sizing and assigning.
   This is achieved by commit: "PCI: Take additional IOV BAR alignment in
   sizing and assigning"

Test Environment:
       The SRIOV device tested is Emulex Lancer(10df:e220) and
       Mellanox ConnectX-3(15b3:1003) on POWER8.

Examples on pass through a VF to guest through vfio:
	1. unbind the original driver and bind to vfio-pci driver
	   echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
	   echo  1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
(Continue reading)

Jaehoon Chung | 25 Mar 06:13 2015

[PATCH] pci: pci-exynos: fixed the sentence error

There is the sentence error.
Changed the semicolon instead of comma.

Signed-off-by: Jaehoon Chung <jh80.chung <at> samsung.com>
---
 drivers/pci/host/pci-exynos.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index d202b37..c139237 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
 <at>  <at>  -396,7 +396,7  <at>  <at>  static void exynos_pcie_enable_irq_pulse(struct pcie_port *pp)

 	/* enable INTX interrupt */
 	val = IRQ_INTA_ASSERT | IRQ_INTB_ASSERT |
-		IRQ_INTC_ASSERT | IRQ_INTD_ASSERT,
+		IRQ_INTC_ASSERT | IRQ_INTD_ASSERT;
 	exynos_elb_writel(exynos_pcie, val, PCIE_IRQ_EN_PULSE);
 }

--

-- 
1.9.1

Ray Jui | 24 Mar 06:33 2015

[PATCH] pci: iproc: fix PCIE_IPROC in Kconfig

Make PCIE_IPROC depending on both OF and ARM and default to be disabled,
so it cannot be accidentally enabled by other platforms

PCIE_IPROC is meant to be enabled by a front-end bus driver. Curenntly
it's enabled by PCIE_IPROC_PLTFM driver

Signed-off-by: Ray Jui <rjui <at> broadcom.com>
---
 drivers/pci/host/Kconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index feccd0d..963b507 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
 <at>  <at>  -108,6 +108,8  <at>  <at>  config PCI_VERSATILE

 config PCIE_IPROC
 	tristate "Broadcom iProc PCIe controller"
+	depends on OF && ARM
+	default n
 	help
 	  This enables the iProc PCIe core controller support for Broadcom's
 	  iProc family of SoCs. An appropriate bus interface driver also needs
--

-- 
1.7.9.5

kbuild test robot | 23 Mar 19:08 2015
Picon

[pci:pci/enumeration-yw7 32/35] drivers/pci/host-bridge.c:147:24: sparse: symbol 'pci_find_host_bridge' was not declared. Should it be static?

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/enumeration-yw7
head:   2681a1f3d2011d4cbb888d3e974a13bda85d225c
commit: 2577ed41b6a6db3117713069e49b72091b60c867 [32/35] PCI: rename to pci_find_host_bridge()
reproduce:
  # apt-get install sparse
  git checkout 2577ed41b6a6db3117713069e49b72091b60c867
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__

sparse warnings: (new ones prefixed by >>)

>> drivers/pci/host-bridge.c:147:24: sparse: symbol 'pci_find_host_bridge' was not declared.
Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild                 Intel Corporation
Gavin Shan | 23 Mar 04:02 2015
Picon

[PATCH v3 1/2] PCI: One more parameter to pci_set_pcie_reset_state()

The patch adds one more parameter ("probe") to pci_set_pcie_reset_state(),
which allows to check if one particular PCI device can be resetted by the
function. The function will be reused to support PCI device specific methods
maintained in pci_dev_reset_methods[] in subsequent patch.

Cc: Brian King <brking <at> us.ibm.com>
Cc: Frank Haverkamp <haver <at> linux.vnet.ibm.com>
Cc: Ian Munsie <imunsie <at> au1.ibm.com>
Signed-off-by: Gavin Shan <gwshan <at> linux.vnet.ibm.com>
---
v3: Fix arguments of pci_set_pcie_reset_state() in cxl driver
v2: Reimplemented based on pci_set_pcie_reset_state()
---
 arch/powerpc/kernel/eeh.c       | 14 ++++++++++----
 drivers/misc/cxl/pci.c          |  2 +-
 drivers/misc/genwqe/card_base.c |  9 +++++++--
 drivers/pci/pci.c               | 15 +++++++++------
 drivers/scsi/ipr.c              |  5 +++--
 include/linux/pci.h             |  5 +++--
 6 files changed, 33 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index daa68a1..cd85c18 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
 <at>  <at>  -726,11 +726,14  <at>  <at>  static void *eeh_restore_dev_state(void *data, void *userdata)
  * pcibios_set_pcie_slot_reset - Set PCI-E reset state
  *  <at> dev: pci device struct
  *  <at> state: reset state to enter
+ *  <at> probe: check if the device can take the reset
(Continue reading)


Gmane