1. 03 Oct, 2016 7 commits
    • Bjorn Helgaas's avatar
      Merge branch 'pci/resource' into next · e15194d2
      Bjorn Helgaas authored
      * pci/resource:
        PCI: Ignore requested alignment for VF BARs
        PCI: Ignore requested alignment for PROBE_ONLY and fixed resources
      e15194d2
    • Bjorn Helgaas's avatar
      Merge branch 'pci/pm' into next · 3f4f3567
      Bjorn Helgaas authored
      * pci/pm:
        PCI: Avoid unnecessary resume after direct-complete
        PCI: Recognize D3cold in pci_update_current_state()
        PCI: Query platform firmware for device power state
        PCI: Afford direct-complete to devices with non-standard PM
      3f4f3567
    • Bjorn Helgaas's avatar
      Merge branch 'pci/msi' into next · 6c6cba49
      Bjorn Helgaas authored
      * pci/msi:
        PCI/MSI: Enable PCI_MSI_IRQ_DOMAIN support for ARC
      6c6cba49
    • Bjorn Helgaas's avatar
      Merge branch 'pci/misc' into next · 5485e49f
      Bjorn Helgaas authored
      * pci/misc:
        PCI: Drop CONFIG_KEXEC_CORE ifdeffery
      5485e49f
    • Bjorn Helgaas's avatar
      Merge branch 'pci/hotplug' into next · 64ea3b99
      Bjorn Helgaas authored
      * pci/hotplug:
        x86/PCI: VMD: Request userspace control of PCIe hotplug indicators
        PCI: pciehp: Allow exclusive userspace control of indicators
        PCI: pciehp: Remove useless pciehp_get_latch_status() calls
        PCI: pciehp: Clean up dmesg "Slot(%s)" messages
        PCI: pciehp: Remove unnecessary guard
        PCI: pciehp: Don't re-read Slot Status when handling surprise event
        PCI: pciehp: Don't re-read Slot Status when queuing hotplug event
        PCI: pciehp: Process all hotplug events before looking for new ones
        PCI: pciehp: Return IRQ_NONE when we can't read interrupt status
        PCI: pciehp: Rename pcie_isr() locals for clarity
        PCI: pciehp: Clear attention LED on device add
      64ea3b99
    • Bjorn Helgaas's avatar
      Merge branch 'pci/enumeration' into next · fb6b6cc4
      Bjorn Helgaas authored
      * pci/enumeration:
        PCI: tegra: Fix pci_remap_iospace() failure path
        PCI: generic: Fix pci_remap_iospace() failure path
        PCI: rcar: Fix pci_remap_iospace() failure path
        PCI: versatile: Fix pci_remap_iospace() failure path
        PCI: designware: Fix pci_remap_iospace() failure path
        PCI: aardvark: Fix pci_remap_iospace() failure path
      fb6b6cc4
    • Bjorn Helgaas's avatar
      Merge branch 'pci/aer' into next · 4dc2db09
      Bjorn Helgaas authored
      * pci/aer:
        PCI/AER: Fix aer_probe() kernel-doc comment
        PCI/AER: Cache capability position
        PCI/AER: Avoid memory allocation in interrupt handling path
        ACPI / APEI: Send correct severity to calculate AER severity
        PCI/AER: Remove duplicate AER severity translation
        PCI/AER: Remove aerdriver.forceload kernel parameter
        PCI/AER: Remove aerdriver.nosourceid kernel parameter
        x86/PCI: VMD: Add quirk for AER to ignore source ID
        PCI/AER: Add bus flag to skip source ID matching
      
      Conflicts:
      	drivers/pci/probe.c
      4dc2db09
  2. 30 Sep, 2016 1 commit
  3. 28 Sep, 2016 6 commits
    • Yongji Xie's avatar
      PCI: Ignore requested alignment for VF BARs · 62d9a78f
      Yongji Xie authored
      Resource allocation for VFs is done via the VF BARx registers in the PF's
      SR-IOV Capability, and the BARs in the VFs themselves are read-only zeros
      (see SR-IOV spec r1.1, secs 3.3.14 and 3.4.1.11).
      
      Even though the actual VF BARs are read-only zeros, the VF dev->resource[]
      structs describe the space allocated for the VF (this is a piece of the
      space described by the VF BARx register in the PF's SR-IOV capability).
      
      It's meaningless to request additional alignment for a VF: the VF BAR
      alignment is completely determined by the alignment of the VF BARx in the
      PF and the size of the VF BAR.
      
      Ignore the user's alignment requests for VF devices.
      Signed-off-by: default avatarYongji Xie <xyjxie@linux.vnet.ibm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      62d9a78f
    • Yongji Xie's avatar
      PCI: Ignore requested alignment for PROBE_ONLY and fixed resources · f0b99f70
      Yongji Xie authored
      Users may request additional alignment of PCI resources, e.g., to align
      BARs on page boundaries so they can be shared with guests via VFIO.  This
      of course may require reallocation if firmware has already assigned the
      BARs with smaller alignments.
      
      If the platform has requested PCI_PROBE_ONLY, we should never change any
      PCI BARs, so we can't provide any additional alignment.  Also, if a BAR is
      marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the
      firmware depends on the current BAR value, we can't change the alignment.
      
      In these cases, log a message and ignore the user's alignment requests.
      
      [bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check]
      Signed-off-by: default avatarYongji Xie <xyjxie@linux.vnet.ibm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      f0b99f70
    • Lukas Wunner's avatar
      PCI: Avoid unnecessary resume after direct-complete · a0d2a959
      Lukas Wunner authored
      Commit 58a1fbbb ("PM / PCI / ACPI: Kick devices that might have been
      reset by firmware") added a runtime resume for devices that were runtime
      suspended when the system entered sleep.
      
      The motivation was that devices might be in a reset-power-on state after
      waking from system sleep, so their power state as perceived by Linux
      (stored in pci_dev->current_state) would no longer reflect reality.  By
      resuming such devices, we allow them to return to a low-power state via
      autosuspend and also bring their current_state in sync with reality.
      
      However for devices that are *not* in a reset-power-on state, doing an
      unconditional resume wastes energy.  A more refined approach is called for
      which issues a runtime resume only if the power state after direct-complete
      is shallower than it was before. To achieve this, update the device's
      current_state and compare it to its pre-sleep value.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a0d2a959
    • Lukas Wunner's avatar
      PCI: Recognize D3cold in pci_update_current_state() · a6a64026
      Lukas Wunner authored
      Whenever a device is resumed or its power state is changed using the
      platform, its new power state is read from the PM Control & Status Register
      and cached in pci_dev->current_state by calling pci_update_current_state().
      
      If the device is in D3cold, reading from config space typically results in
      a fabricated "all ones" response.  But if it's in D3hot, the two bits
      representing the power state in the PMCSR are *also* set to 1.  Thus D3hot
      and D3cold are not discernible by just reading the PMCSR.
      
      To account for this, pci_update_current_state() uses two workarounds:
      
      - When transitioning to D3cold using pci_platform_power_transition(), the
        new power state is set blindly by pci_update_current_state(), i.e.
        without verifying that the device actually *is* in D3cold.  This is
        achieved by setting the "state" argument to PCI_D3cold.  The "state"
        argument was originally intended to convey the new state in case the
        device doesn't have the PM capability.  It is *also* used to convey the
        device state if the PM capability is present and the new state is D3cold,
        but this was never explained in the kerneldoc.
      
      - Once the current_state is set to D3cold, further invocations of
        pci_update_current_state() will blindly assume that the device is still
        in D3cold and leave the current_state unmodified.  To get out of this
        impasse, the current_state has to be set directly, typically by calling
        pci_raw_set_power_state() or pci_enable_device().
      
      It would be desirable if pci_update_current_state() could reliably detect
      D3cold by itself.  That would allow us to do away with these workarounds,
      and it would allow for a smarter, more energy conserving runtime resume
      strategy after system sleep:  Currently devices which utilize
      direct_complete are mandatorily runtime resumed in their ->complete stage.
      This can be avoided if their power state after system sleep is the same as
      before, but it requires a mechanism to detect the power state reliably.
      
      We've just gained the ability to query the platform firmware for its
      opinion on the device's power state.  On platforms conforming to ACPI 4.0
      or newer, this allows recognition of D3cold.  Pre-4.0 platforms lack _PR3
      and therefore the deepest power state that will ever be reported is D3hot,
      even though the device may actually be in D3cold.  To detect D3cold in
      those cases, accessibility of the vendor ID in config space is probed using
      pci_device_is_present().  This also works for devices which are not
      platform-power-manageable at all, but can be suspended to D3cold using a
      nonstandard mechanism (e.g. some hybrid graphics laptops or Thunderbolt on
      the Mac).
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a6a64026
    • Lukas Wunner's avatar
      PCI: Query platform firmware for device power state · cc7cc02b
      Lukas Wunner authored
      Usually the most accurate way to determine a PCI device's power state is to
      read its PM Control & Status Register.  There are two cases however when
      this is not an option:  If the device doesn't have the PM capability at
      all, or if it is in D3cold (in which case its config space is
      inaccessible).
      
      In both cases, we can alternatively query the platform firmware for its
      opinion on the device's power state.  To facilitate this, augment struct
      pci_platform_pm_ops with a ->get_power callback and implement it for
      acpi_pci_platform_pm (the only pci_platform_pm_ops existing so far).
      
      It is used by a forthcoming commit to let pci_update_current_state()
      recognize D3cold.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cc7cc02b
    • Lukas Wunner's avatar
      PCI: Afford direct-complete to devices with non-standard PM · 4132a577
      Lukas Wunner authored
      There are devices not power-manageable by the platform, but still able to
      runtime suspend to D3cold with a non-standard mechanism.  One example is
      laptop hybrid graphics where the discrete GPU and its built-in HDA
      controller are power-managed either with a _DSM (AMD PowerXpress, Nvidia
      Optimus) or a separate gmux controller (MacBook Pro).  Another example is
      Thunderbolt on Macs which is power-managed with custom ACPI methods.
      
      When putting the system to sleep, we currently handle such devices
      improperly by transitioning them from D3cold to D3hot (the default power
      state defined at the top of pci_target_state()).  This wastes energy and
      prolongs the suspend sequence (powering up the Thunderbolt controller takes
      2 seconds).
      
      Avoid that by assuming that a non-standard PM mechanism is at work if the
      device is not platform-power-manageable but currently in D3cold.
      
      If the device is wakeup enabled, we might still have to wake it up from
      D3cold if PME cannot be signaled from that power state.
      
      The check for devices without PM capability comes before the check for
      D3cold since such devices could in theory also be powered down by
      non-standard means and should then be afforded direct-complete as well.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4132a577
  4. 27 Sep, 2016 2 commits
  5. 23 Sep, 2016 1 commit
  6. 22 Sep, 2016 1 commit
    • Keith Busch's avatar
      PCI: pciehp: Allow exclusive userspace control of indicators · 576243b3
      Keith Busch authored
      PCIe hotplug supports optional Attention and Power Indicators, which are
      used internally by pciehp.  Users can't control the Power Indicator, but
      they can control the Attention Indicator by writing to a sysfs "attention"
      file.
      
      The Slot Control register has two bits for each indicator, and the PCIe
      spec defines the encodings for each as (Reserved/On/Blinking/Off).  For
      sysfs "attention" writes, pciehp_set_attention_status() maps into these
      encodings, so the only useful write values are 0 (Off), 1 (On), and 2
      (Blinking).
      
      However, some platforms use all four bits for platform-specific indicators,
      and they need to allow direct user control of them while preventing pciehp
      from using them at all.
      
      Add a "hotplug_user_indicators" flag to the pci_dev structure.  When set,
      pciehp does not use either the Attention Indicator or the Power Indicator,
      and the low four bits (values 0x0 - 0xf) of sysfs "attention" write values
      are written directly to the Attention Indicator Control and Power Indicator
      Control fields.
      
      [bhelgaas: changelog, rename flag and accessors to s/attention/indicator/]
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      576243b3
  7. 20 Sep, 2016 2 commits
  8. 14 Sep, 2016 9 commits
  9. 12 Sep, 2016 1 commit
  10. 06 Sep, 2016 9 commits
    • Jon Derrick's avatar
      x86/PCI: VMD: Add quirk for AER to ignore source ID · 443b40ba
      Jon Derrick authored
      VMD root ports change all source ids to the VMD device ID.  To find the
      sender of the AER notification, we need to scan all child devices for the
      AER sender, rather than relying on the source ID from the message.
      Signed-off-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      443b40ba
    • Jon Derrick's avatar
      PCI/AER: Add bus flag to skip source ID matching · 032c3d86
      Jon Derrick authored
      Allow root port buses to choose to skip source id matching when finding the
      faulting device.  Certain root port devices may return an incorrect source
      ID and recommend to scan child device registers for AER notifications.
      Signed-off-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      032c3d86
    • Lorenzo Pieralisi's avatar
      PCI: tegra: Fix pci_remap_iospace() failure path · 13f392eb
      Lorenzo Pieralisi authored
      On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
      IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
      and by mapping the PCI host bridges memory address space driving PCI IO
      cycles to it.
      
      PCI host bridge drivers that enable downstream PCI IO cycles map the host
      bridge memory address responding to PCI IO cycles to the fixed virtual
      address space through the pci_remap_iospace() API.
      
      This means that if the pci_remap_iospace() function fails, the
      corresponding host bridge PCI IO resource must be considered invalid, in
      that there is no way for the kernel to actually drive PCI IO transactions
      if the memory addresses responding to PCI IO cycles cannot be mapped into
      the CPU virtual address space.
      
      The PCI tegra host bridge driver adds the PCI IO resource retrieved from
      firmware to the host bridge resource windows even if the
      pci_remap_iospace() call fails; this is an actual bug in that the PCI host
      bridge would consider the PCI IO resource valid (and possibly assign it to
      downstream devices) even if the kernel was not able to map the PCI host
      bridge memory address driving IO cycle to the CPU virtual address space (ie
      pci_remap_iospace() failures).
      
      Add the PCI host bridge driver pci_remap_iospace() failure path and do not
      add the corresponding PCI host bridge PCI IO resources retrieved through
      firmware when the pci_remap_iospace() function call fails, fixing the
      issue.
      
      Fixes: e6e9f471 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Thierry Reding <treding@nvidia.com>
      13f392eb
    • Lorenzo Pieralisi's avatar
      PCI: generic: Fix pci_remap_iospace() failure path · 43281ede
      Lorenzo Pieralisi authored
      On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
      IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
      and by mapping the PCI host bridges memory address space driving PCI IO
      cycles to it.
      
      PCI host bridge drivers that enable downstream PCI IO cycles map the host
      bridge memory address responding to PCI IO cycles to the fixed virtual
      address space through the pci_remap_iospace() API.
      
      This means that if the pci_remap_iospace() function fails, the
      corresponding host bridge PCI IO resource must be considered invalid, in
      that there is no way for the kernel to actually drive PCI IO transactions
      if the memory addresses responding to PCI IO cycles cannot be mapped into
      the CPU virtual address space.
      
      The PCI common host bridge driver does not remove the PCI IO resource from
      the host bridge resource windows if the pci_remap_iospace() call fails;
      this is an actual bug in that the PCI host bridge would consider the PCI IO
      resource valid (and possibly assign it to downstream devices) even if the
      kernel was not able to map the PCI host bridge memory address driving IO
      cycle to the CPU virtual address space (ie pci_remap_iospace() failures).
      
      Fix the PCI host bridge driver pci_remap_iospace() failure path, by
      destroying the PCI host bridge PCI IO resources retrieved through firmware
      when the pci_remap_iospace() function call fails, therefore preventing the
      kernel from adding the respective PCI IO resource to the list of PCI host
      bridge valid resources, fixing the issue.
      
      Fixes: 4e64dbe2 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      43281ede
    • Lorenzo Pieralisi's avatar
      PCI: rcar: Fix pci_remap_iospace() failure path · 5e8c8732
      Lorenzo Pieralisi authored
      On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
      IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
      and by mapping the PCI host bridges memory address space driving PCI IO
      cycles to it.
      
      PCI host bridge drivers that enable downstream PCI IO cycles map the host
      bridge memory address responding to PCI IO cycles to the fixed virtual
      address space through the pci_remap_iospace() API.
      
      This means that if the pci_remap_iospace() function fails, the
      corresponding host bridge PCI IO resource must be considered invalid, in
      that there is no way for the kernel to actually drive PCI IO transactions
      if the memory addresses responding to PCI IO cycles cannot be mapped into
      the CPU virtual address space.
      
      The PCI rcar host bridge driver does not remove the PCI IO resource from
      the host bridge resource windows if the pci_remap_iospace() call fails;
      this is an actual bug in that the PCI host bridge would consider the PCI IO
      resource valid (and possibly assign it to downstream devices) even if the
      kernel was not able to map the PCI host bridge memory address driving IO
      cycle to the CPU virtual address space (ie pci_remap_iospace() failures).
      
      Fix the PCI host bridge driver pci_remap_iospace() failure path, by
      destroying the PCI host bridge PCI IO resources retrieved through firmware
      when the pci_remap_iospace() function call fails, therefore preventing the
      kernel from adding the respective PCI IO resource to the list of PCI host
      bridge valid resources, fixing the issue.
      
      Fixes: 5d2917d4 ("PCI: rcar: Convert to DT resource parsing API")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Phil Edworthy <phil.edworthy@renesas.com>
      CC: Simon Horman <horms+renesas@verge.net.au>
      5e8c8732
    • Lorenzo Pieralisi's avatar
      PCI: versatile: Fix pci_remap_iospace() failure path · 53f4f7ee
      Lorenzo Pieralisi authored
      On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
      IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
      and by mapping the PCI host bridges memory address space driving PCI IO
      cycles to it.
      
      PCI host bridge drivers that enable downstream PCI IO cycles map the host
      bridge memory address responding to PCI IO cycles to the fixed virtual
      address space through the pci_remap_iospace() API.
      
      This means that if the pci_remap_iospace() function fails, the
      corresponding host bridge PCI IO resource must be considered invalid, in
      that there is no way for the kernel to actually drive PCI IO transactions
      if the memory addresses responding to PCI IO cycles cannot be mapped into
      the CPU virtual address space.
      
      The PCI versatile host bridge driver does not remove the PCI IO resource
      from the host bridge resource windows if the pci_remap_iospace() call
      fails; this is an actual bug in that the PCI host bridge would consider the
      PCI IO resource valid (and possibly assign it to downstream devices) even
      if the kernel was not able to map the PCI host bridge memory address
      driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
      failures).
      
      Fix the PCI host bridge driver pci_remap_iospace() failure path, by
      destroying the PCI host bridge PCI IO resources retrieved through firmware
      when the pci_remap_iospace() function call fails, therefore preventing the
      kernel from adding the respective PCI IO resource to the list of PCI host
      bridge valid resources, fixing the issue.
      
      Fixes: b7e78170 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Rob Herring <robh@kernel.org>
      53f4f7ee
    • Lorenzo Pieralisi's avatar
      PCI: designware: Fix pci_remap_iospace() failure path · bcd7b718
      Lorenzo Pieralisi authored
      On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
      IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
      and by mapping the PCI host bridges memory address space driving PCI IO
      cycles to it.
      
      PCI host bridge drivers that enable downstream PCI IO cycles map the host
      bridge memory address responding to PCI IO cycles to the fixed virtual
      address space through the pci_remap_iospace() API.
      
      This means that if the pci_remap_iospace() function fails, the
      corresponding host bridge PCI IO resource must be considered invalid, in
      that there is no way for the kernel to actually drive PCI IO transactions
      if the memory addresses responding to PCI IO cycles cannot be mapped into
      the CPU virtual address space.
      
      The PCI designware host bridge driver does not remove the PCI IO resource
      from the host bridge resource windows if the pci_remap_iospace() call
      fails; this is an actual bug in that the PCI host bridge would consider the
      PCI IO resource valid (and possibly assign it to downstream devices) even
      if the kernel was not able to map the PCI host bridge memory address
      driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
      failures).
      
      Fix the PCI host bridge driver pci_remap_iospace() failure path, by
      destroying the PCI host bridge PCI IO resources retrieved through firmware
      when the pci_remap_iospace() function call fails, therefore preventing the
      kernel from adding the respective PCI IO resource to the list of PCI host
      bridge valid resources, fixing the issue.
      
      Fixes: cbce7900 ("PCI: designware: Make driver arch-agnostic")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Jingoo Han <jingoohan1@gmail.com>
      CC: Pratyush Anand <pratyush.anand@gmail.com>
      bcd7b718
    • Lorenzo Pieralisi's avatar
      PCI: aardvark: Fix pci_remap_iospace() failure path · db047f8a
      Lorenzo Pieralisi authored
      On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
      IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
      and by mapping the PCI host bridge's memory address space driving PCI IO
      cycles to it.
      
      PCI host bridge drivers that enable downstream PCI IO cycles map the host
      bridge memory address responding to PCI IO cycles to the fixed virtual
      address space through the pci_remap_iospace() API.
      
      This means that if the pci_remap_iospace() function fails, the
      corresponding host bridge PCI IO resource must be considered invalid, in
      that there is no way for the kernel to actually drive PCI IO transactions
      if the memory addresses responding to PCI IO cycles cannot be mapped into
      the CPU virtual address space.
      
      The PCI aardvark host bridge driver does not remove the PCI IO resource
      from the host bridge resource windows if the pci_remap_iospace() call
      fails; this is an actual bug in that the PCI host bridge would consider the
      PCI IO resource valid (and possibly assign it to downstream devices) even
      if the kernel was not able to map the PCI host bridge memory address
      driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
      failures).
      
      Fix the PCI host bridge driver pci_remap_iospace() failure path, by
      destroying the PCI host bridge PCI IO resources retrieved through firmware
      when the pci_remap_iospace() function call fails, therefore preventing the
      kernel from adding the respective PCI IO resource to the list of PCI host
      bridge valid resources, fixing the issue.
      
      Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller driver")
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      db047f8a
    • Joao Pinto's avatar
      PCI/MSI: Enable PCI_MSI_IRQ_DOMAIN support for ARC · f8430eae
      Joao Pinto authored
      Add ARC as an arch that supports PCI_MSI_IRQ_DOMAIN and add generation of
      msi.h in the ARC arch.
      Signed-off-by: default avatarJoao Pinto <jpinto@synopsys.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      f8430eae
  11. 01 Sep, 2016 1 commit
    • Bjorn Helgaas's avatar
      Merge branch 'pci/ptm' into next · 9e18ad98
      Bjorn Helgaas authored
      * pci/ptm:
        PCI: Add PTM clock granularity information
        PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints
        PCI: Add Precision Time Measurement (PTM) support
      9e18ad98