1. 06 11月, 2012 1 次提交
  2. 06 7月, 2012 1 次提交
    • R
      PCI / PM: restore the original behavior of pci_set_power_state() · db288c9c
      Rafael J. Wysocki 提交于
      Commit cc2893b6 (PCI: Ensure we re-enable devices on resume)
      addressed the problem with USB not being powered after resume on
      recent Lenovo machines, but it did that in a suboptimal way.
      Namely, it should have changed the relevant code paths only,
      which are pci_pm_resume_noirq() and pci_pm_restore_noirq() supposed
      to restore the device's power and standard configuration registers
      after system resume from suspend or hibernation.  Instead, however,
      it modified pci_set_power_state() which is executed in several
      other situations too.  That resulted in some undesirable effects,
      like attempting to change a device's power state in the same way
      multiple times in a row (up to as many as 4 times in a row in the
      snd_hda_intel driver).
      
      Fix the bug addressed by commit cc2893b6 in an alternative way,
      by forcibly powering up all devices in pci_pm_default_resume_early(),
      which is called by pci_pm_resume_noirq() and pci_pm_restore_noirq()
      to restore the device's power and standard configuration registers,
      and modifying pci_pm_runtime_resume() to avoid the forcible power-up
      if not necessary.  Then, revert the changes made by commit cc2893b6
      to make the confusion introduced by it go away.
      Acked-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      db288c9c
  3. 24 6月, 2012 1 次提交
    • H
      PCI/PM: add PCIe runtime D3cold support · 448bd857
      Huang Ying 提交于
      This patch adds runtime D3cold support and corresponding ACPI platform
      support.  This patch only enables runtime D3cold support; it does not
      enable D3cold support during system suspend/hibernate.
      
      D3cold is the deepest power saving state for a PCIe device, where its main
      power is removed.  While it is in D3cold, you can't access the device at
      all, not even its configuration space (which is still accessible in D3hot).
      Therefore the PCI PM registers can not be used to transition into/out of
      the D3cold state; that must be done by platform logic such as ACPI _PR3.
      
      To support wakeup from D3cold, a system may provide auxiliary power, which
      allows a device to request wakeup using a Beacon or the sideband WAKE#
      signal.  WAKE# is usually connected to platform logic such as ACPI GPE.
      This is quite different from other power saving states, where devices
      request wakeup via a PME message on the PCIe link.
      
      Some devices, such as those in plug-in slots, have no direct platform
      logic.  For example, there is usually no ACPI _PR3 for them.  D3cold
      support for these devices can be done via the PCIe Downstream Port leading
      to the device.  When the PCIe port is powered on/off, the device is powered
      on/off too.  Wakeup events from the device will be notified to the
      corresponding PCIe port.
      
      For more information about PCIe D3cold and corresponding ACPI support,
      please refer to:
      
      - PCI Express Base Specification Revision 2.0
      - Advanced Configuration and Power Interface Specification Revision 5.0
      
      [bhelgaas: changelog]
      Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
      Originally-by: NZheng Yan <zheng.z.yan@intel.com>
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      448bd857
  4. 14 6月, 2012 2 次提交
  5. 12 6月, 2012 1 次提交
  6. 01 5月, 2012 2 次提交
  7. 25 2月, 2012 2 次提交
  8. 24 2月, 2012 1 次提交
    • Y
      PCI: fix memleak for pci dev removing during hotplug · f796841e
      Yinghai Lu 提交于
      unreferenced object 0xffff880276d17700 (size 64):
        comm "swapper/0", pid 1, jiffies 4294897182 (age 3976.028s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 18 f9 de 76 02 88 ff ff  ...........v....
          10 00 00 00 0e 00 00 00 0f 28 40 00 00 00 00 00  .........(@.....
        backtrace:
          [<ffffffff81c8aede>] kmemleak_alloc+0x26/0x43
          [<ffffffff811385f0>] __kmalloc+0x121/0x183
          [<ffffffff813cf821>] pci_add_cap_save_buffer+0x35/0x7c
          [<ffffffff813d12b7>] pci_allocate_cap_save_buffers+0x1d/0x65
          [<ffffffff813cdb52>] pci_device_add+0x92/0xf1
          [<ffffffff81c8afe6>] pci_scan_single_device+0x9f/0xa1
          [<ffffffff813cdbd2>] pci_scan_slot.part.20+0x21/0x106
          [<ffffffff813cdce2>] pci_scan_slot+0x2b/0x35
          [<ffffffff81c8dae4>] __pci_scan_child_bus+0x51/0x107
          [<ffffffff81c8d75b>] pci_scan_bridge+0x376/0x6ae
          [<ffffffff81c8db60>] __pci_scan_child_bus+0xcd/0x107
          [<ffffffff81c8dbab>] pci_scan_child_bus+0x11/0x2a
          [<ffffffff81cca58c>] pci_acpi_scan_root+0x18b/0x21c
          [<ffffffff81c916be>] acpi_pci_root_add+0x1e1/0x42a
          [<ffffffff81406210>] acpi_device_probe+0x50/0x190
          [<ffffffff814a0227>] really_probe+0x99/0x126
      
      Need to free saved_buffer for capabilities.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f796841e
  9. 15 2月, 2012 1 次提交
  10. 07 1月, 2012 2 次提交
  11. 02 8月, 2011 1 次提交
  12. 09 7月, 2011 1 次提交
  13. 21 6月, 2011 1 次提交
    • O
      x86/ia64: intel-iommu: move to drivers/iommu/ · 166e9278
      Ohad Ben-Cohen 提交于
      This should ease finding similarities with different platforms,
      with the intention of solving problems once in a generic framework
      which everyone can use.
      
      Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge()
      has to move from drivers/pci/pci.h to include/linux/pci.h. This is handled
      in this patch, too.
      
      As suggested, also drop DMAR's EXPERIMENTAL tag while we're at it.
      
      Compile-tested on x86_64.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      166e9278
  14. 22 5月, 2011 2 次提交
  15. 11 4月, 2011 1 次提交
  16. 05 3月, 2011 1 次提交
    • N
      PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs · 6058989b
      Narendra_K@Dell.com 提交于
      This patch exports ACPI _DSM (Device Specific Method) provided firmware
      instance number and string name of PCI devices as defined by 'PCI
      Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming a
      PCI or PCI Express Device Under Operating Systems) to sysfs.
      
      New files created are:
        /sys/bus/pci/devices/.../label which contains the firmware name for
      the device in question, and
        /sys/bus/pci/devices/.../acpi_index which contains the firmware device type
      instance for the given device.
      
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index
      1
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label
      Embedded Broadcom 5709C NIC 1
      
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index
      2
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label
      Embedded Broadcom 5709C NIC 2
      
      The ACPI _DSM provided firmware 'instance number' and 'string name' will
      be given priority if the firmware also provides 'SMBIOS type 41 device
      type instance and string'.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NJordan Hargrave <jordan_hargrave@dell.com>
      Signed-off-by: NNarendra K <narendra_k@dell.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6058989b
  17. 15 1月, 2011 2 次提交
  18. 12 11月, 2010 1 次提交
    • M
      PCI: fix size checks for mmap() on /proc/bus/pci files · 3b519e4e
      Martin Wilck 提交于
      The checks for valid mmaps of PCI resources made through /proc/bus/pci files
      that were introduced in 9eff02e2 have several
      problems:
      
      1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0,
      whereas under /sys/bus/pci/devices, the start of the resource corresponds
      to offset 0. This may lead to false negatives in pci_mmap_fits(), which
      implicitly assumes the /sys/bus/pci/devices layout.
      
      2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads
      to false positives, because pci_mmap_fits() doesn't treat empty resources
      correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT)
      in this case!).
      
      3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus
      WARNINGS for the first resources that don't fit until the correct one is found.
      
      On many controllers the first 2-4 BARs are used, and the others are empty.
      In this case, an mmap attempt will first fail on the non-empty BARs
      (including the "right" BAR because of 1.) and emit bogus WARNINGS because
      of 3., and finally succeed on the first empty BAR because of 2.
      This is certainly not the intended behaviour.
      
      This patch addresses all 3 issues.
      Updated with an enum type for the additional parameter for pci_mmap_fits().
      
      Cc: stable@kernel.org
      Signed-off-by: NMartin Wilck <martin.wilck@ts.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      3b519e4e
  19. 18 10月, 2010 1 次提交
  20. 10 9月, 2010 1 次提交
  21. 25 8月, 2010 1 次提交
  22. 03 8月, 2010 1 次提交
    • N
      PCI: Fix warnings when CONFIG_DMI unset · b879743f
      Narendra K 提交于
      This patch fixes the below warnings introduced by the commit
      911e1c9b ("PCI:
      export SMBIOS provided firmware instance and label to sysfs").
      
      drivers/pci/pci.h: In function ‘pci_create_firmware_label_files’:
      drivers/pci/pci.h:16: warning: ‘return’ with a value, in function returning void
      drivers/pci/pci.h: In function ‘pci_remove_firmware_label_files’:
      drivers/pci/pci.h:18: warning: ‘return’ with a value, in function returning void
      
      The warnings are seen because of the below code, doing a retun 0
      from the functions 'pci_create_firmware_label_files' and
      'pci_remove_firmware_label_files' defined as void.
      
      +#ifndef CONFIG_DMI
      +static inline void pci_create_firmware_label_files(struct pci_dev *pdev)
      +{ return 0; }
      +static inline void pci_remove_firmware_label_files(struct pci_dev *pdev)
      +{ return 0; }
      Signed-off-by: NNarendra K <narendra_k@dell.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b879743f
  23. 31 7月, 2010 1 次提交
  24. 19 7月, 2010 1 次提交
    • R
      PM: Make it possible to avoid races between wakeup and system sleep · c125e96f
      Rafael J. Wysocki 提交于
      One of the arguments during the suspend blockers discussion was that
      the mainline kernel didn't contain any mechanisms making it possible
      to avoid races between wakeup and system suspend.
      
      Generally, there are two problems in that area.  First, if a wakeup
      event occurs exactly when /sys/power/state is being written to, it
      may be delivered to user space right before the freezer kicks in, so
      the user space consumer of the event may not be able to process it
      before the system is suspended.  Second, if a wakeup event occurs
      after user space has been frozen, it is not generally guaranteed that
      the ongoing transition of the system into a sleep state will be
      aborted.
      
      To address these issues introduce a new global sysfs attribute,
      /sys/power/wakeup_count, associated with a running counter of wakeup
      events and three helper functions, pm_stay_awake(), pm_relax(), and
      pm_wakeup_event(), that may be used by kernel subsystems to control
      the behavior of this attribute and to request the PM core to abort
      system transitions into a sleep state already in progress.
      
      The /sys/power/wakeup_count file may be read from or written to by
      user space.  Reads will always succeed (unless interrupted by a
      signal) and return the current value of the wakeup events counter.
      Writes, however, will only succeed if the written number is equal to
      the current value of the wakeup events counter.  If a write is
      successful, it will cause the kernel to save the current value of the
      wakeup events counter and to abort the subsequent system transition
      into a sleep state if any wakeup events are reported after the write
      has returned.
      
      [The assumption is that before writing to /sys/power/state user space
      will first read from /sys/power/wakeup_count.  Next, user space
      consumers of wakeup events will have a chance to acknowledge or
      veto the upcoming system transition to a sleep state.  Finally, if
      the transition is allowed to proceed, /sys/power/wakeup_count will
      be written to and if that succeeds, /sys/power/state will be written
      to as well.  Still, if any wakeup events are reported to the PM core
      by kernel subsystems after that point, the transition will be
      aborted.]
      
      Additionally, put a wakeup events counter into struct dev_pm_info and
      make these per-device wakeup event counters available via sysfs,
      so that it's possible to check the activity of various wakeup event
      sources within the kernel.
      
      To illustrate how subsystems can use pm_wakeup_event(), make the
      low-level PCI runtime PM wakeup-handling code use it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: Nmarkgross <markgross@thegnar.org>
      Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>
      c125e96f
  25. 11 5月, 2010 1 次提交
  26. 23 2月, 2010 4 次提交
    • R
      PCI PM: Run-time callbacks for PCI bus type · 6cbf8214
      Rafael J. Wysocki 提交于
      Introduce run-time PM callbacks for the PCI bus type.  Make the new
      callbacks work in analogy with the existing system sleep PM
      callbacks, so that the drivers already converted to struct dev_pm_ops
      can use their suspend and resume routines for run-time PM without
      modifications.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6cbf8214
    • R
      PCI / ACPI / PM: Platform support for PCI PME wake-up · b67ea761
      Rafael J. Wysocki 提交于
      Although the majority of PCI devices can generate PMEs that in
      principle may be used to wake up devices suspended at run time,
      platform support is generally necessary to convert PMEs into wake-up
      events that can be delivered to the kernel.  If ACPI is used for this
      purpose, PME signals generated by a PCI device will trigger the ACPI
      GPE associated with the device to generate an ACPI wake-up event that
      we can set up a handler for, provided that everything is configured
      correctly.
      
      Unfortunately, the subset of PCI devices that have GPEs associated
      with them is quite limited.  The devices without dedicated GPEs have
      to rely on the GPEs associated with other devices (in the majority of
      cases their upstream bridges and, possibly, the root bridge) to
      generate ACPI wake-up events in response to PME signals from them.
      
      Add ACPI platform support for PCI PME wake-up:
      o Add a framework making is possible to use ACPI system notify
        handlers for run-time PM.
      o Add new PCI platform callback ->run_wake() to struct
        pci_platform_pm_ops allowing us to enable/disable the platform to
        generate wake-up events for given device.  Implemet this callback
        for the ACPI platform.
      o Define ACPI wake-up handlers for PCI devices and PCI root buses and
        make the PCI-ACPI binding code register wake-up notifiers for all
        PCI devices present in the ACPI tables.
      o Add function pci_dev_run_wake() which can be used by PCI drivers to
        check if given device is capable of generating wake-up events at
        run time.
      
      Developed in cooperation with Matthew Garrett <mjg@redhat.com>.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b67ea761
    • R
      PCI PM: Add function for checking PME status of devices · 58ff4633
      Rafael J. Wysocki 提交于
      Add function pci_check_pme_status() that will check the PME status
      bit of given device and clear it along with the PME enable bit.  It
      will be necessary for PCI run-time power management.
      
      Based on a patch from Shaohua Li <shaohua.li@intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      58ff4633
    • R
      PCI: Clean up build for CONFIG_PCI_QUIRKS unset · 93177a74
      Rafael J. Wysocki 提交于
      Currently, drivers/pci/quirks.c is built unconditionally, but if
      CONFIG_PCI_QUIRKS is unset, the only things actually built in this
      file are definitions of global variables and empty functions (due to
      the #ifdef CONFIG_PCI_QUIRKS embracing all of the code inside the
      file).  This is not particularly nice and if someone overlooks
      the #ifdef CONFIG_PCI_QUIRKS, build errors are introduced.
      
      To clean that up, move the definitions of the global variables in
      quirks.c that are always built to pci.c, move the definitions of
      the empty functions (compiled when CONFIG_PCI_QUIRKS is unset) to
      headers (additionally make these functions static inline) and modify
      drivers/pci/Makefile so that quirks.c is only built if
      CONFIG_PCI_QUIRKS is set.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      93177a74
  27. 01 1月, 2010 1 次提交
  28. 17 12月, 2009 1 次提交
  29. 05 11月, 2009 1 次提交
    • A
      PCI: acs p2p upsteram forwarding enabling · ae21ee65
      Allen Kay 提交于
      Note: dom0 checking in v4 has been separated out into 2/2.
      
      This patch enables P2P upstream forwarding in ACS capable PCIe switches.
      It solves two potential problems in virtualization environment where a PCIe
      device is assigned to a guest domain using a HW iommu such as VT-d:
      
      1) Unintentional failure caused by guest physical address programmed
         into the device's DMA that happens to match the memory address range
         of other downstream ports in the same PCIe switch.  This causes the PCI
         transaction to go to the matching downstream port instead of go to the
         root complex to get translated by VT-d as it should be.
      
      2) Malicious guest software intentionally attacks another downstream
         PCIe device by programming the DMA address into the assigned device
         that matches memory address range of the downstream PCIe port.
      
      We are in process of implementing device filtering software in KVM/XEN
      management software to allow device assignment of PCIe devices behind a PCIe
      switch only if it has ACS capability and with the P2P upstream forwarding bits
      enabled.  This patch is intended to work for both KVM and Xen environments.
      Signed-off-by: NAllen Kay <allen.m.kay@intel.com>
      Reviewed-by: NMathew Wilcox <willy@linux.intel.com>
      Reviewed-by: NChris Wright <chris@sous-sol.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      ae21ee65
  30. 10 9月, 2009 2 次提交
    • E
      PCI: Simplify hotplug mch quirk. · 0ba379ec
      Eric W. Biederman 提交于
      There is a very old quirk for the intel E7502 E7320 and E7525 memory
      controller hubs that disables usage of msi interrupts on pcie hotplug
      bridges of those devices, and disables changing the affinity of irqs.
      
      Today all we have to do to disable msi on a specific device is to set
      dev->no_msi, which is much more straightforward than the previous
      logic.
      
      The re-running of this fixup after pci hotplug happens below these
      devices is totally bogus.  All of the state we change is pure software
      state and we don't change the hardware at all.  Which means hotplug on
      the lower devices doesn't have a chance to change this state.  So we
      can safely remove the special case from the pciehp driver and the pcie
      portdriver.
      
      I suspect the special case was someone's expermental debug code that
      slipped in. Certainly it isn't mentioned in commit
      6fb8880a61510295aece04a542767161f624dffe aka BKrev:
      41966101LJ_ogfOU0m2aE6teZfQnuQ where the code first appears.
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0ba379ec
    • M
      PCI: expose function reset capability in sysfs · 711d5779
      Michael S. Tsirkin 提交于
      Some devices allow an individual function to be reset without affecting
      other functions in the same device: that's what pci_reset_function does.
      For devices that have this support, expose reset attribite in sysfs.
      
      This is useful e.g. for virtualization, where a qemu userspace
      process wants to reset the device when the guest is reset,
      to emulate machine reboot as closely as possible.
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      711d5779