linux-toradex.git/drivers/pci, branch v4.11

PCI: hisi: Fix DT binding (hisi-pcie-almost-ecam)

2017-04-12T15:46:47+00:00

The "hisilicon,pcie-almost-ecam" binding goes against the usual DT
conventions, and is non-sensical in that it describes the IP based on
what it isn't.  Fix the DT binding with "hisilicon,hip06-pcie-ecam"
and "hisilicon,hip07-pcie-ecam".

Signed-off-by: Mark Rutland 
Signed-off-by: Dongdong Liu 
Signed-off-by: Bjorn Helgaas

PCI: dwc: Fix dw_pcie_ops NULL pointer dereference

2017-04-04T13:24:25+00:00

Fix a crash from dereferencing a NULL dw_pcie_ops pointer.  For example,
on ARTPEC-6:

  Unable to handle kernel NULL pointer dereference at virtual address 00000004
  pgd = c0204000
  [00000004] *pgd=00000000
  Internal error: Oops: 5 [#1] SMP ARM
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
  Hardware name: Axis ARTPEC-6 Platform
  task: db098000 task.stack: db096000
  PC is at dw_pcie_writel_dbi+0x2c/0xd0

Prior to 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into
host-only and core structures"), every driver had a struct pcie_host_ops
with function pointers, typically used as:

  if (pp->ops->readl_rc)
    return pp->ops->readl_rc(...);

442ec4c04d12 split struct pcie_host_ops into two pieces: struct
dw_pcie_host_ops and struct dw_pcie_ops, so the above became:

  if (pci->ops->readl_dbi)
    return pci->ops->readl_dbi(...);

But pcie-artpec6.c and pcie-designware-plat.c don't need the dw_pcie_ops
pointers and didn't supply a pci->ops struct, which leads to NULL pointer
dereferences.

Supply an empty struct dw_pcie_ops to avoid the NULL pointer dereferences.

[bhelgaas: changelog]
Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only and core structures")
Signed-off-by: Niklas Cassel 
Signed-off-by: Bjorn Helgaas 
Acked-by: Kishon Vijay Abraham I 
Acked-by: Joao Pinto

PCI: dwc: Select PCI_HOST_COMMON for hisi

2017-04-03T21:17:11+00:00

Without PCI_HOST_COMMON support enabled, we get a link error:

  drivers/pci/dwc/built-in.o: In function `hisi_pcie_map_bus':
  pcie-hisi.c:(.text+0x8860): undefined reference to `pci_ecam_map_bus'
  drivers/pci/dwc/built-in.o: In function `hisi_pcie_almost_ecam_probe':
  pcie-hisi.c:(.text+0x88b4): undefined reference to `pci_host_common_probe'

Add an explicit 'select', as the other users have.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jingoo Han

PCI: thunder-pem: Fix legacy firmware PEM-specific resources

2017-04-03T20:10:21+00:00

SZ_16M PEM resource size includes PEM-specific register and its children
resources. Reservation of the whole SZ_16M range leads to child device
driver failure when pcieport driver is requesting resources:

  pcieport 0004:1f:00.0: can't enable device: BAR 0 [mem 0x87e0c0f00000-0x87e0c0ffffff 64bit] not claimed

So we cannot reserve full 16M here and instead we want to reserve
PEM-specific register only which is SZ_64K.

At the end increase PEM resource to SZ_16M since this is what
thunder_pem_init() call expects for proper initialization.

Fixes: 9abb27c7594a ("PCI: thunder-pem: Add legacy firmware support for Cavium ThunderX host controller")
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v4.10+

PCI: thunder-pem: Add legacy firmware support for Cavium ThunderX host controller

2017-03-23T22:11:26+00:00

During early days of PCI quirks support, ThunderX firmware did not provide
PNP0c02 node with PCI configuration space and PEM-specific register ranges.
This means that for legacy FW we are not reserving these resources and
cannot gather PEM-specific resources for further PEM initialization.

To support already deployed legacy FW, calculate PEM-specific ranges and
provide resources reservation as fallback scenario into PEM driver when we
could not gather PEM reg base from ACPI tables.

Tested-by: Robert Richter 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Vadim Lomovtsev 
Signed-off-by: Bjorn Helgaas 
Acked-by: Robert Richter 
CC: stable@vger.kernel.org	# v4.10+

PCI: thunder-pem: Use Cavium assigned hardware ID for ThunderX host controller

2017-03-23T22:10:10+00:00

"CAV" is the only PNP/ACPI hardware ID vendor prefix assigned to Cavium so
fix this as it should be from day one.

Fixes: 44f22bd91e88 ("PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller")
Tested-by: Robert Richter 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Bjorn Helgaas 
Acked-by: Robert Richter 
CC: stable@vger.kernel.org	# v4.10+

PCI: iproc: Save host bridge window resource in struct iproc_pcie

2017-03-09T17:27:07+00:00

The host bridge memory window resource is inserted into the iomem_resource
tree and cannot be deallocated until the host bridge itself is removed.

Previously, the window was on the stack, which meant the iomem_resource
entry pointed into the stack and was corrupted as soon as the probe
function returned, which caused memory corruption and errors like this:

  pcie_iproc_bcma bcma0:8: resource collision: [mem 0x40000000-0x47ffffff] conflicts with PCIe MEM space [mem 0x40000000-0x47ffffff]

Move the memory window resource from the stack into struct iproc_pcie so
its lifetime matches that of the host bridge.

Fixes: c3245a566400 ("PCI: iproc: Request host bridge window resources")
Reported-and-tested-by: Rafał Miłecki 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v4.8+

PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove

2017-03-07T20:23:30+00:00

We call pcie_aspm_exit_link_state() when we remove a device.  If the device
is the last PCIe function to be removed below a bridge and the bridge has
an ASPM link_state struct, we disable ASPM on the link.  Disabling ASPM
requires link->downstream (used in pcie_config_aspm_link()).

We previously set link->downstream in pcie_aspm_cap_init(), but only if the
device was not blacklisted.  Removing the blacklisted device caused a NULL
pointer dereference in the pcie_aspm_exit_link_state() ->
pcie_config_aspm_link() path:

  # echo 1 > /sys/bus/pci/devices/0000\:0b\:00.0/remove
  ...
   BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
   IP: pcie_config_aspm_link+0x5d/0x2b0
   Call Trace:
    pcie_aspm_exit_link_state+0x75/0x130
    pci_stop_bus_device+0xa4/0xb0
    pci_stop_and_remove_bus_device_locked+0x1a/0x30
    remove_store+0x50/0x70
    dev_attr_store+0x18/0x30
    sysfs_kf_write+0x44/0x60
    kernfs_fop_write+0x10e/0x190
    __vfs_write+0x28/0x110
    ? rcu_read_lock_sched_held+0x5d/0x80
    ? rcu_sync_lockdep_assert+0x2c/0x60
    ? __sb_start_write+0x173/0x1a0
    ? vfs_write+0xb3/0x180
    vfs_write+0xc4/0x180
    SyS_write+0x49/0xa0
    do_syscall_64+0xa6/0x1c0
    entry_SYSCALL64_slow_path+0x25/0x25
   ---[ end trace bd187ee0267df5d9 ]---

To avoid this, set link->downstream in alloc_pcie_link_state(), so every
pcie_link_state structure has a valid link->downstream pointer.

[bhelgaas: changelog]
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rajat Jain 
CC: stable@vger.kernel.org

PCI: Prevent VPD access for QLogic ISP2722

2017-03-07T20:16:57+00:00

QLogic ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter has the VPD
access issue too, while read the common pci-sysfs access interface shown as

 /sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/vpd

with simple 'cat' could cause system hang and panic:

  Kernel panic - not syncing: An NMI occurred. Depending on your system the reason for the NMI is logged in any one of the following resources:
  1. Integrated Management Log (IML)
  2. OA Syslog
  3. OA Forward Progress Log
  4. iLO Event Log
  CPU: 0 PID: 15070 Comm: udevadm Not tainted 4.1.12
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
   0000000000000086 000000007f0cdf51 ffff880c4fa05d58 ffffffff817193de
   ffffffffa00b42d8 0000000000000075 ffff880c4fa05dd8 ffffffff81714072
   0000000000000008 ffff880c4fa05de8 ffff880c4fa05d88 000000007f0cdf51
  Call Trace:
     [] dump_stack+0x63/0x81
   [] panic+0xd0/0x20e
   [] hpwdt_pretimeout+0xdd/0xe0 [hpwdt]
   [] ? sched_clock+0x9/0x10
   [] nmi_handle+0x91/0x170
   [] ? nmi_handle+0x9c/0x170
   [] io_check_error+0x1e/0xa0
   [] default_do_nmi+0x99/0x140
   [] do_nmi+0xf4/0x170
   [] end_repeat_nmi+0x1a/0x1e
   [] ? pci_conf1_read+0xeb/0x120
   [] ? pci_conf1_read+0xeb/0x120
   [] ? pci_conf1_read+0xeb/0x120
   <>  [] raw_pci_read+0x23/0x40
   [] pci_read+0x2c/0x30
   [] pci_user_read_config_word+0x72/0x110
   [] pci_vpd_pci22_wait+0x96/0x130
   [] pci_vpd_pci22_read+0xdb/0x1a0
   [] pci_read_vpd+0x20/0x30
   [] read_vpd_attr+0x30/0x40
   [] sysfs_kf_bin_read+0x47/0x70
   [] kernfs_fop_read+0xae/0x180
   [] __vfs_read+0x37/0x100
   [] ? security_file_permission+0x84/0xa0
   [] ? rw_verify_area+0x56/0xe0
   [] vfs_read+0x86/0x140
   [] SyS_read+0x55/0xd0
   [] system_call_fastpath+0x12/0x71
  Shutting down cpus with NMI
  Kernel Offset: disabled
  drm_kms_helper: panic occurred, switching back to text console

So blacklist the access to its VPD.

Signed-off-by: Ethan Zhao 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v4.6+

PCI: exynos: Initialize elbi_base even when using PHY framework

2017-03-07T18:46:38+00:00

Even when using the PHY framework, we need the elbi_base.  Before this
patch, we didn't initialize elbi_base, which caused NULL pointer
dereferences later.

Fixes: e7cd7ef58e1f ("PCI: exynos: Support the PHY generic framework")
Signed-off-by: Jaehoon Chung 
Signed-off-by: Bjorn Helgaas