1What: /sys/bus/pci/drivers/.../bind 2Date: December 2003 3Contact: linux-pci@vger.kernel.org 4Description: 5 Writing a device location to this file will cause 6 the driver to attempt to bind to the device found at 7 this location. This is useful for overriding default 8 bindings. The format for the location is: DDDD:BB:DD.F. 9 That is Domain:Bus:Device.Function and is the same as 10 found in /sys/bus/pci/devices/. For example: 11 # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind 12 (Note: kernels before 2.6.28 may require echo -n). 13 14What: /sys/bus/pci/drivers/.../unbind 15Date: December 2003 16Contact: linux-pci@vger.kernel.org 17Description: 18 Writing a device location to this file will cause the 19 driver to attempt to unbind from the device found at 20 this location. This may be useful when overriding default 21 bindings. The format for the location is: DDDD:BB:DD.F. 22 That is Domain:Bus:Device.Function and is the same as 23 found in /sys/bus/pci/devices/. For example: 24 # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind 25 (Note: kernels before 2.6.28 may require echo -n). 26 27What: /sys/bus/pci/drivers/.../new_id 28Date: December 2003 29Contact: linux-pci@vger.kernel.org 30Description: 31 Writing a device ID to this file will attempt to 32 dynamically add a new device ID to a PCI device driver. 33 This may allow the driver to support more hardware than 34 was included in the driver's static device ID support 35 table at compile time. The format for the device ID is: 36 VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID, 37 Device ID, Subsystem Vendor ID, Subsystem Device ID, 38 Class, Class Mask, and Private Driver Data. The Vendor ID 39 and Device ID fields are required, the rest are optional. 40 Upon successfully adding an ID, the driver will probe 41 for the device and attempt to bind to it. For example: 42 # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id 43 44What: /sys/bus/pci/drivers/.../remove_id 45Date: February 2009 46Contact: Chris Wright <chrisw@sous-sol.org> 47Description: 48 Writing a device ID to this file will remove an ID 49 that was dynamically added via the new_id sysfs entry. 50 The format for the device ID is: 51 VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device 52 ID, Subsystem Vendor ID, Subsystem Device ID, Class, 53 and Class Mask. The Vendor ID and Device ID fields are 54 required, the rest are optional. After successfully 55 removing an ID, the driver will no longer support the 56 device. This is useful to ensure auto probing won't 57 match the driver to the device. For example: 58 # echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id 59 60What: /sys/bus/pci/rescan 61Date: January 2009 62Contact: Linux PCI developers <linux-pci@vger.kernel.org> 63Description: 64 Writing a non-zero value to this attribute will 65 force a rescan of all PCI buses in the system, and 66 re-discover previously removed devices. 67 68What: /sys/bus/pci/devices/.../msi_irqs/ 69Date: September, 2011 70Contact: Neil Horman <nhorman@tuxdriver.com> 71Description: 72 The /sys/devices/.../msi_irqs directory contains a variable set 73 of sub-directories, with each sub-directory being named after a 74 corresponding msi irq vector allocated to that device. Each 75 numbered sub-directory N contains attributes of that irq. 76 Note that this directory is not created for device drivers which 77 do not support msi irqs 78 79What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode 80Date: September 2011 81Contact: Neil Horman <nhorman@tuxdriver.com> 82Description: 83 This attribute indicates the mode that the irq vector named by 84 the parent directory is in (msi vs. msix) 85 86What: /sys/bus/pci/devices/.../remove 87Date: January 2009 88Contact: Linux PCI developers <linux-pci@vger.kernel.org> 89Description: 90 Writing a non-zero value to this attribute will 91 hot-remove the PCI device and any of its children. 92 93What: /sys/bus/pci/devices/.../pci_bus/.../rescan 94Date: May 2011 95Contact: Linux PCI developers <linux-pci@vger.kernel.org> 96Description: 97 Writing a non-zero value to this attribute will 98 force a rescan of the bus and all child buses, 99 and re-discover devices removed earlier from this 100 part of the device tree. 101 102What: /sys/bus/pci/devices/.../rescan 103Date: January 2009 104Contact: Linux PCI developers <linux-pci@vger.kernel.org> 105Description: 106 Writing a non-zero value to this attribute will 107 force a rescan of the device's parent bus and all 108 child buses, and re-discover devices removed earlier 109 from this part of the device tree. 110 111What: /sys/bus/pci/devices/.../reset 112Date: July 2009 113Contact: Michael S. Tsirkin <mst@redhat.com> 114Description: 115 Some devices allow an individual function to be reset 116 without affecting other functions in the same device. 117 For devices that have this support, a file named reset 118 will be present in sysfs. Writing 1 to this file 119 will perform reset. 120 121What: /sys/bus/pci/devices/.../vpd 122Date: February 2008 123Contact: Ben Hutchings <bhutchings@solarflare.com> 124Description: 125 A file named vpd in a device directory will be a 126 binary file containing the Vital Product Data for the 127 device. It should follow the VPD format defined in 128 PCI Specification 2.1 or 2.2, but users should consider 129 that some devices may have malformatted data. If the 130 underlying VPD has a writable section then the 131 corresponding section of this file will be writable. 132 133What: /sys/bus/pci/devices/.../virtfnN 134Date: March 2009 135Contact: Yu Zhao <yu.zhao@intel.com> 136Description: 137 This symbolic link appears when hardware supports the SR-IOV 138 capability and the Physical Function driver has enabled it. 139 The symbolic link points to the PCI device sysfs entry of the 140 Virtual Function whose index is N (0...MaxVFs-1). 141 142What: /sys/bus/pci/devices/.../dep_link 143Date: March 2009 144Contact: Yu Zhao <yu.zhao@intel.com> 145Description: 146 This symbolic link appears when hardware supports the SR-IOV 147 capability and the Physical Function driver has enabled it, 148 and this device has vendor specific dependencies with others. 149 The symbolic link points to the PCI device sysfs entry of 150 Physical Function this device depends on. 151 152What: /sys/bus/pci/devices/.../physfn 153Date: March 2009 154Contact: Yu Zhao <yu.zhao@intel.com> 155Description: 156 This symbolic link appears when a device is a Virtual Function. 157 The symbolic link points to the PCI device sysfs entry of the 158 Physical Function this device associates with. 159 160What: /sys/bus/pci/slots/.../module 161Date: June 2009 162Contact: linux-pci@vger.kernel.org 163Description: 164 This symbolic link points to the PCI hotplug controller driver 165 module that manages the hotplug slot. 166 167What: /sys/bus/pci/devices/.../label 168Date: July 2010 169Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com 170Description: 171 Reading this attribute will provide the firmware 172 given name (SMBIOS type 41 string or ACPI _DSM string) of 173 the PCI device. The attribute will be created only 174 if the firmware has given a name to the PCI device. 175 ACPI _DSM string name will be given priority if the 176 system firmware provides SMBIOS type 41 string also. 177Users: 178 Userspace applications interested in knowing the 179 firmware assigned name of the PCI device. 180 181What: /sys/bus/pci/devices/.../index 182Date: July 2010 183Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com 184Description: 185 Reading this attribute will provide the firmware 186 given instance (SMBIOS type 41 device type instance) of the 187 PCI device. The attribute will be created only if the firmware 188 has given an instance number to the PCI device. 189Users: 190 Userspace applications interested in knowing the 191 firmware assigned device type instance of the PCI 192 device that can help in understanding the firmware 193 intended order of the PCI device. 194 195What: /sys/bus/pci/devices/.../acpi_index 196Date: July 2010 197Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com 198Description: 199 Reading this attribute will provide the firmware 200 given instance (ACPI _DSM instance number) of the PCI device. 201 The attribute will be created only if the firmware has given 202 an instance number to the PCI device. ACPI _DSM instance number 203 will be given priority if the system firmware provides SMBIOS 204 type 41 device type instance also. 205Users: 206 Userspace applications interested in knowing the 207 firmware assigned instance number of the PCI 208 device that can help in understanding the firmware 209 intended order of the PCI device. 210 211What: /sys/bus/pci/devices/.../d3cold_allowed 212Date: July 2012 213Contact: Huang Ying <ying.huang@intel.com> 214Description: 215 d3cold_allowed is bit to control whether the corresponding PCI 216 device can be put into D3Cold state. If it is cleared, the 217 device will never be put into D3Cold state. If it is set, the 218 device may be put into D3Cold state if other requirements are 219 satisfied too. Reading this attribute will show the current 220 value of d3cold_allowed bit. Writing this attribute will set 221 the value of d3cold_allowed bit. 222 223What: /sys/bus/pci/devices/.../sriov_totalvfs 224Date: November 2012 225Contact: Donald Dutile <ddutile@redhat.com> 226Description: 227 This file appears when a physical PCIe device supports SR-IOV. 228 Userspace applications can read this file to determine the 229 maximum number of Virtual Functions (VFs) a PCIe physical 230 function (PF) can support. Typically, this is the value reported 231 in the PF's SR-IOV extended capability structure's TotalVFs 232 element. Drivers have the ability at probe time to reduce the 233 value read from this file via the pci_sriov_set_totalvfs() 234 function. 235 236What: /sys/bus/pci/devices/.../sriov_numvfs 237Date: November 2012 238Contact: Donald Dutile <ddutile@redhat.com> 239Description: 240 This file appears when a physical PCIe device supports SR-IOV. 241 Userspace applications can read and write to this file to 242 determine and control the enablement or disablement of Virtual 243 Functions (VFs) on the physical function (PF). A read of this 244 file will return the number of VFs that are enabled on this PF. 245 A number written to this file will enable the specified 246 number of VFs. A userspace application would typically read the 247 file and check that the value is zero, and then write the number 248 of VFs that should be enabled on the PF; the value written 249 should be less than or equal to the value in the sriov_totalvfs 250 file. A userspace application wanting to disable the VFs would 251 write a zero to this file. The core ensures that valid values 252 are written to this file, and returns errors when values are not 253 valid. For example, writing a 2 to this file when sriov_numvfs 254 is not 0 and not 2 already will return an error. Writing a 10 255 when the value of sriov_totalvfs is 8 will return an error. 256