1. 08 1月, 2009 7 次提交
  2. 23 10月, 2008 1 次提交
  3. 21 10月, 2008 4 次提交
  4. 17 7月, 2008 1 次提交
  5. 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
  6. 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
  7. 12 6月, 2008 1 次提交
  8. 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
  9. 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
  10. 02 2月, 2008 3 次提交
  11. 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
  12. 13 10月, 2007 2 次提交
    • R
      pci: implement "pci=noaer" · 7f785763
      Randy Dunlap 提交于
      For cases in which CONFIG_PCIEAER=y (such as distro kernels), allow users
      to disable PCIE Advanced Error Reporting by using "pci=noaer" on the
      kernel command line.
      
      This can be used to work around hardware or (kernel) software problems.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7f785763
    • K
      Driver core: change add_uevent_var to use a struct · 7eff2e7a
      Kay Sievers 提交于
      This changes the uevent buffer functions to use a struct instead of a
      long list of parameters. It does no longer require the caller to do the
      proper buffer termination and size accounting, which is currently wrong
      in some places. It fixes a known bug where parts of the uevent
      environment are overwritten because of wrong index calculations.
      
      Many thanks to Mathieu Desnoyers for finding bugs and improving the
      error handling.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      7eff2e7a
  13. 23 8月, 2007 1 次提交
  14. 25 7月, 2007 1 次提交
  15. 22 7月, 2007 1 次提交
  16. 03 5月, 2007 1 次提交
  17. 13 3月, 2007 1 次提交
    • E
      [PATCH] msi: Safer state caching. · 392ee1e6
      Eric W. Biederman 提交于
      There are two ways pci_save_state and pci_restore_state are used.  As
      helper functions during suspend/resume, and as helper functions around
      a hardware reset event.  When used as helper functions around a hardware
      reset event there is no reason to believe the calls will be paired, nor
      is there a good reason to believe that if we restore the msi state from
      before the reset that it will match the current msi state.  Since arch
      code may change the msi message without going through the driver, drivers
      currently do not have enough information to even know when to call
      pci_save_state to ensure they will have msi state in sync with the other
      kernel irq reception data structures.
      
      It turns out the solution is straight forward, cache the state in the
      existing msi data structures (not the magic pci saved things) and
      have the msi code update the cached state each time we write to the hardware.
      This means we never need to read the hardware to figure out what the hardware
      state should be.
      
      By modifying the caching in this manner we get to remove our save_state
      routines and only need to provide restore_state routines.
      
      The only fields that were at all tricky to regenerate were the msi and msi-x
      control registers and the way we regenerate them currently is a bit dependent
      upon assumptions on how we use the allow msi registers to be configured and used
      making the code a little bit brittle.  If we ever change what cases we allow
      or how we configure the msi bits we can address the fragility then.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      392ee1e6
  18. 05 3月, 2007 1 次提交
    • E
      [PATCH] msi: sanely support hardware level msi disabling · f5f2b131
      Eric W. Biederman 提交于
      In some cases when we are not using msi we need a way to ensure that the
      hardware does not have an msi capability enabled.  Currently the code has been
      calling disable_msi_mode to try and achieve that.  However disable_msi_mode
      has several other side effects and is only available when msi support is
      compiled in so it isn't really appropriate.
      
      Instead this patch implements pci_msi_off which disables all msi and msix
      capabilities unconditionally with no additional side effects.
      
      pci_disable_device was redundantly clearing the bus master enable flag and
      clearing the msi enable bit.  A device that is not allowed to perform bus
      mastering operations cannot generate intx or msi interrupt messages as those
      are essentially a special case of dma, and require bus mastering.  So the call
      in pci_disable_device to disable msi capabilities was redundant.
      
      quirk_pcie_pxh also called disable_msi_mode and is updated to use pci_msi_off.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f5f2b131
  19. 08 2月, 2007 4 次提交
  20. 02 12月, 2006 1 次提交
    • I
      PCI: switch pci_{enable,disable}_device() to be nestable · bae94d02
      Inaky Perez-Gonzalez 提交于
      Changes the pci_{enable,disable}_device() functions to work in a
      nested basis, so that eg, three calls to enable_device() require three
      calls to disable_device().
      
      The reason for this is to simplify PCI drivers for
      multi-interface/capability devices. These are devices that cram more
      than one interface in a single function. A relevant example of that is
      the Wireless [USB] Host Controller Interface (similar to EHCI) [see
      http://www.intel.com/technology/comms/wusb/whci.htm]. 
      
      In these kind of devices, multiple interfaces are accessed through a
      single bar and IRQ line. For that, the drivers map only the smallest
      area of the bar to access their register banks and use shared IRQ
      handlers. 
      
      However, because the order at which those drivers load cannot be known
      ahead of time, the sequence in which the calls to pci_enable_device()
      and pci_disable_device() cannot be predicted. Thus:
      
      1. driverA     starts     pci_enable_device()
      2. driverB     starts     pci_enable_device()
      3. driverA     shutdown   pci_disable_device()
      4. driverB     shutdown   pci_disable_device()
      
      between steps 3 and 4, driver B would loose access to it's device,
      even if it didn't intend to.
      
      By using this modification, the device won't be disabled until all the
      callers to enable() have called disable().
      
      This is implemented by replacing 'struct pci_dev->is_enabled' from a
      bitfield to an atomic use count. Each caller to enable increments it,
      each caller to disable decrements it. When the count increments from 0
      to 1, __pci_enable_device() is called to actually enable the
      device. When it drops to zero, pci_disable_device() actually does the
      disabling.
      
      We keep the backend __pci_enable_device() for pci_default_resume() to
      use and also change the sysfs method implementation, so that userspace
      enabling/disabling the device doesn't disable it one time too much.
      Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bae94d02
  21. 27 9月, 2006 1 次提交
  22. 13 7月, 2006 1 次提交
    • K
      [PATCH] PCI: PCIE power management quirk · ffadcc2f
      Kristen Carlson Accardi 提交于
      When changing power states from D0->DX and then from DX->D0, some
      Intel PCIE chipsets will cause a device reset to occur.  This will
      cause problems for any D State other than D3, since any state
      information that the driver will expect to be present coming from
      a D1 or D2 state will have been cleared.  This patch addes a
      flag to the pci_dev structure to indicate that devices should
      not use states D1 or D2, and will set that flag for the affected
      chipsets.  This patch also modifies pci_set_power_state() so that
      when a device driver tries to set the power state on
      a device that is downstream from an affected chipset, or on one
      of the affected devices it only allows state changes to or
      from D0 & D3.  In addition, this patch allows the delay time
      between D3->D0 to be changed via a quirk.  These chipsets also
      need additional time to change states beyond the normal 10ms.
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ffadcc2f
  23. 28 6月, 2006 1 次提交
  24. 22 6月, 2006 1 次提交