1. 16 Jul, 2014 8 commits
    • Bjorn Helgaas's avatar
      Merge branches 'pci/host-generic', 'pci/host-mvebu', 'pci/host-rcar',... · 792688fd
      Bjorn Helgaas authored
      Merge branches 'pci/host-generic', 'pci/host-mvebu', 'pci/host-rcar', 'pci/host-tegra', 'pci/msi', 'pci/misc', 'pci/resource' and 'pci/virtualization' into next
      
      * pci/host-generic:
        PCI: generic: Fix GPL v2 license string typo
      
      * pci/host-mvebu:
        PCI: mvebu: Fix GPL v2 license string typo
      
      * pci/host-rcar:
        PCI: rcar: Fix GPL v2 license string typo
      
      * pci/host-tegra:
        PCI: tegra: Fix GPL v2 license string typo
      
      * pci/msi:
        PCI/MSI: Use irq_get_msi_desc() to simplify code
        PCI/MSI: Remove unused list access in __pci_restore_msix_state()
        PCI/MSI: Retrieve first MSI IRQ from msi_desc rather than pci_dev
        PCI/MSI: Remove unused function msi_remove_pci_irq_vectors()
        PCI/MSI: Add msi_setup_entry() to clean up MSI initialization
      
      * pci/misc:
        PCI: Configure ASPM when enabling device
        x86: don't exclude low BIOS area when allocating address space for non-PCI cards
        PCI: Add include guard to include/linux/pci_ids.h
        x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
      
      * pci/resource:
        PCI: Tidy resource assignment messages
        PCI: Return conventional error values from pci_revert_fw_address()
        PCI: Cleanup control flow
        PCI: Support BAR sizes up to 128GB
        PCI: Keep original resource if we fail to expand it
      
      * pci/virtualization:
        powerpc/pci: Remove duplicate logic
        PCI: Make resetting secondary bus logic common
      792688fd
    • Yijing Wang's avatar
      PCI/MSI: Use irq_get_msi_desc() to simplify code · e11ece5a
      Yijing Wang authored
      Use irq_get_msi_desc() to get MSI IRQ related msi_desc directly instead of
      searching the dev->msi_list.
      Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      e11ece5a
    • Yijing Wang's avatar
      PCI/MSI: Remove unused list access in __pci_restore_msix_state() · 0dae508a
      Yijing Wang authored
      In __pci_restore_msix_state(), we get the first element from msi_list, but
      we never use it.  Remove this useless code.
      Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      0dae508a
    • Yijing Wang's avatar
      PCI/MSI: Retrieve first MSI IRQ from msi_desc rather than pci_dev · a281b788
      Yijing Wang authored
      Retrieve the first MSI IRQ to compute the MSI index from struct msi_desc
      rather than the struct pci_dev to avoid an additional memory access.
      Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      a281b788
    • Yijing Wang's avatar
      PCI/MSI: Remove unused function msi_remove_pci_irq_vectors() · 4cc90161
      Yijing Wang authored
      msi_remove_pci_irq_vectors() is unused, so remove it.
      Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      4cc90161
    • Yijing Wang's avatar
      PCI/MSI: Add msi_setup_entry() to clean up MSI initialization · d873b4d4
      Yijing Wang authored
      Move MSI entry stuff to a new function, msi_setup_entry(), to simplify
      msi_capability_init() as MSI-X does.
      Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      d873b4d4
    • Vidya Sagar's avatar
      PCI: Configure ASPM when enabling device · 1f6ae47e
      Vidya Sagar authored
      We can't do ASPM configuration at enumeration-time because enabling it
      makes some defective hardware unresponsive, even if ASPM is disabled later
      (see 41cd766b ("PCI: Don't enable aspm before drivers have had a chance
      to veto it").  Therefore, we have to do it after a driver claims the
      device.
      
      We previously configured ASPM in pci_set_power_state(), but that's not a
      very good place because it's not really related to setting the PCI device
      power state, and doing it there means:
      
        - We incorrectly skipped ASPM config when setting a device that's
          already in D0 to D0.
      
        - We unnecessarily configured ASPM when setting a device to a low-power
          state (the ASPM feature only applies when the device is in D0).
      
        - We unnecessarily configured ASPM when called from a .resume() method
          (ASPM configuration needs to be restored during resume, but
          pci_restore_pcie_state() should already do this).
      
      Move ASPM configuration from pci_set_power_state() to
      do_pci_enable_device() so we do it when a driver enables a device.
      
      [bhelgaas: changelog]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79621
      Fixes: db288c9c ("PCI / PM: restore the original behavior of pci_set_power_state()")
      Suggested-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarVidya Sagar <sagar.tv@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.6+
      1f6ae47e
    • Christoph Schulz's avatar
      x86: don't exclude low BIOS area when allocating address space for non-PCI cards · cbace46a
      Christoph Schulz authored
      Commit 30919b0b ("x86: avoid low BIOS area when allocating address
      space") moved the test for resource allocations that fall within the first
      1MB of address space from the PCI-specific path to a generic path, such
      that all resource allocations will avoid this area.  However, this breaks
      ISA cards which need to allocate a memory region within the first 1MB.  An
      example is the i82365 PCMCIA controller and derivatives like the Ricoh
      RF5C296/396 which map part of the PCMCIA socket memory address space into
      the first 1MB of system memory address space.  They do not work anymore as
      no usable memory region exists due to this change:
      
        Intel ISA PCIC probe: Ricoh RF5C296/396 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
        host opts [0]: none
        host opts [1]: none
        ISA irqs (scanned) = 3,4,5,9,10 status change on irq 10
        pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1
        pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff
        pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean.
        pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0d0000-0x0dffff: clean.
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0e0000-0x0effff: clean.
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: clean.
        pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: clean.
        pcmcia_socket pcmcia_socket1: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff
        pcmcia_socket pcmcia_socket1: cs: IO port probe 0xa00-0xaff: clean.
        pcmcia_socket pcmcia_socket1: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0d0000-0x0dffff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0e0000-0x0effff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x60000000-0x60ffffff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0xa0000000-0xa0ffffff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0cc000-0x0effff: excluding 0xe0000-0xeffff
        pcmcia_socket pcmcia_socket1: cs: unable to map card memory!
      
      If filtering out the first 1MB is reverted, everything works as expected.
      Tested-by: default avatarRobert Resch <fli4l@robert.reschpara.de>
      Signed-off-by: default avatarChristoph Schulz <develop@kristov.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v2.6.37+
      cbace46a
  2. 15 Jul, 2014 4 commits
  3. 10 Jul, 2014 2 commits
  4. 09 Jul, 2014 1 commit
    • Bjorn Helgaas's avatar
      Merge branches 'pci/host-rcar', 'pci/hotplug', 'pci/iommu', 'pci/misc' and 'pci/msi' into next · 1d0df486
      Bjorn Helgaas authored
      * pci/host-rcar:
        PCI: rcar: Remove rcar_pcie_setup_window() resource argument
        PCI: rcar: Cleanup style and formatting
        PCI: rcar: Use correct initial HW settings
        PCI: rcar: Remove redundant config accessor register number checks
      
      * pci/hotplug:
        PCI: cpqphp: Remove unnecessary null test before debugfs_remove()
        PCI: pciehp: Clear Data Link Layer State Changed during init
        PCI: pciehp: Remove struct controller.no_cmd_complete
        PCI: pciehp: Remove assumptions about which commands cause completion events
        PCI: pciehp: Compute timeout from hotplug command start time
        PCI: pciehp: Wait for hotplug command completion lazily
        PCI: pciehp: Make pcie_wait_cmd() self-contained
        PCI: Prevent NULL dereference during pciehp probe
      
      * pci/iommu:
        PCI: Add bridge DMA alias quirk for Intel 82801 bridge
      
      * pci/misc:
        ACPI / PCI: Fix sysfs acpi_index and label errors
        PCI/portdrv: Remove warning about invalid IRQ for hot-added PCIe ports
      
      * pci/msi:
        PCI/MSI: Cache Multiple Message Capable in struct msi_desc
        PCI/MSI: Remove unused msi_enabled_mask()
        PCI/MSI: Add internal msix_clear_and_set_ctrl() function
      1d0df486
  5. 08 Jul, 2014 4 commits
  6. 07 Jul, 2014 2 commits
    • Fabian Frederick's avatar
      PCI: cpqphp: Remove unnecessary null test before debugfs_remove() · 5d37818b
      Fabian Frederick authored
      Fix checkpatch warning:
      "WARNING: debugfs_remove(NULL) is safe this check is probably not required"
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Ryan Desfosses <ryan@desfo.org>
      5d37818b
    • Myron Stowe's avatar
      PCI: pciehp: Clear Data Link Layer State Changed during init · 0d25d35c
      Myron Stowe authored
      During PCIe hot-plug initialization - pciehp_probe() - data structures
      related to slot capabilities are set up.  As part of this set up, ISRs are
      put in place to handle slot events and all event bits are cleared out.
      
      This patch adds the Data Link Layer State Changed (PCI_EXP_SLTSTA_DLLSC)
      Slot Status bit to the event bits that are cleared out during
      initialization.
      
      If the BIOS doesn't clear DLLSC before handoff to the OS, pciehp notices
      that it's set and interprets it as a new Link Up event, which results in
      spurious messages:
      
        pciehp 0000:82:04.0:pcie24: slot(4): Link Up event
        pciehp 0000:82:04.0:pcie24: Device 0000:83:00.0 already exists at 0000:83:00, cannot hot-add
        pciehp 0000:82:04.0:pcie24: Cannot add device at 0000:83:00
      
      Prior to e48f1b67 ("PCI: pciehp: Use link change notifications for
      hot-plug and removal"), pciehp ignored DLLSC.
      
      Reference:
        PCI-SIG.  PCI Express Base Specification Revision 4.0 Version 0.3
        (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah).
      
      [bhelgaas: add e48f1b67 ref and stable tag]
      Fixes: e48f1b67 ("PCI: pciehp: Use link change notifications for hot-plug and removal")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79611Signed-off-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.15+
      0d25d35c
  7. 05 Jul, 2014 6 commits
  8. 04 Jul, 2014 1 commit
    • Guo Chao's avatar
      PCI: Keep original resource if we fail to expand it · c3337708
      Guo Chao authored
      If we have space assigned to a resource, we try to expand the resource
      (e.g., to accommodate SR-IOV resources), and the expansion attempt fails,
      we should keep the original assignment.
      
      After bd064f0a ("PCI: Mark resources as IORESOURCE_UNSET if we can't
      assign them"), we left the resource marked IORESOURCE_UNSET when the
      expansion failed, even if it had originally been set.  That caused errors
      like this:
      
        pci 0003:00:00.0: can't enable device: BAR 15 [mem size 0x0c000000 64bit pref] not assigned
        pci 0003:00:00.0: Error enabling bridge (-22), continuing
      
      Fix this by restoring the original flags when reassignment fails.
      
      [bhelgaas: reworked to simplify, changelog]
      Fixes: bd064f0a ("PCI: Mark resources as IORESOURCE_UNSET if we can't assign them")
      Signed-off-by: default avatarGuo Chao <yan@linux.vnet.ibm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.15+
      c3337708
  9. 03 Jul, 2014 5 commits
  10. 02 Jul, 2014 2 commits
    • Simone Gotti's avatar
      ACPI / PCI: Fix sysfs acpi_index and label errors · dcfa9be8
      Simone Gotti authored
      Fix errors in handling "device label" _DSM return values.
      
      If _DSM returns a Unicode string, the ACPI type is ACPI_TYPE_BUFFER, not
      ACPI_TYPE_STRING.  Fix dsm_label_utf16s_to_utf8s() to convert UTF-16 from
      acpi_object->buffer instead of acpi_object->string.
      
      Prior to v3.14, we accepted Unicode labels (ACPI_TYPE_BUFFER return
      values).  But after 1d0fcef7, we accepted only ASCII (ACPI_TYPE_STRING)
      (and we incorrectly tried to convert those ASCII labels from UTF-16 to
      UTF-8).
      
      Rejecting Unicode labels made us return -EPERM when reading sysfs
      "acpi_index" or "label" files, which in turn caused on-board network
      interfaces on a Dell PowerEdge E420 to be renamed (by udev net_id internal)
      from eno1/eno2 to enp2s0f0/enp2s0f1.
      
      Fix this by accepting either ACPI_TYPE_STRING (and treating it as ASCII) or
      ACPI_TYPE_BUFFER (and converting from UTF-16 to UTF-8).
      
      [bhelgaas: changelog]
      Fixes: 1d0fcef7 ("ACPI / PCI: replace open-coded _DSM code with helper functions")
      Signed-off-by: default avatarSimone Gotti <simone.gotti@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      CC: stable@vger.kernel.org	# v3.14+
      dcfa9be8
    • Jiang Liu's avatar
      PCI/portdrv: Remove warning about invalid IRQ for hot-added PCIe ports · 7f105d31
      Jiang Liu authored
      For hot-added PCIe ports on x86 platforms, we always warned about an
      invalid IRQ, e.g.,
      
        pci 0000:00:00.0: device [8086:0e0b] has invalid IRQ; check vendor BIOS
      
      This was because we check pci_dev->irq before actually allocating the IRQ
      for the device, which happens in this path:
      
        pcie_port_device_register
          pci_enable_device
            pci_enable_device_flags
              do_pci_enable_device
                pcibios_enable_device    (on x86)
                  pcibios_enable_irq
      
      This warning message isn't generated for PCIe ports present at boot time
      because x86 arch code has called acpi_pci_irq_enable() in pci_acpi_init()
      for each PCI device for safety.
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      7f105d31
  11. 17 Jun, 2014 3 commits
    • Bjorn Helgaas's avatar
      PCI: pciehp: Remove assumptions about which commands cause completion events · 2cc56f30
      Bjorn Helgaas authored
      We use incorrect logic to decide whether a PCIe hotplug controller
      generates command completion events.
      
      5808639b ("pciehp: fix slow probing") assumed that the Slot Status
      "Command Completed" bit was set only for commands affecting slot power,
      indicators, or electromechanical interlock.  That assumption is false: per
      sec. 6.7.3.2 of PCIe spec r3.0, a write targeting any portion of the Slot
      Control register is a command, and (if command completed events are
      supported) software must wait for a command to complete before issuing the
      next command.
      
      5808639b was to fix boot-time timeouts (see bugzilla below) on a Lenovo
      Thinkpad R61 with an Intel hotplug controller.  The controller probably has
      the Intel CF118 erratum, which means it doesn't report Command Completed
      unless the Slot Control power, indicator, or interlock bits are changed.
      This causes a timeout because pciehp always waits for Command Complete (if
      supported), regardless of which bits are changed.
      
      Remove the incorrect logic because the timeouts have been addressed
      differently by these changes:
      
        PCI: pciehp: Wait for hotplug command completion lazily
        PCI: pciehp: Compute timeout from hotplug command start time
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=10751
      Tested-by: Rajat Jain <rajatxjain@gmail.com>	(IDT 807a controller)
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      2cc56f30
    • Bjorn Helgaas's avatar
      PCI: pciehp: Compute timeout from hotplug command start time · 40b96083
      Bjorn Helgaas authored
      If we issue a hotplug command, go do something else, then come back and
      wait for the command to complete, we don't have to wait the whole timeout
      period, because some of it elapsed while we were doing something else.
      
      Keep track of the time we issued the command, and wait only until the
      timeout period from that point has elapsed.
      
      For controllers with errata like Intel CF118, we previously timed out
      before issuing the second hotplug command:
      
        At time T1 (during boot):
          - Write DLLSCE, ABPE, PDCE, etc. to Slot Control
        At time T2 (hotplug event):
          - Wait for command completion (CC) in Slot Status
          - Timeout at T2 + 1 second because CC is never set in Slot Status
          - Write PCC, PIC, etc. to Slot Control
      
      With this change, we wait until T1 + 1 second instead of T2 + 1 second.
      If the hotplug event is more than 1 second after the boot-time
      initialization, we won't wait for the timeout at all.
      
      We still emit a "Timeout on hotplug command" message if it timed out; we
      should see this on the first hotplug event on every controller with this
      erratum, as well as on real errors on controllers without the erratum.
      
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html
      Tested-by: Rajat Jain <rajatxjain@gmail.com>	(IDT 807a controller)
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      40b96083
    • Bjorn Helgaas's avatar
      PCI: pciehp: Wait for hotplug command completion lazily · 3461a068
      Bjorn Helgaas authored
      Previously we issued a hotplug command and waited for it to complete.  But
      there's no need to wait until we're ready to issue the *next* command.  The
      next command will probably be much later, so the first one may have already
      completed and we may not have to actually wait at all.
      
      Because of hardware errata, some controllers generate command completion
      events for some commands but not others.  In the case of Intel CF118 (see
      spec update reference), the controller indicates command completion only
      for Slot Control writes that change the value of the following bits:
      
        Power Controller Control
        Power Indicator Control
        Attention Indicator Control
        Electromechanical Interlock Control
      
      Changes to other bits, e.g., the interrupt enable bits, do not cause the
      Command Completed bit to be set.  Controllers from AMD and Nvidia are
      reported to have similar errata.
      
      These errata cause timeouts when pcie_enable_notification() enables
      interrupts.  Previously that timeout occurred at boot-time.  With this
      change, the timeout occurs later, when we change the state of the slot
      power, indicators, or interlock.  This speeds up boot but causes a timeout
      at the first hotplug event on the slot.  Subsequent events don't timeout
      because only the first (boot-time) hotplug command updates Slot Control
      without touching the power/indicator/interlock controls.
      
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html
      Tested-by: Rajat Jain <rajatxjain@gmail.com>	(IDT 807a controller)
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      3461a068
  12. 16 Jun, 2014 2 commits