1. 30 May, 2018 1 commit
    • Rafael J. Wysocki's avatar
      PCI: Restore config space on runtime resume despite being unbound · e2b3fa0c
      Rafael J. Wysocki authored
      [ Upstream commit 5775b843 ]
      
      We leave PCI devices not bound to a driver in D0 during runtime suspend.
      But they may have a parent which is bound and can be transitioned to
      D3cold at runtime.  Once the parent goes to D3cold, the unbound child
      may go to D3cold as well.  When the child goes to D3cold, its internal
      state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost.
      
      One example are recent hybrid graphics laptops which cut power to the
      discrete GPU when the root port above it goes to ACPI power state D3.
      Users may provoke this by unbinding the GPU driver and allowing runtime
      PM on the GPU via sysfs:  The PM core will then treat the GPU as
      "suspended", which in turn allows the root port to runtime suspend,
      causing the power resources listed in its _PR3 object to be powered off.
      The GPU's BARs will be uninitialized when a driver later probes it.
      
      Another example are hybrid graphics laptops where the GPU itself (rather
      than the root port) is capable of runtime suspending to D3cold.  If the
      GPU's integrated HDA controller is not bound and the GPU's driver
      decides to runtime suspend to D3cold, the HDA controller's BARs will be
      uninitialized when a driver later probes it.
      
      Fix by saving and restoring config space over a runtime suspend cycle
      even if the device is not bound.
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Tested-by: Peter Wu <peter@lekensteyn.nl>              # Nvidia Optimus
      Tested-by: Lukas Wunner <lukas@wunner.de>              # MacBook Pro
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      [lukas: add commit message, bikeshed code comments for clarity]
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.deSigned-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2b3fa0c
  2. 29 Dec, 2017 1 commit
  3. 18 Aug, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      PCI/IB: add support for pci driver attribute groups · 92d50fc1
      Greg Kroah-Hartman authored
      Some drivers (specifically the nes IB driver), want to create a lot of
      sysfs driver attributes.  Instead of open-coding the creation and
      removal of these files (and getting it wrong btw), it's a better idea to
      let the driver core handle all of this logic for us.
      
      So add a new field to the pci driver structure, **groups, that allows
      pci drivers to specify an attribute group list it wishes to have created
      when it is registered with the driver core.
      
      Big bonus is now the driver doesn't race with userspace when the sysfs
      files are created vs. when the kobject is announced, so any script/tool
      that actually wanted to use these files will not have to poll waiting
      for them to show up.
      
      Cc: Faisal Latif <faisal.latif@intel.com>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      92d50fc1
  4. 01 Aug, 2017 1 commit
  5. 12 Jul, 2017 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: Restore PME Enable after config space restoration · 0ce3fcaf
      Rafael J. Wysocki authored
      Commit dc15e71e (PCI / PM: Restore PME Enable if skipping wakeup
      setup) introduced a mechanism by which the PME Enable bit can be
      restored by pci_enable_wake() if dev->wakeup_prepared is set in
      case it has been overwritten by PCI config space restoration.
      
      However, that commit overlooked the fact that on some systems (Dell
      XPS13 9360 in particular) the AML handling wakeup events checks PME
      Status and PME Enable and it won't trigger a Notify() for devices
      where those bits are not set while it is running.
      
      That happens during resume from suspend-to-idle when pci_restore_state()
      invoked by pci_pm_default_resume_early() clears PME Enable before the
      wakeup events are processed by AML, effectively causing those wakeup
      events to be ignored.
      
      Fix this issue by restoring the PME Enable configuration right after
      pci_restore_state() has been called instead of doing that in
      pci_enable_wake().
      
      Fixes: dc15e71e (PCI / PM: Restore PME Enable if skipping wakeup setup)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      0ce3fcaf
  6. 02 Jul, 2017 1 commit
    • Matthew Minter's avatar
      PCI: Add a call to pci_assign_irq() in pci_device_probe() · 30fdfb92
      Matthew Minter authored
      The pci_assign_irq() function allows assignment of an IRQ to devices during
      device enable time rather than only at boot.  Therefore call it in the
      pci_device_probe() function during the enable device code path so this
      assignment can be performed.
      
      This patch will do nothing on arches which do not set the IRQ mapping
      function pointers and is therefore currently a nop, however as support for
      these function pointers is added to arch-specific code this will cause IRQ
      assignment to migrate to device enable time allowing the new code paths to
      be used.
      Signed-off-by: default avatarMatthew Minter <matt@masarand.com>
      [lorenzo.pieralisi@arm.com: moved pci_assign_irq() call site]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      30fdfb92
  7. 30 Jun, 2017 1 commit
    • Chen Yu's avatar
      PCI/PM: Restore the status of PCI devices across hibernation · e60514bd
      Chen Yu authored
      Currently we saw a lot of "No irq handler" errors during hibernation, which
      caused the system hang finally:
      
        ata4.00: qc timeout (cmd 0xec)
        ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
        ata4.00: revalidation failed (errno=-5)
        ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
        do_IRQ: 31.151 No irq handler for vector
      
      According to above logs, there is an interrupt triggered and it is
      dispatched to CPU31 with a vector number 151, but there is no handler for
      it, thus this IRQ will not get acked and will cause an IRQ flood which
      kills the system.  To be more specific, the 31.151 is an interrupt from the
      AHCI host controller.
      
      After some investigation, the reason why this issue is triggered is because
      the thaw_noirq() function does not restore the MSI/MSI-X settings across
      hibernation.
      
      The scenario is illustrated below:
      
        1. Before hibernation, IRQ 34 is the handler for the AHCI device, which
           is bound to CPU31.
      
        2. Hibernation starts, the AHCI device is put into low power state.
      
        3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to
           the last alive one - CPU0.
      
        4. After the snapshot has been created, all the nonboot CPUs are brought
           up again; IRQ 34 remains bound to CPU0.
      
        5. AHCI devices are put into D0.
      
        6. The snapshot is written to the disk.
      
      The issue is triggered in step 6.  The AHCI interrupt should be delivered
      to CPU0, however it is delivered to the original CPU31 instead, which
      causes the "No irq handler" issue.
      
      Ying Huang has provided a clue that, in step 3 it is possible that writing
      to the register might not take effect as the PCI devices have been
      suspended.
      
      In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but
      in fact it is not.  In __pci_write_msi_msg(), if the device is already in
      low power state, the low level MSI message entry will not be updated but
      cached.  During the device restore process after a normal suspend/resume,
      pci_restore_msi_state() writes the cached MSI back to the hardware.
      
      But this is not the case for hibernation.  pci_restore_msi_state() is not
      currently called in pci_pm_thaw_noirq(), although pci_save_state() has
      saved the necessary PCI cached information in pci_pm_freeze_noirq().
      
      Restore the PCI status for the device during hibernation.  Otherwise the
      status might be lost across hibernation (for example, settings for MSI,
      MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation.
      Suggested-by: default avatarYing Huang <ying.huang@intel.com>
      Suggested-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarChen Yu <yu.c.chen@intel.com>
      [bhelgaas: changelog]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable@vger.kernel.org
      Cc: Len Brown <len.brown@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: Ying Huang <ying.huang@intel.com>
      e60514bd
  8. 27 Jun, 2017 1 commit
  9. 12 Jun, 2017 1 commit
  10. 26 May, 2017 2 commits
    • Thomas Gleixner's avatar
      PCI: Replace the racy recursion prevention · 0b2c2a71
      Thomas Gleixner authored
      pci_call_probe() can called recursively when a physcial function is probed
      and the probing creates virtual functions, which are populated via
      pci_bus_add_device() which in turn can end up calling pci_call_probe()
      again.
      
      The code has an interesting way to prevent recursing into the workqueue
      code.  That's accomplished by a check whether the current task runs already
      on the numa node which is associated with the device.
      
      While that works to prevent the recursion into the workqueue code, it's
      racy versus normal execution as there is no guarantee that the node does
      not vanish after the check.
      
      There is another issue with this code. It dereferences cpumask_of_node()
      unconditionally without checking whether the node is available.
      
      Make the detection reliable by:
      
       - Mark a probed device as 'is_probed' in pci_call_probe()
       
       - Check in pci_call_probe for a virtual function. If it's a virtual
         function and the associated physical function device is marked
         'is_probed' then this is a recursive call, so the call can be invoked in
         the calling context.
      
       - Add a check whether the node is online before dereferencing it.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linux-pci@vger.kernel.org
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/20170524081548.771457199@linutronix.de
      0b2c2a71
    • Thomas Gleixner's avatar
      PCI: Use cpu_hotplug_disable() instead of get_online_cpus() · 1ddd45f8
      Thomas Gleixner authored
      Converting the hotplug locking, i.e. get_online_cpus(), to a percpu rwsem
      unearthed a circular lock dependency which was hidden from lockdep due to
      the lockdep annotation of get_online_cpus() which prevents lockdep from
      creating full dependency chains. There are several variants of this. And
      example is:
      
      Chain exists of:
      
      cpu_hotplug_lock.rw_sem --> drm_global_mutex --> &item->mutex
      
      CPU0                    CPU1
      ----                    ----
      lock(&item->mutex);
                              lock(drm_global_mutex);
                              lock(&item->mutex);
      lock(cpu_hotplug_lock.rw_sem);
      
      because there are dependencies through workqueues. The call chain is:
      
      	get_online_cpus
      	apply_workqueue_attrs
      	__alloc_workqueue_key
      	ttm_mem_global_init
      	ast_ttm_mem_global_init
      	drm_global_item_ref
      	ast_mm_init
      	ast_driver_load
      	drm_dev_register
      	drm_get_pci_dev
      	ast_pci_probe
      	local_pci_probe
      	work_for_cpu_fn
      	process_one_work
      	worker_thread
      
      This is not a problem of get_online_cpus() recursion, it's a possible
      deadlock undetected by lockdep so far.
      
      The cure is to use cpu_hotplug_disable() instead of get_online_cpus() to
      protect the PCI probing.
      
      There is a side effect to this: cpu_hotplug_disable() makes a concurrent
      cpu hotplug attempt via the sysfs interfaces fail with -EBUSY, but PCI
      probing usually happens during the boot process where no interaction is
      possible. Any later invocations are infrequent enough and concurrent
      hotplug attempts are so unlikely that the danger of user space visible
      regressions is very close to zero. Anyway, thats preferrable over a real
      deadlock.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linux-pci@vger.kernel.org
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/20170524081548.691198590@linutronix.de
      1ddd45f8
  11. 20 Apr, 2017 1 commit
  12. 09 Mar, 2017 1 commit
    • Prarit Bhargava's avatar
      PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown() · fda78d7a
      Prarit Bhargava authored
      The pci_bus_type .shutdown method, pci_device_shutdown(), is called from
      device_shutdown() in the kernel restart and shutdown paths.
      
      Previously, pci_device_shutdown() called pci_msi_shutdown() and
      pci_msix_shutdown().  This disables MSI and MSI-X, which causes the device
      to fall back to raising interrupts via INTx.  But the driver is still bound
      to the device, it doesn't know about this change, and it likely doesn't
      have an INTx handler, so these INTx interrupts cause "nobody cared"
      warnings like this:
      
        irq 16: nobody cared (try booting with the "irqpoll" option)
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1
        Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/
        ...
      
      The MSI disabling code was added by d52877c7 ("pci/irq: let
      pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI
      enabled and kdump failed because the kexeced kernel wasn't prepared to
      receive the MSI interrupts.
      
      Subsequent commits 1851617c ("PCI/MSI: Disable MSI at enumeration even
      if kernel doesn't support MSI") and  e80e7edc ("PCI/MSI: Initialize MSI
      capability for all architectures") changed the kexeced kernel to disable
      all MSIs itself so it no longer depends on the crashed kernel to clean up
      after itself.
      
      Stop disabling MSI/MSI-X in pci_device_shutdown().  This resolves the
      "nobody cared" unhandled IRQ issue above.  It also allows PCI serial
      devices, which may rely on the MSI interrupts, to continue outputting
      messages during reboot/shutdown.
      
      [bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls
      altogether]
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Alex Williamson <alex.williamson@redhat.com>
      CC: David Arcari <darcari@redhat.com>
      CC: Myron Stowe <mstowe@redhat.com>
      CC: Lukas Wunner <lukas@wunner.de>
      CC: Keith Busch <keith.busch@intel.com>
      CC: Mika Westerberg <mika.westerberg@linux.intel.com>
      fda78d7a
  13. 10 Feb, 2017 1 commit
  14. 20 Jan, 2017 1 commit
  15. 28 Sep, 2016 1 commit
    • Lukas Wunner's avatar
      PCI: Avoid unnecessary resume after direct-complete · a0d2a959
      Lukas Wunner authored
      Commit 58a1fbbb ("PM / PCI / ACPI: Kick devices that might have been
      reset by firmware") added a runtime resume for devices that were runtime
      suspended when the system entered sleep.
      
      The motivation was that devices might be in a reset-power-on state after
      waking from system sleep, so their power state as perceived by Linux
      (stored in pci_dev->current_state) would no longer reflect reality.  By
      resuming such devices, we allow them to return to a low-power state via
      autosuspend and also bring their current_state in sync with reality.
      
      However for devices that are *not* in a reset-power-on state, doing an
      unconditional resume wastes energy.  A more refined approach is called for
      which issues a runtime resume only if the power state after direct-complete
      is shallower than it was before. To achieve this, update the device's
      current_state and compare it to its pre-sleep value.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a0d2a959
  16. 09 Aug, 2016 1 commit
  17. 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: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d26d3a8
  18. 02 Dec, 2015 1 commit
  19. 14 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: default 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: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c2df86ea
  20. 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: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2cef548a
  21. 25 Sep, 2015 1 commit
  22. 18 Sep, 2015 1 commit
  23. 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: default 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2965faa5
  24. 30 Jul, 2015 1 commit
  25. 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: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      bac2a909
  26. 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: default avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      CC: stable@vger.kernel.org
      145b3fe5
  27. 03 Dec, 2014 1 commit
  28. 29 Oct, 2014 1 commit
  29. 03 Sep, 2014 1 commit
  30. 19 Jun, 2014 1 commit
  31. 11 Jun, 2014 1 commit
  32. 10 Jun, 2014 1 commit
  33. 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: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: Alexander Graf's avatarAlexander Graf <agraf@suse.de>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      782a985d
  34. 27 May, 2014 1 commit
  35. 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: default 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: default avatarBandan Das <bsd@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      8895d3bc
  36. 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: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      7cd0602d
  37. 07 Dec, 2013 1 commit