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 Depends on CONFIG_HOTPLUG. 68 69What: /sys/bus/pci/devices/.../msi_irqs/ 70Date: September, 2011 71Contact: Neil Horman <nhorman@tuxdriver.com> 72Description: 73 The /sys/devices/.../msi_irqs directory contains a variable set 74 of sub-directories, with each sub-directory being named after a 75 corresponding msi irq vector allocated to that device. Each 76 numbered sub-directory N contains attributes of that irq. 77 Note that this directory is not created for device drivers which 78 do not support msi irqs 79 80What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode 81Date: September 2011 82Contact: Neil Horman <nhorman@tuxdriver.com> 83Description: 84 This attribute indicates the mode that the irq vector named by 85 the parent directory is in (msi vs. msix) 86 87What: /sys/bus/pci/devices/.../remove 88Date: January 2009 89Contact: Linux PCI developers <linux-pci@vger.kernel.org> 90Description: 91 Writing a non-zero value to this attribute will 92 hot-remove the PCI device and any of its children. 93 Depends on CONFIG_HOTPLUG. 94 95What: /sys/bus/pci/devices/.../pci_bus/.../rescan 96Date: May 2011 97Contact: Linux PCI developers <linux-pci@vger.kernel.org> 98Description: 99 Writing a non-zero value to this attribute will 100 force a rescan of the bus and all child buses, 101 and re-discover devices removed earlier from this 102 part of the device tree. Depends on CONFIG_HOTPLUG. 103 104What: /sys/bus/pci/devices/.../rescan 105Date: January 2009 106Contact: Linux PCI developers <linux-pci@vger.kernel.org> 107Description: 108 Writing a non-zero value to this attribute will 109 force a rescan of the device's parent bus and all 110 child buses, and re-discover devices removed earlier 111 from this part of the device tree. 112 Depends on CONFIG_HOTPLUG. 113 114What: /sys/bus/pci/devices/.../reset 115Date: July 2009 116Contact: Michael S. Tsirkin <mst@redhat.com> 117Description: 118 Some devices allow an individual function to be reset 119 without affecting other functions in the same device. 120 For devices that have this support, a file named reset 121 will be present in sysfs. Writing 1 to this file 122 will perform reset. 123 124What: /sys/bus/pci/devices/.../vpd 125Date: February 2008 126Contact: Ben Hutchings <bhutchings@solarflare.com> 127Description: 128 A file named vpd in a device directory will be a 129 binary file containing the Vital Product Data for the 130 device. It should follow the VPD format defined in 131 PCI Specification 2.1 or 2.2, but users should consider 132 that some devices may have malformatted data. If the 133 underlying VPD has a writable section then the 134 corresponding section of this file will be writable. 135 136What: /sys/bus/pci/devices/.../virtfnN 137Date: March 2009 138Contact: Yu Zhao <yu.zhao@intel.com> 139Description: 140 This symbolic link appears when hardware supports the SR-IOV 141 capability and the Physical Function driver has enabled it. 142 The symbolic link points to the PCI device sysfs entry of the 143 Virtual Function whose index is N (0...MaxVFs-1). 144 145What: /sys/bus/pci/devices/.../dep_link 146Date: March 2009 147Contact: Yu Zhao <yu.zhao@intel.com> 148Description: 149 This symbolic link appears when hardware supports the SR-IOV 150 capability and the Physical Function driver has enabled it, 151 and this device has vendor specific dependencies with others. 152 The symbolic link points to the PCI device sysfs entry of 153 Physical Function this device depends on. 154 155What: /sys/bus/pci/devices/.../physfn 156Date: March 2009 157Contact: Yu Zhao <yu.zhao@intel.com> 158Description: 159 This symbolic link appears when a device is a Virtual Function. 160 The symbolic link points to the PCI device sysfs entry of the 161 Physical Function this device associates with. 162 163What: /sys/bus/pci/slots/.../module 164Date: June 2009 165Contact: linux-pci@vger.kernel.org 166Description: 167 This symbolic link points to the PCI hotplug controller driver 168 module that manages the hotplug slot. 169 170What: /sys/bus/pci/devices/.../label 171Date: July 2010 172Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com 173Description: 174 Reading this attribute will provide the firmware 175 given name (SMBIOS type 41 string or ACPI _DSM string) of 176 the PCI device. The attribute will be created only 177 if the firmware has given a name to the PCI device. 178 ACPI _DSM string name will be given priority if the 179 system firmware provides SMBIOS type 41 string also. 180Users: 181 Userspace applications interested in knowing the 182 firmware assigned name of the PCI device. 183 184What: /sys/bus/pci/devices/.../index 185Date: July 2010 186Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com 187Description: 188 Reading this attribute will provide the firmware 189 given instance (SMBIOS type 41 device type instance) of the 190 PCI device. The attribute will be created only if the firmware 191 has given an instance number to the PCI device. 192Users: 193 Userspace applications interested in knowing the 194 firmware assigned device type instance of the PCI 195 device that can help in understanding the firmware 196 intended order of the PCI device. 197 198What: /sys/bus/pci/devices/.../acpi_index 199Date: July 2010 200Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com 201Description: 202 Reading this attribute will provide the firmware 203 given instance (ACPI _DSM instance number) of the PCI device. 204 The attribute will be created only if the firmware has given 205 an instance number to the PCI device. ACPI _DSM instance number 206 will be given priority if the system firmware provides SMBIOS 207 type 41 device type instance also. 208Users: 209 Userspace applications interested in knowing the 210 firmware assigned instance number of the PCI 211 device that can help in understanding the firmware 212 intended order of the PCI device. 213 214What: /sys/bus/pci/devices/.../d3cold_allowed 215Date: July 2012 216Contact: Huang Ying <ying.huang@intel.com> 217Description: 218 d3cold_allowed is bit to control whether the corresponding PCI 219 device can be put into D3Cold state. If it is cleared, the 220 device will never be put into D3Cold state. If it is set, the 221 device may be put into D3Cold state if other requirements are 222 satisfied too. Reading this attribute will show the current 223 value of d3cold_allowed bit. Writing this attribute will set 224 the value of d3cold_allowed bit. 225 226What: /sys/bus/pci/devices/.../sriov_totalvfs 227Date: November 2012 228Contact: Donald Dutile <ddutile@redhat.com> 229Description: 230 This file appears when a physical PCIe device supports SR-IOV. 231 Userspace applications can read this file to determine the 232 maximum number of Virtual Functions (VFs) a PCIe physical 233 function (PF) can support. Typically, this is the value reported 234 in the PF's SR-IOV extended capability structure's TotalVFs 235 element. Drivers have the ability at probe time to reduce the 236 value read from this file via the pci_sriov_set_totalvfs() 237 function. 238 239What: /sys/bus/pci/devices/.../sriov_numvfs 240Date: November 2012 241Contact: Donald Dutile <ddutile@redhat.com> 242Description: 243 This file appears when a physical PCIe device supports SR-IOV. 244 Userspace applications can read and write to this file to 245 determine and control the enablement or disablement of Virtual 246 Functions (VFs) on the physical function (PF). A read of this 247 file will return the number of VFs that are enabled on this PF. 248 A number written to this file will enable the specified 249 number of VFs. A userspace application would typically read the 250 file and check that the value is zero, and then write the number 251 of VFs that should be enabled on the PF; the value written 252 should be less than or equal to the value in the sriov_totalvfs 253 file. A userspace application wanting to disable the VFs would 254 write a zero to this file. The core ensures that valid values 255 are written to this file, and returns errors when values are not 256 valid. For example, writing a 2 to this file when sriov_numvfs 257 is not 0 and not 2 already will return an error. Writing a 10 258 when the value of sriov_totalvfs is 8 will return an error. 259