linux-toradex.git/drivers/pci, branch v3.17.2

PCI: Generate uppercase hex for modalias interface class

2014-10-30T16:43:13+00:00

commit 89ec3dcf17fd3fa009ecf8faaba36828dd6bc416 upstream.

Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.

The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D.  Most interface types defined in the spec do not use
alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
20h, etc. are unaffected.

Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.

[bhelgaas: changelog]
Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Bjorn Helgaas 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size

2014-10-30T16:43:13+00:00

commit 9fe373f9997b48fcd6222b95baf4a20c134b587a upstream.

The Crocodile chip occasionally comes up with 4k and 8k BAR sizes.  Due to
an erratum, setting the SR-IOV page size causes the physical function BARs
to expand to the system page size.  Since ppc64 uses 64k pages, when Linux
tries to assign the smaller resource sizes to the now 64k BARs the address
will be truncated and the BARs will overlap.

Force Linux to allocate the resource as a full page, which avoids the
overlap.

[bhelgaas: print expanded resource, too]
Signed-off-by: Douglas Lehr 
Signed-off-by: Anton Blanchard 
Signed-off-by: Bjorn Helgaas 
Acked-by: Milton Miller 
Signed-off-by: Greg Kroah-Hartman

PCI: Add missing MEM_64 mask in pci_assign_unassigned_bridge_resources()

2014-10-30T16:43:13+00:00

commit d61b0e87d2dfba3706dbbd6c7c6fd41c3d845685 upstream.

In 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources"), we added IORESOURCE_MEM_64 to the mask in
pci_assign_unassigned_root_bus_resources(), but not to the mask in
pci_assign_unassigned_bridge_resources().

Add IORESOURCE_MEM_64 to the pci_assign_unassigned_bridge_resources() type
mask.

Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: mvebu: Fix uninitialized variable in mvebu_get_tgt_attr()

2014-10-30T16:43:13+00:00

commit 56fab6e189441d714a2bfc8a64f3df9c0749dff7 upstream.

Geert Uytterhoeven reported a warning when building pci-mvebu:

  drivers/pci/host/pci-mvebu.c: In function 'mvebu_get_tgt_attr':
  drivers/pci/host/pci-mvebu.c:887:39: warning: 'rtype' may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (slot == PCI_SLOT(devfn) && type == rtype) {
					 ^

And indeed, the code of mvebu_get_tgt_attr() may lead to the usage of rtype
when being uninitialized, even though it would only happen if we had
entries other than I/O space and 32 bits memory space.

This commit fixes that by simply skipping the current DT range being
considered, if it doesn't match the resource type we're looking for.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Fix wait time in timeout message

2014-10-15T10:29:23+00:00

commit d433889cd5a0933fbd90f1e65bff5a8d7963cc52 upstream.

When we warned about a timeout on a hotplug command, we previously printed
the time between calls to pcie_write_cmd(), without accounting for any time
spent actually waiting.  Consider this sequence:

  pcie_write_cmd
    write SLTCTL
    cmd_started = jiffies          # T1

  pcie_write_cmd
    pcie_wait_cmd
      now = jiffies                # T2
      wait_event_timeout           # we may wait here
      if (timeout)
        ctrl_info("Timeout on command issued %u msec ago",
                  jiffies_to_msecs(now - cmd_started))

We previously printed (T2 - T1), but that doesn't include the time spent in
wait_event_timeout().

Fix this by using the current jiffies value, not the one cached before
calling wait_event_timeout().

[bhelgaas: changelog, use current jiffies instead of adding timeout]
Fixes: 40b960831cfa ("PCI: pciehp: Compute timeout from hotplug command start time")
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

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

2014-09-24T16:46:29+00:00

Pull PCI fixes from Bjorn Helgaas:
 "Here are a few fixes that should be in v3.17.

   - Reverting "Don't scan random busses" covers up a CardBus regression
     having to do with allocating CardBus bus numbers.

   - Reverting "Make sure bus numbers stay within parents bounds" covers
     up an ACPI _CRS bug that makes us reconfigure a bridge, causing a
     broken device behind it to stop responding.

   - The pciehp timeout change fixes some code we added in v3.17.
     Without the fix, we can send a new hotplug command too early,
     before the timeout has expired.

  I hope for better fixes for the reverts, but those will have to come
  after v3.17"

* tag 'pci-v3.17-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: pciehp: Fix pcie_wait_cmd() timeout
  Revert "PCI: Make sure bus number resources stay within their parents bounds"
  Revert "PCI: Don't scan random busses in pci_scan_bridge()"

PCI: pciehp: Fix pcie_wait_cmd() timeout

2014-09-23T02:05:45+00:00

pcie_poll_cmd() take msecs instead of jiffies, so convert timeout to msecs.

Fixes: 40b960831cfa ("PCI: pciehp: Compute timeout from hotplug command start time")
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas

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

2014-09-19T17:50:30+00:00

Pull PCI fixes from Bjorn Helgaas:
 "These fix:

   - Boot video device detection on dual-GPU Apple systems
   - Hotplug fiascos on VGA switcheroo with radeon & nouveau drivers
   - Boot hang on Freescale i.MX6 systems
   - Excessive "no hotplug settings from platform" warnings

  In particular:

  Enumeration
    - Don't default exclusively to first video device (Bruno Prémont)

  PCI device hotplug
    - Remove "no hotplug settings from platform" warning (Bjorn Helgaas)
    - Add pci_ignore_hotplug() for VGA switcheroo (Bjorn Helgaas)

  Freescale i.MX6
    - Put LTSSM in "Detect" state before disabling (Lucas Stach)"

* tag 'pci-v3.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  vgaarb: Drop obsolete #ifndef
  vgaarb: Don't default exclusively to first video device with mem+io
  ACPIPHP / radeon / nouveau: Remove acpi_bus_no_hotplug()
  PCI: Remove "no hotplug settings from platform" warning
  PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device
  PCI: imx6: Put LTSSM in "Detect" state before disabling it
  MAINTAINERS: Add Lucas Stach as co-maintainer for i.MX6 PCI driver

Revert "PCI: Make sure bus number resources stay within their parents bounds"

2014-09-19T17:08:40+00:00

This reverts commit 1820ffdccb9b ("PCI: Make sure bus number resources stay
within their parents bounds") because it breaks some systems with LSI Logic
FC949ES Fibre Channel Adapters, apparently by exposing a defect in those
adapters.

Dirk tested a Tyan VX50 (B4985) with this device that worked like this
prior to 1820ffdccb9b:

    bus: [bus 00-7f] on node 0 link 1
    ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-07])
    pci 0000:00:0e.0: PCI bridge to [bus 0a]
    pci_bus 0000:0a: busn_res: can not insert [bus 0a] under [bus 00-07] (conflicts with (null) [bus 00-07])
    pci 0000:0a:00.0: [1000:0646] type 00 class 0x0c0400 (FC adapter)

Note that the root bridge [bus 00-07] aperture is wrong; this is a BIOS
defect in the PCI0 _CRS method.  But prior to 1820ffdccb9b, we didn't
enforce that aperture, and the FC adapter worked fine at 0a:00.0.

After 1820ffdccb9b, we notice that 00:0e.0's aperture is not contained in
the root bridge's aperture, so we reconfigure it so it *is* contained:

    pci 0000:00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring
    pci 0000:00:0e.0: PCI bridge to [bus 06-07]

This effectively moves the FC device from 0a:00.0 to 07:00.0, which should
be legal.  But when we enumerate bus 06, the FC device doesn't respond, so
we don't find anything.  This is probably a defect in the FC device.

Possible fixes (due to Yinghai):

    1) Add a quirk to fix the _CRS information based on what amd_bus.c read
       from the hardware

    2) Reset the FC device after we change its bus number

    3) Revert 1820ffdccb9b

Fix 1 would be relatively easy, but it does sweep the LSI FC issue under
the rug.  We might want to reconfigure bus numbers in the future for some
other reason, e.g., hotplug, and then we could trip over this again.

For that reason, I like fix 2, but we don't know whether it actually works,
and we don't have a patch for it yet.

This revert is fix 3, which also sweeps the LSI FC issue under the rug.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84281
Reported-by: Dirk Gouders 
Tested-by: Dirk Gouders 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v3.15+
CC: Yinghai Lu

Revert "PCI: Don't scan random busses in pci_scan_bridge()"

2014-09-19T16:56:06+00:00

This reverts commit fc1b253141b3 ("PCI: Don't scan random busses in
pci_scan_bridge()") because it breaks CardBus on some machines.

David tested a Dell Latitude D505 that worked like this prior to
fc1b253141b3:

    pci 0000:00:1e.0: PCI bridge to [bus 01]
    pci 0000:01:01.0: CardBus bridge to [bus 02-05]

Note that the 01:01.0 CardBus bridge has a bus number aperture of
[bus 02-05], but those buses are all outside the 00:1e.0 PCI bridge bus
number aperture, so accesses to buses 02-05 never reach CardBus.  This is
later patched up by yenta_fixup_parent_bridge(), which changes the
subordinate bus number of the 00:1e.0 PCI bridge:

    pci_bus 0000:01: Raising subordinate bus# of parent bus (#01) from #01 to #05

With fc1b253141b3, pci_scan_bridge() fails immediately when it notices that
we can't allocate a valid secondary bus number for the CardBus bridge, and
CardBus doesn't work at all:

    pci 0000:01:01.0: can't allocate child bus 01 from [bus 01]

I'd prefer to fix this by integrating the yenta_fixup_parent_bridge() logic
into pci_scan_bridge() so we fix the bus number apertures up front.  But
I don't think we can do that before v3.17, so I'm going to revert this to
avoid the problem while we're working on the long-term fix.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=83441
Link: http://lkml.kernel.org/r/1409303414-5196-1-git-send-email-david.henningsson@canonical.com
Reported-by: David Henningsson 
Tested-by: David Henningsson 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v3.15+