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

PCI: pciehp: Wait for hotplug command completion where necessary

2015-07-21T17:10:15+00:00

commit a5dd4b4b0570b3bf880d563969b245dfbd170c1e upstream.

The commit referenced below deferred waiting for command completion until
the start of the next command, allowing hardware to do the latching
asynchronously.  Unfortunately, being ready to accept a new command is the
only indication we have that the previous command is completed.  In cases
where we need that state change to be enabled, we must still wait for
completion.  For instance, pciehp_reset_slot() attempts to disable anything
that might generate a surprise hotplug on slots that support presence
detection.  If we don't wait for those settings to latch before the
secondary bus reset, we negate any value in attempting to prevent the
spurious hotplug.

Create a base function with optional wait and helper functions so that
pcie_write_cmd() turns back into the "safe" interface which waits before
and after issuing a command and add pcie_write_cmd_nowait(), which
eliminates the trailing wait for asynchronous completion.  The following
functions are returned to their previous behavior:

  pciehp_power_on_slot
  pciehp_power_off_slot
  pcie_disable_notification
  pciehp_reset_slot

The rationale is that pciehp_power_on_slot() enables the link and therefore
relies on completion of power-on.  pciehp_power_off_slot() and
pcie_disable_notification() need a wait because data structures may be
freed after these calls and continued signaling from the device would be
unexpected.  And, of course, pciehp_reset_slot() needs to wait for the
scenario outlined above.

Fixes: 3461a068661c ("PCI: pciehp: Wait for hotplug command completion lazily")
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: Add pci_bus_addr_t

2015-07-21T17:10:14+00:00

commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d upstream.

David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") fails to boot on sparc/T5-8:

pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)

The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that
tripped over this mismatch.

Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses. This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.

[bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
least as wide as dma_addr_t, documentation]
Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
Reported-by: David Ahern
Tested-by: David Ahern
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Acked-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman

PCI: Propagate the "ignore hotplug" setting to parent

2015-07-21T17:10:14+00:00

commit 0824965140fff1bf640a987dc790d1594a8e0699 upstream.

Refine the mechanism introduced by commit f244d8b623da ("ACPIPHP / radeon /
nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the
ignore_hotplug setting of the device to its parent bridge in case hotplug
notifications related to the graphics adapter switching are given for the
bridge rather than for the device itself (they need to be ignored in both
cases).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891
Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927
Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
Reported-and-tested-by: tiagdtd-lava 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'pci-v4.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2015-04-09T17:17:44+00:00

Pull PCI fixes from Bjorn Helgaas:
 "Here are some fixes for v4.0.  I apologize for how late they are.  We
  were hoping for some better fixes, but couldn't get them polished in
  time.  These fix:

   - a Xen domU oops with PCI passthrough devices
   - a sparc T5 boot failure
   - a STM SPEAr13xx crash (use after initdata freed)
   - a cpcihp hotplug driver thinko
   - an AER thinko that printed stack junk

  Details:

  Enumeration
    - Don't look for ACPI hotplug parameters if ACPI is disabled (Bjorn Helgaas)

  Resource management
    - Revert "sparc/PCI: Clip bridge windows to fit in upstream windows" (Bjorn Helgaas)

  AER
    - Avoid info leak in __print_tlp_header() (Rasmus Villemoes)

  PCI device hotplug
    - Add missing curly braces in cpci_configure_slot() (Dan Carpenter)

  ST Microelectronics SPEAr13xx host bridge driver
    - Drop __initdata from spear13xx_pcie_driver (Matwey V. Kornilov)

* tag 'pci-v4.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  Revert "sparc/PCI: Clip bridge windows to fit in upstream windows"
  PCI: Don't look for ACPI hotplug parameters if ACPI is disabled
  PCI: cpcihp: Add missing curly braces in cpci_configure_slot()
  PCI/AER: Avoid info leak in __print_tlp_header()
  PCI: spear: Drop __initdata from spear13xx_pcie_driver

PCI: Don't look for ACPI hotplug parameters if ACPI is disabled

2015-04-08T14:59:55+00:00

Booting a v3.18 or newer Xen domU kernel with PCI devices passed through
results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0
hypervisor and 32-bit domU):

  BUG: unable to handle kernel paging request at 0030303e
  IP: [] acpi_ns_validate_handle+0x12/0x1a
  Call Trace:
   [] ? acpi_evaluate_object+0x31/0x1fc
   [] ? pci_get_hp_params+0x111/0x4e0
   [] ? xen_force_evtchn_callback+0x17/0x30
   [] ? xen_restore_fl_direct_reloc+0x4/0x4
   [] ? pci_device_add+0x24/0x450

Don't look for ACPI configuration information if ACPI has been disabled.

I don't think this is the best fix, because we can boot plain Linux (no
Xen) with "acpi=off", and we don't need this check in pci_get_hp_params().
There should be a better fix that would make Xen domU work the same way.
The domU kernel has ACPI support but it has no AML.  There should be a way
to initialize the ACPI data structures so things fail gracefully rather
than oopsing.  This is an interim fix to address the regression.

Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301
Reported-by: Michael D Labriola 
Tested-by: Michael D Labriola 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v3.18+

Merge tag 'pci-v4.0-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2015-03-12T16:45:46+00:00

Pull PCI fixes from Bjorn Helgaas:
 "Here are a couple updates for v4.0.

  One fixes a config accessor problem on APM X-Gene that we introduced
  when switching to generic config accessors, and the other fixes an
  older read-past-end-of-buffer problem in sysfs.

  APM X-Gene host bridge driver
    - Add register offset to config space base address (Feng Kan)

  Miscellaneous
    - Don't read past the end of sysfs "driver_override" buffer (Sasha Levin)"

* tag 'pci-v4.0-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: xgene: Add register offset to config space base address
  PCI: Don't read past the end of sysfs "driver_override" buffer

PCI: cpcihp: Add missing curly braces in cpci_configure_slot()

2015-03-12T16:22:10+00:00

I don't have this hardware but it looks like we weren't adding bridge
devices as intended.  Maybe the bridge is always the last device?

Fixes: 05b125004815 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7")
Signed-off-by: Dan Carpenter 
Signed-off-by: Bjorn Helgaas 
Acked-by: Yijing Wang 
CC: stable@vger.kernel.org	# v3.9+

PCI/AER: Avoid info leak in __print_tlp_header()

2015-03-06T18:30:23+00:00

Commit fab4c256a58b ("PCI/AER: Add a TLP header print helper") introduced
the helper function __print_tlp_header(), but contrary to the intention,
the behaviour did change: Since we're taking the address of the parameter
t, the first 4 or 8 bytes printed will be the value of the pointer t
itself, and the remaining 12 or 8 bytes will be who-knows-what (something
from the stack).

We want to show the values of the four members of the struct
aer_header_log_regs; that can be done without ugly and error-prone casts.
On little-endian this should produce the same output as originally
intended, and since no-one has complained about getting garbage output so
far, I think big-endian should be ok too.

Fixes: fab4c256a58b ("PCI/AER: Add a TLP header print helper")
Signed-off-by: Rasmus Villemoes 
Signed-off-by: Bjorn Helgaas 
Acked-by: Borislav Petkov 
CC: stable@vger.kernel.org	# v3.14+

PCI: spear: Drop __initdata from spear13xx_pcie_driver

2015-03-06T17:47:28+00:00

Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it
to platform_driver_register(), which can use the pointer at arbitrary times
in the future, even after the initdata is freed.  That leads to crashes.

Move spear13xx_pcie_driver and things referenced by it
(spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata.

[bhelgaas: changelog]
Fixes: 6675ef212dac ("PCI: spear: Fix Section mismatch compilation warning for probe()")
Signed-off-by: Matwey V. Kornilov 
Signed-off-by: Bjorn Helgaas 
Acked-by: Viresh Kumar 
CC: stable@vger.kernel.org	# v3.17+

PCI: xgene: Add register offset to config space base address

2015-03-06T04:14:21+00:00

In xgene_pcie_map_bus(), we neglected to add in the register offset when
calculating the config space address.  This means all config accesses
operated on the first four bytes of config space.

Add the register offset to the config space base address.

Also correct the xgene_pcie_map_bus() prototype to fix a compiler warning.

[bhelgaas: changelog]
Fixes: 350f8be5bb40 ("PCI: xgene: Convert to use generic config accessors")
Posting: http://lkml.kernel.org/r/1424214840-26498-1-git-send-email-fkan@apm.com
Signed-off-by: Feng Kan 
Signed-off-by: Bjorn Helgaas 
Acked-by: Tanmay Inamdar 
Acked-by: Rob Herring