1. 20 4月, 2017 1 次提交
  2. 22 11月, 2016 1 次提交
  3. 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
  4. 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
  5. 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
  6. 26 4月, 2014 2 次提交
  7. 20 12月, 2013 1 次提交
  8. 04 6月, 2013 1 次提交
  9. 29 11月, 2012 1 次提交
  10. 22 8月, 2012 1 次提交
  11. 07 1月, 2012 1 次提交
  12. 06 12月, 2011 1 次提交
  13. 22 5月, 2011 1 次提交
    • Y
      PCI: add rescan to /sys/.../pci_bus/.../ · b9d320fc
      Yinghai Lu 提交于
      After remove the device from /sys, we have to rescan all or
      find out the bridge and access /sys../device/rescan there.
      
      this patch add /sys/.../pci_bus/.../rescan. So user can rescan more easy.
      that is more clean and easy to understand.
      
      like after remove 0000:c4:00.0, you can rescan 0000:c4 directly.
      
      -v2: According to Jesse, use function instead of exposing attr, so could hide
      	#ifdef in header file.
           also add code to remove rescan file in remove path.
      -v3: GregKH pointed out that we should use dev_attrs to avoid racing.
           So add pcibus_attrs and make it to be member of pcibus_attrs.
      -v4: Change name to pcibus_dev_attrs according to GregKH
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b9d320fc
  14. 05 3月, 2011 1 次提交
    • N
      PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs · 6058989b
      Narendra_K@Dell.com 提交于
      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: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NJordan Hargrave <jordan_hargrave@dell.com>
      Signed-off-by: NNarendra K <narendra_k@dell.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6058989b
  15. 31 7月, 2010 1 次提交
  16. 12 6月, 2010 1 次提交
  17. 12 5月, 2010 1 次提交
    • A
      PCI: create function symlinks in /sys/bus/pci/slots/N/ · 75568f80
      Alex Chiang 提交于
      Create convenience symlinks in sysfs, linking slots to device
      functions, and vice versa. These links make it easier for users to
      figure out which devices actually live in what slots.
      
      For example:
      
      sapphire:/sys/bus/pci/slots # ls
      1  10  2  3  4  5  6  7  8  9
      
      sapphire:/sys/bus/pci/slots # ls -l 3
      total 0
      -r--r--r-- 1 root root 65536 Aug 18 14:10 address
      lrwxrwxrwx 1 root root     0 Aug 18 14:10 function0 ->
      ../../../../devices/pci0000:23/0000:23:01.0
      lrwxrwxrwx 1 root root     0 Aug 18 14:10 function1 ->
      ../../../../devices/pci0000:23/0000:23:01.1
      
      sapphire:/sys/bus/pci/slots # ls -l 3/function0/slot
      lrwxrwxrwx 1 root root 0 Aug 18 14:13 3/function0/slot ->
      ../../../bus/pci/slots/3
      
      The original form of this patch was written by Matthew Wilcox,
      and was enhanced to include links from the sysfs slots/ directory
      pointing back at the device functions.
      
      Cc: willy@linux.intel.com
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      75568f80
  18. 10 9月, 2009 1 次提交
  19. 17 6月, 2009 1 次提交
  20. 21 3月, 2009 5 次提交
  21. 25 2月, 2009 1 次提交
  22. 21 4月, 2008 1 次提交
    • B
      PCI: Expose PCI VPD through sysfs · 94e61088
      Ben Hutchings 提交于
      Vital Product Data (VPD) may be exposed by PCI devices in several
      ways.  It is generally unsafe to read this information through the
      existing interfaces to user-land because of stateful interfaces.
      
      This adds:
      - abstract operations for VPD access (struct pci_vpd_ops)
      - VPD state information in struct pci_dev (struct pci_vpd)
      - an implementation of the VPD access method specified in PCI 2.2
        (in access.c)
      - a 'vpd' binary file in sysfs directories for PCI devices with VPD
        operations defined
      
      It adds a probe for PCI 2.2 VPD in pci_scan_device() and release of
      VPD state in pci_release_dev().
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      94e61088