1. 12 3月, 2016 3 次提交
  2. 09 1月, 2016 1 次提交
  3. 11 12月, 2015 1 次提交
  4. 25 11月, 2015 1 次提交
  5. 08 10月, 2015 1 次提交
  6. 25 2月, 2015 1 次提交
  7. 04 12月, 2014 1 次提交
  8. 08 11月, 2014 1 次提交
  9. 07 11月, 2014 1 次提交
    • P
      PCI: Allow numa_node override via sysfs · 63692df1
      Prarit Bhargava 提交于
      NUMA systems with ACPI normally describe the physical topology via _PXM
      methods.  But many BIOSes don't implement _PXM, which leaves the kernel
      with no way to discover the device topology, which reduces performance
      because we can't put memory and processes close to the device.
      
      The NUMA node of a PCI device is already exported in the sysfs "numa_node"
      file.  Make that file writable so users can workaround the lack of _PXM
      methods in the BIOS.  For example:
      
        echo 3 > /sys/devices/pci0000:ff/0000:03:1f.3/numa_node
      
      sets the node for PCI device 0000:03:1f.3.
      
      Writing the file emits a FW_BUG warning to encourage users to request
      firmware updates.  It also taints the kernel with TAINT_FIRMWARE_WORKAROUND
      because overriding the node incorrectly can cause performance issues.
      
      [bhelgaas: changelog, documentation text]
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Myron Stowe <mstowe@redhat.com>
      CC: Alexander Ducyk <alexander.h.duyck@redhat.com>
      CC: Jiang Liu <jiang.liu@linux.intel.com>
      63692df1
  10. 31 10月, 2014 1 次提交
  11. 02 10月, 2014 1 次提交
    • Y
      PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints · 468ff15a
      Yijing Wang 提交于
      The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
      future driver requests for MSI or MSI-X.  Previously, the sysfs file
      existed for endpoints but did nothing.
      
      Add "msi_bus" support for endpoints, so an administrator can prevent the
      use of MSI and MSI-X for individual devices.
      
      Note that as for bridges, these changes only affect future driver requests
      for MSI or MSI-X, so drivers may need to be reloaded.
      
      Add documentation for the "msi_bus" sysfs file.
      
      [bhelgaas: changelog, comments, add "subordinate", add endpoint printk,
      rework bus_flags setting, make bus_flags printk unconditional]
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      468ff15a
  12. 23 9月, 2014 1 次提交
  13. 11 6月, 2014 2 次提交
  14. 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
  15. 23 5月, 2014 1 次提交
  16. 01 5月, 2014 1 次提交
  17. 08 2月, 2014 1 次提交
  18. 14 1月, 2014 2 次提交
    • R
      PCI: Add global pci_lock_rescan_remove() · 9d16947b
      Rafael J. Wysocki 提交于
      There are multiple PCI device addition and removal code paths that may be
      run concurrently with the generic PCI bus rescan and device removal that
      can be triggered via sysfs.  If that happens, it may lead to multiple
      different, potentially dangerous race conditions.
      
      The most straightforward way to address those problems is to run
      the code in question under the same lock that is used by the
      generic rescan/remove code in pci-sysfs.c.  To prepare for those
      changes, move the definition of the global PCI remove/rescan lock
      to probe.c and provide global wrappers, pci_lock_rescan_remove()
      and pci_unlock_rescan_remove(), allowing drivers to manipulate
      that lock.  Also provide pci_stop_and_remove_bus_device_locked()
      for the callers of pci_stop_and_remove_bus_device() who only need
      to hold the rescan/remove lock around it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      9d16947b
    • G
      Revert "pci: use device_remove_file_self() instead of device_schedule_callback()" · 8634c422
      Greg Kroah-Hartman 提交于
      This reverts commit 6716d289.
      
      Tejun writes:
              I'm sorry but can you please revert the whole series?
              get_active() waiting while a node is deactivated has potential
              to lead to deadlock and that deactivate/reactivate interface is
              something fundamentally flawed and that cgroup will have to work
              with the remove_self() like everybody else.  IOW, I think the
              first posting was correct.
      
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: linux-pci@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8634c422
  19. 11 1月, 2014 1 次提交
  20. 15 11月, 2013 1 次提交
  21. 08 10月, 2013 4 次提交
  22. 27 9月, 2013 1 次提交
  23. 26 7月, 2013 1 次提交
  24. 06 6月, 2013 1 次提交
  25. 02 6月, 2013 1 次提交
  26. 16 4月, 2013 1 次提交
  27. 27 12月, 2012 1 次提交
  28. 29 11月, 2012 1 次提交
  29. 10 11月, 2012 5 次提交