Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 10 Nov, 2012 3 commits
  3. 05 Jul, 2012 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: restore the original behavior of pci_set_power_state() · db288c9c
      Rafael J. Wysocki authored 
      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: default avatarMatthew Garrett <mjg@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      db288c9c
  5. 23 Jun, 2012 1 commit
    • Huang Ying's avatar
      PCI/PM: add PCIe runtime D3cold support · 448bd857
      Huang Ying authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Originally-by: default avatarZheng Yan <zheng.z.yan@intel.com>
Signed-off-by: default avatarHuang Ying <ying.huang@intel.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      448bd857
  7. 13 Jun, 2012 2 commits
  9. 12 Jun, 2012 1 commit
  11. 30 Apr, 2012 2 commits
  13. 24 Feb, 2012 2 commits
  15. 23 Feb, 2012 1 commit
    • Yinghai Lu's avatar
      PCI: fix memleak for pci dev removing during hotplug · f796841e
      Yinghai Lu authored 
      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: default avatarYinghai Lu <yinghai@kernel.org>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      f796841e
  17. 14 Feb, 2012 1 commit
  19. 06 Jan, 2012 2 commits
  21. 01 Aug, 2011 1 commit
  23. 08 Jul, 2011 1 commit
  25. 21 Jun, 2011 1 commit
    • Ohad Ben-Cohen's avatar
      x86/ia64: intel-iommu: move to drivers/iommu/ · 166e9278
      Ohad Ben-Cohen authored 
      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: default avatarOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: default avatarJoerg Roedel <joerg.roedel@amd.com>
      166e9278
  27. 21 May, 2011 2 commits
  29. 11 Apr, 2011 1 commit
  31. 04 Mar, 2011 1 commit
    • Narendra_K@Dell.com's avatar
      PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs · 6058989b
      Narendra_K@Dell.com authored 
      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: default avatarMatthew Garrett <mjg@redhat.com>
Signed-off-by: default avatarJordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: default avatarNarendra K <narendra_k@dell.com>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      6058989b
  33. 14 Jan, 2011 2 commits
  35. 11 Nov, 2010 1 commit
    • Martin Wilck's avatar
      PCI: fix size checks for mmap() on /proc/bus/pci files · 3b519e4e
      Martin Wilck authored 
      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: default avatarMartin Wilck <martin.wilck@ts.fujitsu.com>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      3b519e4e
  37. 18 Oct, 2010 1 commit
  39. 09 Sep, 2010 1 commit
  41. 24 Aug, 2010 1 commit
  43. 02 Aug, 2010 1 commit
    • Narendra K's avatar
      PCI: Fix warnings when CONFIG_DMI unset · b879743f
      Narendra K authored 
      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: default avatarNarendra K <narendra_k@dell.com>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b879743f
  45. 30 Jul, 2010 1 commit
  47. 18 Jul, 2010 1 commit
    • Rafael J. Wysocki's avatar
      PM: Make it possible to avoid races between wakeup and system sleep · c125e96f
      Rafael J. Wysocki authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
Acked-by: default avatarmarkgross <markgross@thegnar.org>
Reviewed-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      c125e96f
  49. 11 May, 2010 1 commit
  51. 23 Feb, 2010 4 commits
    • Rafael J. Wysocki's avatar
      PCI PM: Run-time callbacks for PCI bus type · 6cbf8214
      Rafael J. Wysocki authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      6cbf8214
    • Rafael J. Wysocki's avatar
      PCI / ACPI / PM: Platform support for PCI PME wake-up · b67ea761
      Rafael J. Wysocki authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b67ea761
    • Rafael J. Wysocki's avatar
      PCI PM: Add function for checking PME status of devices · 58ff4633
      Rafael J. Wysocki authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      58ff4633
    • Rafael J. Wysocki's avatar
      PCI: Clean up build for CONFIG_PCI_QUIRKS unset · 93177a74
      Rafael J. Wysocki authored 
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      93177a74
  53. 31 Dec, 2009 1 commit
  55. 16 Dec, 2009 1 commit
  57. 04 Nov, 2009 1 commit
    • Allen Kay's avatar
      PCI: acs p2p upsteram forwarding enabling · ae21ee65
      Allen Kay authored 
      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: default avatarAllen Kay <allen.m.kay@intel.com>
Reviewed-by: default avatarMathew Wilcox <willy@linux.intel.com>
Reviewed-by: default avatarChris Wright <chris@sous-sol.org>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      ae21ee65
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7