1. 13 Jun, 2016 1 commit
    • Mika Westerberg's avatar
      PCI: Put PCIe ports into D3 during suspend · 9d26d3a8
      Mika Westerberg authored
      Currently the Linux PCI core does not touch power state of PCI bridges and
      PCIe ports when system suspend is entered.  Leaving them in D0 consumes
      power unnecessarily and may prevent the CPU from entering deeper C-states.
      
      With recent PCIe hardware we can power down the ports to save power given
      that we take into account few restrictions:
      
        - The PCIe port hardware is recent enough, starting from 2015.
      
        - Devices connected to PCIe ports are effectively in D3cold once the port
          is transitioned to D3 (the config space is not accessible anymore and
          the link may be powered down).
      
        - Devices behind the PCIe port need to be allowed to transition to D3cold
          and back.  There is a way both drivers and userspace can forbid this.
      
        - If the device behind the PCIe port is capable of waking the system it
          needs to be able to do so from D3cold.
      
      This patch adds a new flag to struct pci_device called 'bridge_d3'.  This
      flag is set and cleared by the PCI core whenever there is a change in power
      management state of any of the devices behind the PCIe port.  When system
      later on is suspended we only need to check this flag and if it is true
      transition the port to D3 otherwise we leave it in D0.
      
      Also provide override mechanism via command line parameter
      "pcie_port_pm=[off|force]" that can be used to disable or enable the
      feature regardless of the BIOS manufacturing date.
      Tested-by: 's avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: 's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d26d3a8
  2. 02 Dec, 2015 1 commit
  3. 13 Oct, 2015 2 commits
    • Rafael J. Wysocki's avatar
      PM / PCI / ACPI: Kick devices that might have been reset by firmware · 58a1fbbb
      Rafael J. Wysocki authored
      There is a concern that if the platform firmware was involved in
      the system resume that's being completed,  some devices might have
      been reset by it and if those devices had the power.direct_complete
      flag set during the preceding suspend transition, they may stay
      in a reset-power-on state indefinitely (until they are runtime-resumed
      and then suspended again).  That may not be a big deal from the
      individual device's perspective, but if the system is an SoC, it may
      be prevented from entering deep SoC-wide low-power states on idle
      because of that.
      
      The devices that are most likely to be affected by this issue are
      PCI devices and ACPI-enumerated devices using the general ACPI PM
      domain, so to prevent it from happening for those devices, force a
      runtime resume for them if they have their power.direct_complete
      flags set and the platform firmware was involved in the resume
      transition currently in progress.
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      58a1fbbb
    • Rafael J. Wysocki's avatar
      PM / sleep: Drop pm_request_idle() from pm_generic_complete() · c2df86ea
      Rafael J. Wysocki authored
      The pm_request_idle() in pm_generic_complete() is pointless as it is
      called with the runtime PM usage counter different from zero (bumped
      up by the core during the prepare phase of system suspend) and the
      core calls pm_runtime_put() for all devices after executing their
      complete callbacks, so drop it.
      
      This allows the PCI PM layer to use pm_generic_complete() too.
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: 's avatarUlf Hansson <ulf.hansson@linaro.org>
      c2df86ea
  4. 12 Oct, 2015 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: Avoid resuming more devices during system suspend · 2cef548a
      Rafael J. Wysocki authored
      Commit bac2a909 (PCI / PM: Avoid resuming PCI devices during
      system suspend) introduced a mechanism by which some PCI devices that
      were runtime-suspended at the system suspend time might be left in
      that state for the duration of the system suspend-resume cycle.
      However, it overlooked devices that were marked as capable of waking
      up the system just because PME support was detected in their PCI
      config space.
      
      Namely, in that case, device_can_wakeup(dev) returns 'true' for the
      device and if the device is not configured for system wakeup,
      device_may_wakeup(dev) returns 'false' and it will be resumed during
      system suspend even though configuring it for system wakeup may not
      really make sense at all.
      
      To avoid this problem, simply disable PME for PCI devices that have
      not been configured for system wakeup and are runtime-suspended at
      the system suspend time for the duration of the suspend-resume cycle.
      
      If the device is in D3cold, its config space is not available and it
      shouldn't be written to, but that's only possible if the device
      has platform PM support and the platform code is responsible for
      checking whether or not the device's configuration is suitable for
      system suspend in that case.
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2cef548a
  5. 24 Sep, 2015 1 commit
  6. 18 Sep, 2015 1 commit
  7. 10 Sep, 2015 1 commit
    • Dave Young's avatar
      kexec: split kexec_load syscall from kexec core code · 2965faa5
      Dave Young authored
      There are two kexec load syscalls, kexec_load another and kexec_file_load.
       kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
      split kexec_load syscall code to kernel/kexec.c.
      
      And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
      use kexec_file_load only, or vice verse.
      
      The original requirement is from Ted Ts'o, he want kexec kernel signature
      being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
      kexec_load syscall can bypass the checking.
      
      Vivek Goyal proposed to create a common kconfig option so user can compile
      in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
      KEXEC_CORE so that old config files still work.
      
      Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
      architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
      KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
      kexec_load syscall.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: 's avatarDave Young <dyoung@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Petr Tesarik <ptesarik@suse.cz>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      2965faa5
  8. 30 Jul, 2015 1 commit
  9. 23 Jan, 2015 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: Avoid resuming PCI devices during system suspend · bac2a909
      Rafael J. Wysocki authored
      Commit f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM
      domain during system suspend) modified the ACPI PM domain's system
      suspend callbacks to allow devices attached to it to be left in the
      runtime-suspended state during system suspend so as to optimize
      the suspend process.
      
      This was based on the general mechanism introduced by commit
      aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended
      devices unnecessarily).
      
      Extend that approach to PCI devices by modifying the PCI bus type's
      ->prepare callback to return 1 for devices that are runtime-suspended
      when it is being executed and that are in a suitable power state and
      need not be resumed going forward.
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      bac2a909
  10. 09 Jan, 2015 1 commit
    • Ricardo Ribalda Delgado's avatar
      PCI: Generate uppercase hex for modalias var in uevent · 145b3fe5
      Ricardo Ribalda Delgado authored
      Some implementations of modprobe fail to load the driver for a PCI device
      automatically because the "interface" part of the modalias from the kernel
      is lowercase, and the modalias from file2alias is uppercase.
      
      The "interface" is the low-order byte of the Class Code, defined in PCI
      r3.0, Appendix D.  Most interface types defined in the spec do not use
      alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
      20h, etc. are unaffected.
      
      Print the "interface" byte of the Class Code in uppercase hex, as we
      already do for the Vendor ID, Device ID, Class, etc.
      
      Commit 89ec3dcf ("PCI: Generate uppercase hex for modalias interface
      class") fixed only half of the problem.  Some udev implementations rely on
      the uevent file and not the modalias file.
      
      Fixes: d1ded203 ("PCI: add MODALIAS to hotplug event for pci devices")
      Fixes: 89ec3dcf ("PCI: Generate uppercase hex for modalias interface class")
      Signed-off-by: 's avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      CC: stable@vger.kernel.org
      145b3fe5
  11. 03 Dec, 2014 1 commit
  12. 29 Oct, 2014 1 commit
  13. 03 Sep, 2014 1 commit
  14. 19 Jun, 2014 1 commit
  15. 10 Jun, 2014 2 commits
  16. 28 May, 2014 1 commit
    • Alex Williamson's avatar
      PCI: Introduce new device binding path using pci_dev.driver_override · 782a985d
      Alex Williamson authored
      The driver_override field allows us to specify the driver for a device
      rather than relying on the driver to provide a positive match of the
      device.  This shortcuts the existing process of looking up the vendor and
      device ID, adding them to the driver new_id, binding the device, then
      removing the ID, but it also provides a couple advantages.
      
      First, the above existing process allows the driver to bind to any device
      matching the new_id for the window where it's enabled.  This is often not
      desired, such as the case of trying to bind a single device to a meta
      driver like pci-stub or vfio-pci.  Using driver_override we can do this
      deterministically using:
      
        echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
        echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
        echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
      
      Previously we could not invoke drivers_probe after adding a device to
      new_id for a driver as we get non-deterministic behavior whether the driver
      we intend or the standard driver will claim the device.  Now it becomes a
      deterministic process, only the driver matching driver_override will probe
      the device.
      
      To return the device to the standard driver, we simply clear the
      driver_override and reprobe the device:
      
        echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
        echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
        echo 0000:03:00.0 > /sys/bus/pci/drivers_probe
      
      Another advantage to this approach is that we can specify a driver override
      to force a specific binding or prevent any binding.  For instance when an
      IOMMU group is exposed to userspace through VFIO we require that all
      devices within that group are owned by VFIO.  However, devices can be
      hot-added into an IOMMU group, in which case we want to prevent the device
      from binding to any driver (override driver = "none") or perhaps have it
      automatically bind to vfio-pci.  With driver_override it's a simple matter
      for this field to be set internally when the device is first discovered to
      prevent driver matches.
      Signed-off-by: 's avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: 's avatarAlexander Graf <agraf@suse.de>
      Acked-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      782a985d
  17. 27 May, 2014 1 commit
  18. 29 Apr, 2014 2 commits
    • Bjorn Helgaas's avatar
      PCI: Remove dead code · efdd4070
      Bjorn Helgaas authored
      "pdev" can never be NULL here, so remove the test.
      
      Found by Coverity (CID 744313).
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      efdd4070
    • Bandan Das's avatar
      PCI: Fail new_id for vendor/device values already built into driver · 8895d3bc
      Bandan Das authored
      While using the sysfs new_id interface, the user can unintentionally feed
      incorrect values if the driver static table has a matching entry.  This is
      possible since only the device and vendor fields are mandatory and the rest
      are optional.  As a result, store_new_id() will fill in default values that
      are then passed on to the driver and can have unintended consequences.
      
      As an example, consider the ixgbe driver and the 82599EB network card:
      
        echo "8086 10fb" > /sys/bus/pci/drivers/ixgbe/new_id
      
      This will pass a pci_device_id with driver_data = 0 to ixgbe_probe(), which
      uses that zero to index a table of card operations.  The zeroth entry of
      the table does *not* correspond to the 82599 operations.
      
      This change returns an error if the user attempts to add a dynid for a
      vendor/device combination for which a static entry already exists.
      However, if the user intentionally wants a different set of values, she
      must provide all the 7 fields and that will be accepted.
      
      [bhelgaas: drop KVM text since the problem isn't KVM-specific]
      Signed-off-by: 's avatarBandan Das <bsd@redhat.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: 's avatarAlex Williamson <alex.williamson@redhat.com>
      8895d3bc
  19. 03 Mar, 2014 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: Resume runtime-suspended devices later during system suspend · 7cd0602d
      Rafael J. Wysocki authored
      Runtime-suspended devices are resumed during system suspend by
      pci_pm_prepare() for two reasons: First, because they may need
      to be reprogrammed in order to change their wakeup settings and,
      second, because they may need to be operatonal for their children
      to be successfully suspended.  That is a problem, though, if there
      are many runtime-suspended devices that need to be resumed this
      way during system suspend, because the .prepare() PM callbacks of
      devices are executed sequentially and the times taken by them
      accumulate, which may increase the total system suspend time quite
      a bit.
      
      For this reason, move the resume of runtime-suspended devices up
      to the next phase of device suspend (during system suspend), except
      for the ones that have power.ignore_children set.  The exception is
      made, because the devices with power.ignore_children set may still
      be necessary for their children to be successfully suspended (during
      system suspend) and they won't be resumed automatically as a result
      of the runtime resume of their children.
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      7cd0602d
  20. 07 Dec, 2013 1 commit
  21. 25 Nov, 2013 1 commit
  22. 14 Nov, 2013 1 commit
  23. 06 Nov, 2013 1 commit
    • Stephen M. Cameron's avatar
      PCI: Warn on driver probe return value greater than zero · f92d74c1
      Stephen M. Cameron authored
      Ages ago, drivers could return values greater than zero from their probe
      function and this would be regarded as success.
      
      But after f3ec4f87 ("PCI: change device runtime PM settings for probe
      and remove") and 967577b0 ("PCI/PM: Keep runtime PM enabled for unbound
      PCI devices"), we set dev->driver to NULL if the driver's probe function
      returns a value greater than zero.
      
      __pci_device_probe() treats this as success, and drivers can still mostly
      work even with dev->driver == NULL, but PCI power management doesn't work,
      and we don't call the driver's remove function on rmmod.
      
      To help catch these driver problems, issue a warning in this case.
      
      [bhelgaas: changelog]
      Signed-off-by: 's avatarStephen M. Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      f92d74c1
  24. 07 Oct, 2013 5 commits
  25. 26 Sep, 2013 2 commits
  26. 22 Aug, 2013 1 commit
  27. 03 Jun, 2013 1 commit
  28. 02 Apr, 2013 1 commit
  29. 11 Feb, 2013 2 commits
  30. 25 Jan, 2013 1 commit
    • Yinghai Lu's avatar
      PCI: Skip attaching driver in device_add() · 58d9a38f
      Yinghai Lu authored
      We want to add PCI devices to the device tree as early as possible but
      delay attaching drivers.
      
      device_add() adds a device to the device hierarchy and (via
      device_attach()) attaches a matching driver and calls its .probe() method.
      We want to separate adding the device to the hierarchy from attaching the
      driver.
      
      This patch does that by adding "match_driver" in struct pci_dev.  When
      false, we return failure from pci_bus_match(), which makes device_attach()
      believe there's no matching driver.
      
      Later, we set "match_driver = true" and call device_attach() again, which
      now attaches the driver and calls its .probe() method.
      
      [bhelgaas: changelog, explicitly init dev->match_driver,
      fold device_attach() call into pci_bus_add_device()]
      Signed-off-by: 's avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      58d9a38f
  31. 04 Dec, 2012 1 commit
    • Huang Ying's avatar
      PCI/PM: Keep runtime PM enabled for unbound PCI devices · 967577b0
      Huang Ying authored
      For unbound PCI devices, what we need is:
      
       - Always in D0 state, because some devices do not work again after
         being put into D3 by the PCI bus.
      
       - In SUSPENDED state if allowed, so that the parent devices can still
         be put into low power state.
      
      To satisfy these requirements, the runtime PM for the unbound PCI
      devices are disabled and set to SUSPENDED state.  One issue of this
      solution is that the PCI devices will be put into SUSPENDED state even
      if the SUSPENDED state is forbidden via the sysfs interface
      (.../power/control) of the device.  This is not an issue for most
      devices, because most PCI devices are not used at all if unbound.
      But there are exceptions.  For example, unbound VGA card can be used
      for display, but suspending its parents makes it stop working.
      
      To fix the issue, we keep the runtime PM enabled when the PCI devices
      are unbound.  But the runtime PM callbacks will do nothing if the PCI
      devices are unbound.  This way, we can put the PCI devices into
      SUSPENDED state without putting the PCI devices into D3 state.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48201Signed-off-by: 's avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: 's avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: stable@vger.kernel.org          # v3.6+
      967577b0