| What: /sys/bus/pci/drivers/.../bind |
| Date: December 2003 |
| Contact: linux-pci@vger.kernel.org |
| Description: |
| Writing a device location to this file will cause |
| the driver to attempt to bind to the device found at |
| this location. This is useful for overriding default |
| bindings. The format for the location is: DDDD:BB:DD.F. |
| That is Domain:Bus:Device.Function and is the same as |
| found in /sys/bus/pci/devices/. For example: |
| # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind |
| (Note: kernels before 2.6.28 may require echo -n). |
| |
| What: /sys/bus/pci/drivers/.../unbind |
| Date: December 2003 |
| Contact: linux-pci@vger.kernel.org |
| Description: |
| Writing a device location to this file will cause the |
| driver to attempt to unbind from the device found at |
| this location. This may be useful when overriding default |
| bindings. The format for the location is: DDDD:BB:DD.F. |
| That is Domain:Bus:Device.Function and is the same as |
| found in /sys/bus/pci/devices/. For example: |
| # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind |
| (Note: kernels before 2.6.28 may require echo -n). |
| |
| What: /sys/bus/pci/drivers/.../new_id |
| Date: December 2003 |
| Contact: linux-pci@vger.kernel.org |
| Description: |
| Writing a device ID to this file will attempt to |
| dynamically add a new device ID to a PCI device driver. |
| This may allow the driver to support more hardware than |
| was included in the driver's static device ID support |
| table at compile time. The format for the device ID is: |
| VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID, |
| Device ID, Subsystem Vendor ID, Subsystem Device ID, |
| Class, Class Mask, and Private Driver Data. The Vendor ID |
| and Device ID fields are required, the rest are optional. |
| Upon successfully adding an ID, the driver will probe |
| for the device and attempt to bind to it. For example: |
| # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id |
| |
| What: /sys/bus/pci/drivers/.../remove_id |
| Date: February 2009 |
| Contact: Chris Wright <chrisw@sous-sol.org> |
| Description: |
| Writing a device ID to this file will remove an ID |
| that was dynamically added via the new_id sysfs entry. |
| The format for the device ID is: |
| VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device |
| ID, Subsystem Vendor ID, Subsystem Device ID, Class, |
| and Class Mask. The Vendor ID and Device ID fields are |
| required, the rest are optional. After successfully |
| removing an ID, the driver will no longer support the |
| device. This is useful to ensure auto probing won't |
| match the driver to the device. For example: |
| # echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id |
| |
| What: /sys/bus/pci/rescan |
| Date: January 2009 |
| Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
| Description: |
| Writing a non-zero value to this attribute will |
| force a rescan of all PCI buses in the system, and |
| re-discover previously removed devices. |
| |
| What: /sys/bus/pci/devices/.../msi_bus |
| Date: September 2014 |
| Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
| Description: |
| Writing a zero value to this attribute disallows MSI and |
| MSI-X for any future drivers of the device. If the device |
| is a bridge, MSI and MSI-X will be disallowed for future |
| drivers of all child devices under the bridge. Drivers |
| must be reloaded for the new setting to take effect. |
| |
| What: /sys/bus/pci/devices/.../msi_irqs/ |
| Date: September, 2011 |
| Contact: Neil Horman <nhorman@tuxdriver.com> |
| Description: |
| The /sys/devices/.../msi_irqs directory contains a variable set |
| of files, with each file being named after a corresponding msi |
| irq vector allocated to that device. |
| |
| What: /sys/bus/pci/devices/.../msi_irqs/<N> |
| Date: September 2011 |
| Contact: Neil Horman <nhorman@tuxdriver.com> |
| Description: |
| This attribute indicates the mode that the irq vector named by |
| the file is in (msi vs. msix) |
| |
| What: /sys/bus/pci/devices/.../remove |
| Date: January 2009 |
| Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
| Description: |
| Writing a non-zero value to this attribute will |
| hot-remove the PCI device and any of its children. |
| |
| What: /sys/bus/pci/devices/.../pci_bus/.../rescan |
| Date: May 2011 |
| Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
| Description: |
| Writing a non-zero value to this attribute will |
| force a rescan of the bus and all child buses, |
| and re-discover devices removed earlier from this |
| part of the device tree. |
| |
| What: /sys/bus/pci/devices/.../rescan |
| Date: January 2009 |
| Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
| Description: |
| Writing a non-zero value to this attribute will |
| force a rescan of the device's parent bus and all |
| child buses, and re-discover devices removed earlier |
| from this part of the device tree. |
| |
| What: /sys/bus/pci/devices/.../reset |
| Date: July 2009 |
| Contact: Michael S. Tsirkin <mst@redhat.com> |
| Description: |
| Some devices allow an individual function to be reset |
| without affecting other functions in the same device. |
| For devices that have this support, a file named reset |
| will be present in sysfs. Writing 1 to this file |
| will perform reset. |
| |
| What: /sys/bus/pci/devices/.../vpd |
| Date: February 2008 |
| Contact: Ben Hutchings <bwh@kernel.org> |
| Description: |
| A file named vpd in a device directory will be a |
| binary file containing the Vital Product Data for the |
| device. It should follow the VPD format defined in |
| PCI Specification 2.1 or 2.2, but users should consider |
| that some devices may have malformatted data. If the |
| underlying VPD has a writable section then the |
| corresponding section of this file will be writable. |
| |
| What: /sys/bus/pci/devices/.../virtfnN |
| Date: March 2009 |
| Contact: Yu Zhao <yu.zhao@intel.com> |
| Description: |
| This symbolic link appears when hardware supports the SR-IOV |
| capability and the Physical Function driver has enabled it. |
| The symbolic link points to the PCI device sysfs entry of the |
| Virtual Function whose index is N (0...MaxVFs-1). |
| |
| What: /sys/bus/pci/devices/.../dep_link |
| Date: March 2009 |
| Contact: Yu Zhao <yu.zhao@intel.com> |
| Description: |
| This symbolic link appears when hardware supports the SR-IOV |
| capability and the Physical Function driver has enabled it, |
| and this device has vendor specific dependencies with others. |
| The symbolic link points to the PCI device sysfs entry of |
| Physical Function this device depends on. |
| |
| What: /sys/bus/pci/devices/.../physfn |
| Date: March 2009 |
| Contact: Yu Zhao <yu.zhao@intel.com> |
| Description: |
| This symbolic link appears when a device is a Virtual Function. |
| The symbolic link points to the PCI device sysfs entry of the |
| Physical Function this device associates with. |
| |
| What: /sys/bus/pci/slots/.../module |
| Date: June 2009 |
| Contact: linux-pci@vger.kernel.org |
| Description: |
| This symbolic link points to the PCI hotplug controller driver |
| module that manages the hotplug slot. |
| |
| What: /sys/bus/pci/devices/.../label |
| Date: July 2010 |
| Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com |
| Description: |
| Reading this attribute will provide the firmware |
| given name (SMBIOS type 41 string or ACPI _DSM string) of |
| the PCI device. The attribute will be created only |
| if the firmware has given a name to the PCI device. |
| ACPI _DSM string name will be given priority if the |
| system firmware provides SMBIOS type 41 string also. |
| Users: |
| Userspace applications interested in knowing the |
| firmware assigned name of the PCI device. |
| |
| What: /sys/bus/pci/devices/.../index |
| Date: July 2010 |
| Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com |
| Description: |
| Reading this attribute will provide the firmware |
| given instance (SMBIOS type 41 device type instance) of the |
| PCI device. The attribute will be created only if the firmware |
| has given an instance number to the PCI device. |
| Users: |
| Userspace applications interested in knowing the |
| firmware assigned device type instance of the PCI |
| device that can help in understanding the firmware |
| intended order of the PCI device. |
| |
| What: /sys/bus/pci/devices/.../acpi_index |
| Date: July 2010 |
| Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com |
| Description: |
| Reading this attribute will provide the firmware |
| given instance (ACPI _DSM instance number) of the PCI device. |
| The attribute will be created only if the firmware has given |
| an instance number to the PCI device. ACPI _DSM instance number |
| will be given priority if the system firmware provides SMBIOS |
| type 41 device type instance also. |
| Users: |
| Userspace applications interested in knowing the |
| firmware assigned instance number of the PCI |
| device that can help in understanding the firmware |
| intended order of the PCI device. |
| |
| What: /sys/bus/pci/devices/.../d3cold_allowed |
| Date: July 2012 |
| Contact: Huang Ying <ying.huang@intel.com> |
| Description: |
| d3cold_allowed is bit to control whether the corresponding PCI |
| device can be put into D3Cold state. If it is cleared, the |
| device will never be put into D3Cold state. If it is set, the |
| device may be put into D3Cold state if other requirements are |
| satisfied too. Reading this attribute will show the current |
| value of d3cold_allowed bit. Writing this attribute will set |
| the value of d3cold_allowed bit. |
| |
| What: /sys/bus/pci/devices/.../sriov_totalvfs |
| Date: November 2012 |
| Contact: Donald Dutile <ddutile@redhat.com> |
| Description: |
| This file appears when a physical PCIe device supports SR-IOV. |
| Userspace applications can read this file to determine the |
| maximum number of Virtual Functions (VFs) a PCIe physical |
| function (PF) can support. Typically, this is the value reported |
| in the PF's SR-IOV extended capability structure's TotalVFs |
| element. Drivers have the ability at probe time to reduce the |
| value read from this file via the pci_sriov_set_totalvfs() |
| function. |
| |
| What: /sys/bus/pci/devices/.../sriov_numvfs |
| Date: November 2012 |
| Contact: Donald Dutile <ddutile@redhat.com> |
| Description: |
| This file appears when a physical PCIe device supports SR-IOV. |
| Userspace applications can read and write to this file to |
| determine and control the enablement or disablement of Virtual |
| Functions (VFs) on the physical function (PF). A read of this |
| file will return the number of VFs that are enabled on this PF. |
| A number written to this file will enable the specified |
| number of VFs. A userspace application would typically read the |
| file and check that the value is zero, and then write the number |
| of VFs that should be enabled on the PF; the value written |
| should be less than or equal to the value in the sriov_totalvfs |
| file. A userspace application wanting to disable the VFs would |
| write a zero to this file. The core ensures that valid values |
| are written to this file, and returns errors when values are not |
| valid. For example, writing a 2 to this file when sriov_numvfs |
| is not 0 and not 2 already will return an error. Writing a 10 |
| when the value of sriov_totalvfs is 8 will return an error. |
| |
| What: /sys/bus/pci/devices/.../driver_override |
| Date: April 2014 |
| Contact: Alex Williamson <alex.williamson@redhat.com> |
| Description: |
| This file allows the driver for a device to be specified which |
| will override standard static and dynamic ID matching. When |
| specified, only a driver with a name matching the value written |
| to driver_override will have an opportunity to bind to the |
| device. The override is specified by writing a string to the |
| driver_override file (echo pci-stub > driver_override) and |
| may be cleared with an empty string (echo > driver_override). |
| This returns the device to standard matching rules binding. |
| Writing to driver_override does not automatically unbind the |
| device from its current driver or make any attempt to |
| automatically load the specified driver. If no driver with a |
| matching name is currently loaded in the kernel, the device |
| will not bind to any driver. This also allows devices to |
| opt-out of driver binding using a driver_override name such as |
| "none". Only a single driver may be specified in the override, |
| there is no support for parsing delimiters. |
| |
| What: /sys/bus/pci/devices/.../numa_node |
| Date: Oct 2014 |
| Contact: Prarit Bhargava <prarit@redhat.com> |
| Description: |
| This file contains the NUMA node to which the PCI device is |
| attached, or -1 if the node is unknown. The initial value |
| comes from an ACPI _PXM method or a similar firmware |
| source. If that is missing or incorrect, this file can be |
| written to override the node. In that case, please report |
| a firmware bug to the system vendor. Writing to this file |
| taints the kernel with TAINT_FIRMWARE_WORKAROUND, which |
| reduces the supportability of your system. |
| |
| What: /sys/bus/pci/devices/.../revision |
| Date: November 2016 |
| Contact: Emil Velikov <emil.l.velikov@gmail.com> |
| Description: |
| This file contains the revision field of the PCI device. |
| The value comes from device config space. The file is read only. |
| |
| What: /sys/bus/pci/devices/.../sriov_drivers_autoprobe |
| Date: April 2017 |
| Contact: Bodong Wang<bodong@mellanox.com> |
| Description: |
| This file is associated with the PF of a device that |
| supports SR-IOV. It determines whether newly-enabled VFs |
| are immediately bound to a driver. It initially contains |
| 1, which means the kernel automatically binds VFs to a |
| compatible driver immediately after they are enabled. If |
| an application writes 0 to the file before enabling VFs, |
| the kernel will not bind VFs to a driver. |
| |
| A typical use case is to write 0 to this file, then enable |
| VFs, then assign the newly-created VFs to virtual machines. |
| Note that changing this file does not affect already- |
| enabled VFs. In this scenario, the user must first disable |
| the VFs, write 0 to sriov_drivers_autoprobe, then re-enable |
| the VFs. |
| |
| This is similar to /sys/bus/pci/drivers_autoprobe, but |
| affects only the VFs associated with a specific PF. |