1. 27 4月, 2008 3 次提交
    • Y
      x86 pci: remove checking type for mmconfig probe · bb63b421
      Yinghai Lu 提交于
      doesn't need to check if it is type1 or type2, we can use raw_pci_ops
      directly.
      
      also make pci_direct_conf1 static again.
      
      anyway is there system with type 2 and mmconf support?
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bb63b421
    • Y
      x86_64: set cfg_size for AMD Family 10h in case MMCONFIG · 57741a77
      Yinghai Lu 提交于
      reuse pci_cfg_space_size but skip check pci express and pci-x CAP ID.
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      57741a77
    • R
      x86: validate against acpi motherboard resources · 7752d5cf
      Robert Hancock 提交于
      This path adds validation of the MMCONFIG table against the ACPI reserved
      motherboard resources.  If the MMCONFIG table is found to be reserved in
      ACPI, we don't bother checking the E820 table.  The PCI Express firmware
      spec apparently tells BIOS developers that reservation in ACPI is required
      and E820 reservation is optional, so checking against ACPI first makes
      sense.  Many BIOSes don't reserve the MMCONFIG region in E820 even though
      it is perfectly functional, the existing check needlessly disables MMCONFIG
      in these cases.
      
      In order to do this, MMCONFIG setup has been split into two phases.  If PCI
      configuration type 1 is not available then MMCONFIG is enabled early as
      before.  Otherwise, it is enabled later after the ACPI interpreter is
      enabled, since we need to be able to execute control methods in order to
      check the ACPI reserved resources.  Presently this is just triggered off
      the end of ACPI interpreter initialization.
      
      There are a few other behavioral changes here:
      
      - Validate all MMCONFIG configurations provided, not just the first one.
      
      - Validate the entire required length of each configuration according to
        the provided ending bus number is reserved, not just the minimum required
        allocation.
      
      - Validate that the area is reserved even if we read it from the chipset
        directly and not from the MCFG table.  This catches the case where the
        BIOS didn't set the location properly in the chipset and has mapped it
        over other things it shouldn't have.
      
      This also cleans up the MMCONFIG initialization functions so that they
      simply do nothing if MMCONFIG is not compiled in.
      
      Based on an original patch by Rajesh Shah from Intel.
      
      [akpm@linux-foundation.org: many fixes and cleanups]
      Signed-off-by: NRobert Hancock <hancockr@shaw.ca>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NAndi Kleen <ak@suse.de>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7752d5cf
  2. 21 4月, 2008 9 次提交
    • B
      PCI: Expose PCI VPD through sysfs · 94e61088
      Ben Hutchings 提交于
      Vital Product Data (VPD) may be exposed by PCI devices in several
      ways.  It is generally unsafe to read this information through the
      existing interfaces to user-land because of stateful interfaces.
      
      This adds:
      - abstract operations for VPD access (struct pci_vpd_ops)
      - VPD state information in struct pci_dev (struct pci_vpd)
      - an implementation of the VPD access method specified in PCI 2.2
        (in access.c)
      - a 'vpd' binary file in sysfs directories for PCI devices with VPD
        operations defined
      
      It adds a probe for PCI 2.2 VPD in pci_scan_device() and release of
      VPD state in pci_release_dev().
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      94e61088
    • B
      PCI: add generic pci_enable_resources() · 842de40d
      Bjorn Helgaas 提交于
      Each architecture has its own pcibios_enable_resources() implementation.
      These differ in many minor ways that have nothing to do with actual
      architectural differences.  Follow-on patches will make most arches
      use this generic version instead.
      
      This version is based on powerpc, which seemed most up-to-date.  The only
      functional difference from the x86 version is that this uses "!r->parent"
      to check for resource collisions instead of "!r->start && r->end".
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      842de40d
    • S
      PCI: add PCI Express ASPM support · 7d715a6c
      Shaohua Li 提交于
      PCI Express ASPM defines a protocol for PCI Express components in the D0
      state to reduce Link power by placing their Links into a low power state
      and instructing the other end of the Link to do likewise. This
      capability allows hardware-autonomous, dynamic Link power reduction
      beyond what is achievable by software-only controlled power management.
      However, The device should be configured by software appropriately.
      Enabling ASPM will save power, but will introduce device latency.
      
      This patch adds ASPM support in Linux. It introduces a global policy for
      ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
      it. The interface can be used as a boot option too. Currently we have
      below setting:
              -default, BIOS default setting
              -powersave, highest power saving mode, enable all available ASPM
      state and clock power management
              -performance, highest performance, disable ASPM and clock power
      management
      By default, the 'default' policy is used currently.
      
      In my test, power difference between powersave mode and performance mode
      is about 1.3w in a system with 3 PCIE links.
      
      Note: some devices might not work well with aspm, either because chipset
      issue or device issue. The patch provide API (pci_disable_link_state),
      driver can disable ASPM for specific device.
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7d715a6c
    • G
      PCI: remove global list of PCI devices · 5ff580c1
      Greg Kroah-Hartman 提交于
      This patch finally removes the global list of PCI devices.  We are
      relying entirely on the list held in the driver core now, and do not
      need a separate "shadow" list as no one uses it.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5ff580c1
    • G
      PCI: add is_added flag to struct pci_dev · 8a1bc901
      Greg Kroah-Hartman 提交于
      This lets us check if the device is really added to the driver core or
      not, which is what we need when walking some of the bus lists.  The flag
      is there in anticipation of getting rid of the other PCI device list,
      which is what we used to check in this situation.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8a1bc901
    • G
      PCI: clean up search.c a lot · 95247b57
      Greg Kroah-Hartman 提交于
      This cleans up the search.c file, now using the pci list of devices that
      are created for the driver core, instead of relying on our separate list
      of devices.  It's better to use the functions already created for this
      kind of thing, instead of rolling our own all the time.
      
      This work is done in anticipation of getting rid of that second list of
      pci devices all together.
      
      And it ends up saving code, always a nice benefit.
      
      This also removes one compiler warning for when CONFIG_PCI_LEGACY is
      enabled as we no longer internally use the deprecated functions anymore.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      95247b57
    • G
      PCI: remove pci_get_device_reverse · 34220909
      Greg Kroah-Hartman 提交于
      This removes the pci_get_device_reverse function as there should not be
      any need to walk pci devices backwards anymore.  All users of this call
      are now gone from the tree, so it is safe to remove it.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      34220909
    • G
      PCI: remove pci_find_present · 448432c4
      Greg Kroah-Hartman 提交于
      No one is using this function anymore for quite some time, so remove it.
      Everyone calls pci_dev_present() instead anyway...
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      448432c4
    • A
      PCI: #if 0 pci_assign_resource_fixed() · 2baad5f9
      Adrian Bunk 提交于
      An unused function that bloated the kernel only when CONFIG_EMBEDDED was
      enabled...
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2baad5f9
  3. 25 3月, 2008 1 次提交
  4. 17 3月, 2008 1 次提交
  5. 14 3月, 2008 1 次提交
    • G
      PCI: fix issue with busses registering multiple times in sysfs · cc74d96f
      Greg Kroah-Hartman 提交于
      PCI busses can be registered multiple times, so we need to detect if we
      have registered our bus structure in sysfs already.  If so, don't do it
      again.
      
      Thanks to Guennadi Liakhovetski <g.liakhovetski@gmx.de> for reporting
      the problem, and to Linus for poking me to get me to believe that it was
      a real problem.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      cc74d96f
  6. 11 3月, 2008 2 次提交
  7. 05 3月, 2008 1 次提交
    • J
      PCI: Add DECLARE_PCI_DEVICE_TABLE macro · 90a1ba0c
      Jonas Bonn 提交于
      The definitions of struct pci_device_id arrays should generally follow
      the same pattern across the entire kernel.  This macro defines this
      array as const and puts it into the __devinitconst section.
      
      There are currently many definitions scattered about the kernel that
      omit the __devinitdata modifier despite the documentation stating that
      it should always be there.  These definitions really also should have
      been const, which wasn't possible before but has become so with the
      addition of the __devinitconst attribute.
      
      Furthermore, there are definitions that use "const" and __devinitdata,
      which is explicitly wrong but the compiler doesn't catch section
      mismatches if there's only one such one case in the module (which is
      often the case).
      
      Adding the __devinitconst modifier where there was nothing before buys
      us memory.  Adding the const modifier gives the compiler a chance to do
      its thing.  Changing __devinitdata to __devinitconst where it was wrong
      actually fixes some compiler errors in older (mid-release) kernels that
      were patched over by "removing" the section attribute altogether (which
      wastes memory).
      
      This macro makes it pretty difficult to get this definition wrong in
      the future...
      Signed-off-by: NJonas Bonn <jonas@southpole.se>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      90a1ba0c
  8. 11 2月, 2008 1 次提交
  9. 06 2月, 2008 2 次提交
  10. 03 2月, 2008 1 次提交
  11. 02 2月, 2008 11 次提交
  12. 29 1月, 2008 1 次提交
  13. 06 11月, 2007 3 次提交
  14. 22 10月, 2007 1 次提交
    • K
      Intel IOMMU: PCI generic helper function · 994a65e2
      Keshavamurthy, Anil S 提交于
      When devices are under a p2p bridge, upstream transactions get replaced by the
      device id of the bridge as it owns the PCIE transaction.  Hence its necessary
      to setup translations on behalf of the bridge as well.  Due to this limitation
      all devices under a p2p share the same domain in a DMAR.
      
      We just cache the type of device, if its a native PCIe device
      or not for later use.
      
      [akpm@linux-foundation.org: BUG_ON -> WARN_ON+recover]
      Signed-off-by: NAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      994a65e2
  15. 13 10月, 2007 1 次提交
  16. 23 8月, 2007 1 次提交