1. 31 7月, 2015 1 次提交
  2. 24 1月, 2015 1 次提交
    • R
      PCI / PM: Avoid resuming PCI devices during system suspend · bac2a909
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      bac2a909
  3. 10 1月, 2015 1 次提交
    • R
      PCI: Generate uppercase hex for modalias var in uevent · 145b3fe5
      Ricardo Ribalda Delgado 提交于
      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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      CC: stable@vger.kernel.org
      145b3fe5
  4. 04 12月, 2014 1 次提交
  5. 29 10月, 2014 1 次提交
  6. 04 9月, 2014 1 次提交
  7. 20 6月, 2014 1 次提交
  8. 11 6月, 2014 2 次提交
  9. 29 5月, 2014 1 次提交
    • A
      PCI: Introduce new device binding path using pci_dev.driver_override · 782a985d
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NAlexander Graf <agraf@suse.de>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      782a985d
  10. 28 5月, 2014 1 次提交
  11. 30 4月, 2014 2 次提交
    • B
      PCI: Remove dead code · efdd4070
      Bjorn Helgaas 提交于
      "pdev" can never be NULL here, so remove the test.
      
      Found by Coverity (CID 744313).
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      efdd4070
    • B
      PCI: Fail new_id for vendor/device values already built into driver · 8895d3bc
      Bandan Das 提交于
      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: NBandan Das <bsd@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
      8895d3bc
  12. 04 3月, 2014 1 次提交
    • R
      PCI / PM: Resume runtime-suspended devices later during system suspend · 7cd0602d
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      7cd0602d
  13. 08 12月, 2013 1 次提交
  14. 26 11月, 2013 1 次提交
  15. 15 11月, 2013 1 次提交
  16. 07 11月, 2013 1 次提交
    • S
      PCI: Warn on driver probe return value greater than zero · f92d74c1
      Stephen M. Cameron 提交于
      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: NStephen M. Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      f92d74c1
  17. 08 10月, 2013 5 次提交
  18. 27 9月, 2013 2 次提交
  19. 23 8月, 2013 1 次提交
  20. 04 6月, 2013 1 次提交
  21. 03 4月, 2013 1 次提交
  22. 12 2月, 2013 2 次提交
  23. 26 1月, 2013 1 次提交
    • Y
      PCI: Skip attaching driver in device_add() · 58d9a38f
      Yinghai Lu 提交于
      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: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      58d9a38f
  24. 05 12月, 2012 1 次提交
    • H
      PCI/PM: Keep runtime PM enabled for unbound PCI devices · 967577b0
      Huang Ying 提交于
      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: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: stable@vger.kernel.org          # v3.6+
      967577b0
  25. 29 11月, 2012 2 次提交
  26. 08 11月, 2012 1 次提交
    • D
      PCI: Don't touch card regs after runtime suspend D3 · 42eca230
      Dave Airlie 提交于
      If the driver takes care of state saving, don't touch any registers on it.
      
      Optimus (dual-gpu) laptops seem to have their own form of D3cold, but
      unfortunately enter it on normal D3 transitions via the ACPI callback.
      
      So when we use runtime PM to transition to D3, the card disappears off
      the PCI bus, however we then try to access registers on it in the
      runtime suspend finish, which really doesn't work.
      
      This patch checks whether the pci state is saved and doesn't attempt to hit
      any registers after that point if it is.
      
      (Looks okay to Rafael)
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      42eca230
  27. 03 11月, 2012 1 次提交
  28. 20 9月, 2012 1 次提交
    • A
      PM: Prevent runtime suspend during system resume · 88d26136
      Alan Stern 提交于
      This patch (as1591) moves the pm_runtime_get_noresume() and
      pm_runtime_put_sync() calls from __device_suspend() and
      device_resume() to device_prepare() and device_complete() in the PM
      core.
      
      The reason for doing this is to make sure that parent devices remain
      at full power (i.e., don't go into runtime suspend) while their
      children are being resumed from a system sleep.
      
      The PCI core already contained equivalent code to serve the same
      purpose.  The patch removes the duplicated code, since it is no longer
      needed.  One of the comments from the PCI core gets moved into the PM
      core, and a second comment is added to explain whe the _get_noresume
      and _put_sync calls are present.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      88d26136
  29. 18 9月, 2012 1 次提交
  30. 22 8月, 2012 1 次提交
  31. 16 8月, 2012 1 次提交