1. 10 9月, 2009 1 次提交
  2. 30 8月, 2009 1 次提交
    • C
      PCI SR-IOV: correct broken resource alignment calculations · 6faf17f6
      Chris Wright 提交于
      An SR-IOV capable device includes an SR-IOV PCIe capability which
      describes the Virtual Function (VF) BAR requirements.  A typical SR-IOV
      device can support multiple VFs whose BARs must be in a contiguous region,
      effectively an array of VF BARs.  The BAR reports the size requirement
      for a single VF.  We calculate the full range needed by simply multiplying
      the VF BAR size with the number of possible VFs and create a resource
      spanning the full range.
      
      This all seems sane enough except it artificially inflates the alignment
      requirement for the VF BAR.  The VF BAR need only be aligned to the size
      of a single BAR not the contiguous range of VF BARs.  This can cause us
      to fail to allocate resources for the BAR despite the fact that we
      actually have enough space.
      
      This patch adds a thin PCI specific layer over the generic
      resource_alignment() function which is aware of the special nature of
      VF BARs and does sorting and allocation based on the smaller alignment
      requirement.
      
      I recognize that while resource_alignment is generic, it's basically a
      PCI helper.  An alternative to this patch is to add PCI VF BAR specific
      information to struct resource.  I opted for the extra layer rather than
      adding such PCI specific information to struct resource.  This does
      have the slight downside that we don't cache the BAR size and re-read
      for each alignment query (happens a small handful of times during boot
      for each VF BAR).
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Yu Zhao <yu.zhao@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6faf17f6
  3. 18 5月, 2009 2 次提交
  4. 31 3月, 2009 1 次提交
  5. 21 3月, 2009 8 次提交
  6. 14 2月, 2009 1 次提交
  7. 17 1月, 2009 1 次提交
    • R
      PCI PM: Restore standard config registers of all devices early · aa8c6c93
      Rafael J. Wysocki 提交于
      There is a problem in our handling of suspend-resume of PCI devices that
      many of them have their standard config registers restored with
      interrupts enabled and they are put into the full power state with
      interrupts enabled as well.  This may lead to the following scenario:
        * an interrupt vector is shared between two or more devices
        * one device is resumed earlier and generates an interrupt
        * the interrupt handler of another device tries to handle it and
          attempts to access the device the config space of which hasn't been
          restored yet and/or which still is in a low power state
        * the system crashes as a result
      
      To prevent this from happening we should restore the standard
      configuration registers of all devices with interrupts disabled and we
      should put them into the D0 power state right after that.
      Unfortunately, this cannot be done using the existing
      pci_set_power_state(), because it can sleep.  Also, to do it we have to
      make sure that the config spaces of all devices were actually saved
      during suspend.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      aa8c6c93
  8. 08 1月, 2009 11 次提交
  9. 23 10月, 2008 1 次提交
  10. 21 10月, 2008 4 次提交
  11. 17 7月, 2008 1 次提交
  12. 08 7月, 2008 2 次提交
    • R
      PCI ACPI: Rework PCI handling of wake-up · eb9d0fe4
      Rafael J. Wysocki 提交于
      * Introduce function acpi_pm_device_sleep_wake() for enabling and
        disabling the system wake-up capability of devices that are power
        manageable by ACPI.
      
      * Introduce function acpi_bus_can_wakeup() allowing other (dependent)
        subsystems to check if ACPI is able to enable the system wake-up
        capability of given device.
      
      * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and
        for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake().
      
      * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and
        for the ACPI 'driver' make it use acpi_bus_can_wakeup().
      
      * Move the PME# handlig code out of pci_enable_wake() and split it
        into two functions, pci_pme_capable() and pci_pme_active(),
        allowing the caller to check if given device is capable of
        generating PME# from given power state and to enable/disable the
        device's PME# functionality, respectively.
      
      * Modify pci_enable_wake() to use the new ACPI callbacks and the new
        PME#-related functions.
      
      * Drop the generic .platform_enable_wakeup() callback that is not
        used any more.
      
      * Introduce device_set_wakeup_capable() that will set the
        power.can_wakeup flag of given device.
      
      * Rework PCI device PM initialization so that, if given device is
        capable of generating wake-up events, either natively through the
        PME# mechanism, or with the help of the platform, its
        power.can_wakeup flag is set and its power.should_wakeup flag is
        unset as appropriate.
      
      * Make ACPI set the power.can_wakeup flag for devices found to be
        wake-up capable by it.
      
      * Make the ACPI wake-up code enable/disable GPEs for devices that
        have the wakeup.flags.prepared flag set (which means that their
        wake-up power has been enabled).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      eb9d0fe4
    • R
      PCI: Introduce platform_pci_power_manageable function · 961d9120
      Rafael J. Wysocki 提交于
      Introduce function pointer platform_pci_power_manageable to be used
      by the platform-related code to point to a function allowing us to
      check if given device is power manageable by the platform.
      
      Introduce acpi_pci_power_manageable() playing that role for ACPI.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      961d9120
  13. 03 7月, 2008 1 次提交
    • B
      PCI: Limit VPD read/write lengths for Broadcom 5706, 5708, 5709 rev. · 99cb233d
      Benjamin Li 提交于
      For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the
      VPD end tag will hang the device.  This problem was initially
      observed when a vpd entry was created in sysfs
      ('/sys/bus/pci/devices/<id>/vpd').   A read to this sysfs entry
      will dump 32k of data.  Reading a full 32k will cause an access
      beyond the VPD end tag causing the device to hang.  Once the device
      is hung, the bnx2 driver will not be able to reset the device.
      We believe that it is legal to read beyond the end tag and
      therefore the solution is to limit the read/write length.
      
      A majority of this patch is from Matthew Wilcox who gave code for
      reworking the PCI vpd size information.  A PCI quirk added for the
      Broadcom NIC's to limit the read/write's.
      Signed-off-by: NBenjamin Li <benli@broadcom.com>
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      99cb233d
  14. 12 6月, 2008 1 次提交
  15. 11 6月, 2008 1 次提交
    • A
      PCI: introduce pci_slot · f46753c5
      Alex Chiang 提交于
      Currently, /sys/bus/pci/slots/ only exposes hotplug attributes when a
      hotplug driver is loaded, but PCI slots have attributes such as address,
      speed, width, etc.  that are not related to hotplug at all.
      
      Introduce pci_slot as the primary data structure and kobject model.
      Hotplug attributes described in hotplug_slot become a secondary
      structure associated with the pci_slot.
      
      This patch only creates the infrastructure that allows the separation of
      PCI slot attributes and hotplug attributes.  In this patch, the PCI
      hotplug core remains the only user of this infrastructure, and thus,
      /sys/bus/pci/slots/ will still only become populated when a hotplug
      driver is loaded.
      
      A later patch in this series will add a second user of this new
      infrastructure and demonstrate splitting the task of exposing pci_slot
      attributes from hotplug_slot attributes.
      
        - Make pci_slot the primary sysfs entity. hotplug_slot becomes a
          subsidiary structure.
          o pci_create_slot() creates and registers a slot with the PCI core
          o pci_slot_add_hotplug() gives it hotplug capability
      
        - Change the prototype of pci_hp_register() to take the bus and
          slot number (on parent bus) as parameters.
      
        - Remove all the ->get_address methods since this functionality is
          now handled by pci_slot directly.
      
      [achiang@hp.com: rpaphp-correctly-pci_hp_register-for-empty-pci-slots]
      Tested-by: NBadari Pulavarty <pbadari@us.ibm.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: make headers_check happy]
      [akpm@linux-foundation.org: nuther build fix]
      [akpm@linux-foundation.org: fix typo in #include]
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Cc: Greg KH <greg@kroah.com>
      Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f46753c5
  16. 21 4月, 2008 1 次提交
    • 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
  17. 02 2月, 2008 2 次提交