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

drivers/pci/hotplug: Fix initial state for empty slot

2017-03-15T02:02:46+00:00

commit d0c424971f70501ec0a0364117b9934db039c9cc upstream.

In PowerNV PCI hotplug driver, the initial PCI slot's state is set
to PNV_PHP_STATE_POPULATED if no PCI devices are connected to the
slot. The PCI devices that are hot added to the slot won't be probed
and populated because of the check in pnv_php_enable():

        /* Check if the slot has been configured */
        if (php_slot->state != PNV_PHP_STATE_REGISTERED)
                return 0;

This fixes the issue by leaving the slot in PNV_PHP_STATE_REGISTERED
state initially if nothing is connected to the slot.

Fixes: 360aebd85a4 ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
Reported-by: Hank Chang 
Signed-off-by: Gavin Shan 
Tested-by: Willie Liauw 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

drivers/pci/hotplug: Handle presence detection change properly

2017-03-15T02:02:46+00:00

commit d7d55536c6cd1f80295b6d7483ad0587b148bde4 upstream.

The surprise hotplug is driven by interrupt in PowerNV PCI hotplug
driver. In the interrupt handler, pnv_php_interrupt(), we bail when
pnv_pci_get_presence_state() returns zero wrongly. It causes the
presence change event is always ignored incorrectly.

This fixes the issue by bailing on error (non-zero value) returned
from pnv_pci_get_presence_state().

Fixes: 360aebd85a4 ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
Reported-by: Hank Chang 
Signed-off-by: Gavin Shan 
Tested-by: Willie Liauw 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

pci/hotplug/pnv-php: Disable surprise hotplug capability on conflicts

2017-03-15T02:02:45+00:00

commit 303529d6ef1293513c2c73c9ab86489eebb37d08 upstream.

The root port or PCIe switch downstream port might have been associated
with driver other than pnv-php. The MSI or MSIx might also have been
enabled by that driver (e.g. pcieport_drv). Attempt to enable MSI incurs
below backtrace:

 PowerPC PowerNV PCI Hotplug Driver version: 0.1
 ------------[ cut here ]------------
 WARNING: CPU: 19 PID: 1004 at drivers/pci/msi.c:1071 \
                              __pci_enable_msi_range+0x84/0x4e0
 NIP [c000000000665c34] __pci_enable_msi_range+0x84/0x4e0
 LR [c000000000665c24] __pci_enable_msi_range+0x74/0x4e0
 Call Trace:
 [c000000384d67600] [c000000000665c24] __pci_enable_msi_range+0x74/0x4e0
 [c000000384d676e0] [d00000000aa31b04] pnv_php_register+0x564/0x5a0 [pnv_php]
 [c000000384d677c0] [d00000000aa31658] pnv_php_register+0xb8/0x5a0 [pnv_php]
 [c000000384d678a0] [d00000000aa31658] pnv_php_register+0xb8/0x5a0 [pnv_php]
 [c000000384d67980] [d00000000aa31dfc] pnv_php_init+0x60/0x98 [pnv_php]
 [c000000384d679f0] [c00000000000cfdc] do_one_initcall+0x6c/0x1d0
 [c000000384d67ab0] [c000000000b92354] do_init_module+0x94/0x254
 [c000000384d67b40] [c00000000019719c] load_module+0x258c/0x2c60
 [c000000384d67d30] [c000000000197bb0] SyS_finit_module+0xf0/0x170
 [c000000384d67e30] [c00000000000b184] system_call+0x38/0xe0

This fixes the issue by skipping enabling the surprise hotplug
capability if the MSI or MSIx on the PCI slot's upstream port has
been enabled by other driver.

Fixes: 360aebd85a4c ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
Signed-off-by: Gavin Shan 
Reviewed-by: Andrew Donnellan 
Tested-by: Vaibhav Jain 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

pci/hotplug/pnv-php: Remove WARN_ON() in pnv_php_put_slot()

2017-03-15T02:02:45+00:00

commit 36c7c9da40c408a71e5e6bfe12e57dcf549a296d upstream.

The WARN_ON() causes unnecessary backtrace when putting the parent
slot, which is likely to be NULL.

 WARNING: CPU: 2 PID: 1071 at drivers/pci/hotplug/pnv_php.c:85 \
                              pnv_php_release+0xcc/0x150 [pnv_php]
    :
 Call Trace:
 [c0000003bc007c10] [d00000000ad613c4] pnv_php_release+0x144/0x150 [pnv_php]
 [c0000003bc007c40] [c0000000006641d8] pci_hp_deregister+0x238/0x330
 [c0000003bc007cd0] [d00000000ad61440] pnv_php_unregister_one+0x70/0xa0 [pnv_php]
 [c0000003bc007d10] [d00000000ad614c0] pnv_php_unregister+0x50/0x80 [pnv_php]
 [c0000003bc007d40] [d00000000ad61e84] pnv_php_exit+0x50/0xcb4 [pnv_php]
 [c0000003bc007d70] [c00000000019499c] SyS_delete_module+0x1fc/0x2a0
 [c0000003bc007e30] [c00000000000b184] system_call+0x38/0xe0

Fixes: 66725152fb9f ("PCI/hotplug: PowerPC PowerNV PCI hotplug driver")
Signed-off-by: Gavin Shan 
Reviewed-by: Andrew Donnellan 
Tested-by: Vaibhav Jain 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

PCI: altera: Fix TLP_CFG_DW0 for TLP write

2017-03-12T05:41:47+00:00

commit 2a7275a3d867b228216886aae35e1f64291180b1 upstream.

eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage") used
TLP_FMTTYPE_CFGRD* (instead of TLP_FMTTYPE_CFGWR*) for TLP writes, which
causes writing to configuration space to fail.  Fix it by using correct
FMTTYPE for write operation.

Fixes: eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage")
Signed-off-by: Ley Foon Tan 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

pci/hotplug/pnv-php: Disable MSI and PCI device properly

2017-03-12T05:41:47+00:00

commit 49f4b08e61547a5ccd2db551d994c4503efe5666 upstream.

pnv_php_disable_irq() can be called in two paths: Bailing path in
pnv_php_enable_irq() or releasing slot. The MSI (or MSIx) interrupts
is disabled unconditionally in pnv_php_disable_irq(). It's wrong
because that might be enabled by drivers other than pnv-php.

This disables MSI (or MSIx) interrupts and the PCI device only if
it was enabled by pnv-php. In the error path of pnv_php_enable_irq(),
we rely on the newly added parameter @disable_device. In the path
of releasing slot, @pnv_php->irq is checked.

Fixes: 360aebd85a4c ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
Signed-off-by: Gavin Shan 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal

2017-03-12T05:41:47+00:00

commit 60e2e2fbafdd1285ae1b4ad39ded41603e0c74d0 upstream.

The devfn of 00:02.0 is 0x10.  devfn_to_wslot(0x10) == 0x2, and
wslot_to_devfn(0x2) should be 0x10, while it's 0x2 in the current code.

Due to this, hv_eject_device_work() -> pci_get_domain_bus_and_slot()
returns NULL and pci_stop_and_remove_bus_device() is not called.

Later when the real device driver's .remove() is invoked by
hv_pci_remove() -> pci_stop_root_bus(), some warnings can be noticed
because the VM has lost the access to the underlying device at that
time.

Signed-off-by: Jake Oshins 
Signed-off-by: Dexuan Cui 
Signed-off-by: Bjorn Helgaas 
Acked-by: Haiyang Zhang 
CC: K. Y. Srinivasan 
CC: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

PCI/PME: Restore pcie_pme_driver.remove

2017-02-23T16:44:36+00:00

commit afe3e4d11bdf50a4c3965eb6465ba6bebbcf5dcf upstream.

In addition to making PME non-modular, d7def2040077 ("PCI/PME: Make
explicitly non-modular") removed the pcie_pme_driver .remove() method,
pcie_pme_remove().

pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe().
The fact that we don't free the IRQ after d7def2040077 causes the following
crash when removing a PCIe port device via /sys:

  ------------[ cut here ]------------
  kernel BUG at drivers/pci/msi.c:370!
  invalid opcode: 0000 [#1] SMP
  Modules linked in:
  CPU: 1 PID: 14509 Comm: sh Tainted: G    W  4.8.0-rc1-yh-00012-gd29438d
  RIP: 0010:[]  free_msi_irqs+0x65/0x190
  ...
  Call Trace:
   [] pci_disable_msi+0x34/0x40
   [] cleanup_service_irqs+0x27/0x30
   [] pcie_port_device_remove+0x2a/0x40
   [] pcie_portdrv_remove+0x40/0x50
   [] pci_device_remove+0x4b/0xc0
   [] __device_release_driver+0xb6/0x150
   [] device_release_driver+0x25/0x40
   [] pci_stop_bus_device+0x74/0xa0
   [] 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
   [] ? percpu_down_read+0x44/0x80
   [] ? __sb_start_write+0xa7/0xe0
   [] ? __sb_start_write+0xa7/0xe0
   [] vfs_write+0xc4/0x180
   [] SyS_write+0x49/0xa0
   [] do_syscall_64+0xa6/0x1b0
   [] entry_SYSCALL64_slow_path+0x25/0x25
  ...
   RIP  [] free_msi_irqs+0x65/0x190
   RSP 
  ---[ end trace f4505e1dac5b95d3 ]---
  Segmentation fault

Restore pcie_pme_remove().

[bhelgaas: changelog]
Fixes: d7def2040077 ("PCI/PME: Make explicitly non-modular")
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PCI/ASPM: Handle PCI-to-PCIe bridges as roots of PCIe hierarchies

2017-02-09T07:08:25+00:00

commit 030305d69fc6963c16003f50d7e8d74b02d0a143 upstream.

In a struct pcie_link_state, link->root points to the pcie_link_state of
the root of the PCIe hierarchy.  For the topmost link, this points to
itself (link->root = link).  For others, we copy the pointer from the
parent (link->root = link->parent->root).

Previously we recognized that Root Ports originated PCIe hierarchies, but
we treated PCI/PCI-X to PCIe Bridges as being in the middle of the
hierarchy, and when we tried to copy the pointer from link->parent->root,
there was no parent, and we dereferenced a NULL pointer:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
  IP: [] pcie_aspm_init_link_state+0x170/0x820

Recognize that PCI/PCI-X to PCIe Bridges originate PCIe hierarchies just
like Root Ports do, so link->root for these devices should also point to
itself.

Fixes: 51ebfc92b72b ("PCI: Enumerate switches below PCI-to-PCIe bridges")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193411
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1022181
Tested-by: lists@ssl-mail.com
Tested-by: Jayachandran C. 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: Enumerate switches below PCI-to-PCIe bridges

2017-01-26T07:24:38+00:00

commit 51ebfc92b72b4f7dac1ab45683bf56741e454b8c upstream.

A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
interface and a PCI Express secondary interface.  The PCIe interface is a
Downstream Port that originates a Link.  See the "PCI Express to PCI/PCI-X
Bridge Specification", rev 1.0, sections 1.2 and A.6.

The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below
the bridge:

  00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a]
  01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a]
  02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a]
  03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a]

01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by
lspci).  As we traverse a PCIe hierarchy, device connections alternate
between PCIe Links and internal Switch logic.  Previously we did not
recognize that 01:00.0 had a secondary link, so we thought the 02:00.0
Upstream Port *did* have a secondary link.  In fact, it's the other way
around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic
on its secondary side.

When we thought 02:00.0 had a secondary link, the pci_scan_slot() ->
only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0
was the only possible downstream device.  But 03:00.0 doesn't exist, so we
didn't look for any other devices on bus 03.

Booting with "pci=pcie_scan_all" is a workaround, but we don't want users
to have to do that.

Recognize that PCI-to-PCIe bridges originate links on their secondary
interfaces.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361
Fixes: d0751b98dfa3 ("PCI: Add dev->has_secondary_link to track downstream PCIe links")
Tested-by: Blake Moore 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman