1. 08 12月, 2016 1 次提交
    • A
      PCI: Add pci_register_host_bridge() interface · 37d6a0a6
      Arnd Bergmann 提交于
      Make the existing pci_host_bridge structure a proper device that is usable
      by PCI host drivers in a more standard way. In addition to the existing
      pci_scan_bus(), pci_scan_root_bus(), pci_scan_root_bus_msi(), and
      pci_create_root_bus() interfaces, this unfortunately means having to add
      yet another interface doing basically the same thing, and add some extra
      code in the initial step.
      
      However, this time it's more likely to be extensible enough that we won't
      have to do another one again in the future, and we should be able to reduce
      code much more as a result.
      
      The main idea is to pull the allocation of 'struct pci_host_bridge' out of
      the registration, and let individual host drivers and architecture code
      fill the members before calling the registration function.
      
      There are a number of things we can do based on this:
      
      * Use a single memory allocation for the driver-specific structure
        and the generic PCI host bridge
      * consolidate the contents of driver-specific structures by moving
        them into pci_host_bridge
      * Add a consistent interface for removing a PCI host bridge again
        when unloading a host driver module
      * Replace the architecture specific __weak pcibios_*() functions with
        callbacks in a pci_host_bridge device
      * Move common boilerplate code from host drivers into the generic
        function, based on contents of the structure
      * Extend pci_host_bridge with additional members when needed without
        having to add arguments to pci_scan_*().
      * Move members of struct pci_bus into pci_host_bridge to avoid
        having lots of identical copies.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
      37d6a0a6
  2. 28 9月, 2016 1 次提交
  3. 23 9月, 2016 1 次提交
    • K
      PCI: pciehp: Allow exclusive userspace control of indicators · 576243b3
      Keith Busch 提交于
      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: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      576243b3
  4. 17 9月, 2016 1 次提交
  5. 15 9月, 2016 1 次提交
  6. 07 9月, 2016 1 次提交
  7. 02 9月, 2016 1 次提交
  8. 25 8月, 2016 1 次提交
    • B
      PCI: Add PTM clock granularity information · 8b2ec318
      Bjorn Helgaas 提交于
      The PTM Control register (PCIe r3.1, sec 7.32.3) contains an Effective
      Granularity field:
      
        This provides information relating to the expected accuracy of the PTM
        clock, but does not otherwise affect the PTM mechanism.
      
      Set the Effective Granularity based on the PTM Root and any intervening PTM
      Time Sources.
      
      This does not set Effective Granularity for Root Complex Integrated
      Endpoints because I don't know how to figure out clock granularity for
      them.  The spec says:
      
        ... system software must set [Effective Granularity] to the value
        reported in the Local Clock Granularity field by the associated PTM
        Time Source.
      
      but I don't know how to identify the associated PTM Time Source.  Normally
      it's the upstream bridge, but an integrated endpoint has no upstream
      bridge.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8b2ec318
  9. 19 8月, 2016 1 次提交
  10. 17 8月, 2016 1 次提交
    • C
      PCI: Use positive flags in pci_alloc_irq_vectors() · 4fe0d154
      Christoph Hellwig 提交于
      Instead of passing negative flags like PCI_IRQ_NOMSI to prevent use of
      certain interrupt types, pass positive flags like PCI_IRQ_LEGACY,
      PCI_IRQ_MSI, etc., to specify the acceptable interrupt types.
      
      This is based on a number of pending driver conversions that just happend
      to be a whole more obvious to read this way, and given that we have no
      users in the tree yet it can still easily be done.
      
      I've also added a PCI_IRQ_ALL_TYPES catchall to keep the case of accepting
      all interrupt types very simple.
      
      [bhelgaas: changelog, fix PCI_IRQ_AFFINITY doc typo, remove mention of
      PCI_IRQ_NOLEGACY]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NAlexander Gordeev <agordeev@redhat.com>
      4fe0d154
  11. 16 8月, 2016 1 次提交
  12. 26 7月, 2016 1 次提交
  13. 22 7月, 2016 2 次提交
  14. 24 6月, 2016 1 次提交
    • L
      PCI: Add generic pci_bus_claim_resources() · 765bf9b7
      Lorenzo Pieralisi 提交于
      All PCI resources (bridge windows and BARs) should be inserted in the
      iomem_resource and ioport_resource trees so we know what space is occupied
      and what is available for other devices.  There's nothing arch-specific
      about this, but it is currently done by arch-specific code.
      
      Add a generic pci_bus_claim_resources() interface so we can migrate away
      from the arch-specific code.
      
      [bhelgaas: changelog]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Yinghai Lu <yinghai@kernel.org>
      765bf9b7
  15. 22 6月, 2016 1 次提交
  16. 21 6月, 2016 1 次提交
    • G
      PCI: Add pcibios_setup_bridge() · d366d28c
      Gavin Shan 提交于
      Currently, PowerPC PowerNV platform utilizes ppc_md.pcibios_fixup(),
      which is called for once after PCI probing and resource assignment
      are completed, to allocate platform required resources for PCI devices:
      PE#, IO and MMIO mapping, DMA address translation (TCE) table etc.
      Obviously, it's not hotplug friendly.
      
      This adds weak function pcibios_setup_bridge(), which is called by
      pci_setup_bridge(). PowerPC PowerNV platform will reuse the function
      to assign above platform required resources to newly plugged PCI devices
      during PCI hotplug in subsequent patches.
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d366d28c
  17. 18 6月, 2016 2 次提交
  18. 14 6月, 2016 1 次提交
    • M
      PCI: Put PCIe ports into D3 during suspend · 9d26d3a8
      Mika Westerberg 提交于
      Currently the Linux PCI core does not touch power state of PCI bridges and
      PCIe ports when system suspend is entered.  Leaving them in D0 consumes
      power unnecessarily and may prevent the CPU from entering deeper C-states.
      
      With recent PCIe hardware we can power down the ports to save power given
      that we take into account few restrictions:
      
        - The PCIe port hardware is recent enough, starting from 2015.
      
        - Devices connected to PCIe ports are effectively in D3cold once the port
          is transitioned to D3 (the config space is not accessible anymore and
          the link may be powered down).
      
        - Devices behind the PCIe port need to be allowed to transition to D3cold
          and back.  There is a way both drivers and userspace can forbid this.
      
        - If the device behind the PCIe port is capable of waking the system it
          needs to be able to do so from D3cold.
      
      This patch adds a new flag to struct pci_device called 'bridge_d3'.  This
      flag is set and cleared by the PCI core whenever there is a change in power
      management state of any of the devices behind the PCIe port.  When system
      later on is suspended we only need to check this flag and if it is true
      transition the port to D3 otherwise we leave it in D0.
      
      Also provide override mechanism via command line parameter
      "pcie_port_pm=[off|force]" that can be used to disable or enable the
      feature regardless of the BIOS manufacturing date.
      Tested-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d26d3a8
  19. 13 6月, 2016 1 次提交
  20. 11 6月, 2016 4 次提交
  21. 07 6月, 2016 1 次提交
    • B
      PCI: Add devm_request_pci_bus_resources() · 950334bc
      Bjorn Helgaas 提交于
      Several host bridge drivers iterate through the list of bridge windows to
      request resources.  Several others don't request the window resources at
      all.
      
      Add a devm_request_pci_bus_resources() interface to make it easier for
      drivers to request all the window resources.  Export to GPL modules (from
      Arnd Bergmann <arnd@arndb.de>).
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      950334bc
  22. 12 5月, 2016 1 次提交
  23. 20 4月, 2016 1 次提交
  24. 16 4月, 2016 1 次提交
  25. 12 4月, 2016 2 次提交
  26. 09 3月, 2016 3 次提交
  27. 08 3月, 2016 2 次提交
  28. 26 2月, 2016 1 次提交
    • B
      PCI: Disable IO/MEM decoding for devices with non-compliant BARs · b84106b4
      Bjorn Helgaas 提交于
      The PCI config header (first 64 bytes of each device's config space) is
      defined by the PCI spec so generic software can identify the device and
      manage its usage of I/O, memory, and IRQ resources.
      
      Some non-spec-compliant devices put registers other than BARs where the
      BARs should be.  When the PCI core sizes these "BARs", the reads and writes
      it does may have unwanted side effects, and the "BAR" may appear to
      describe non-sensical address space.
      
      Add a flag bit to mark non-compliant devices so we don't touch their BARs.
      Turn off IO/MEM decoding to prevent the devices from consuming address
      space, since we can't read the BARs to find out what that address space
      would be.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Tested-by: NAndi Kleen <ak@linux.intel.com>
      CC: stable@vger.kernel.org
      b84106b4
  29. 19 2月, 2016 1 次提交
  30. 18 2月, 2016 1 次提交
  31. 17 2月, 2016 1 次提交