Based on kernel version 3.13. Page generated on 2014-01-20 21:59 EST.
1 What: /sys/bus/pci/drivers/.../bind 2 Date: December 2003 3 Contact: firstname.lastname@example.org 4 Description: 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 14 What: /sys/bus/pci/drivers/.../unbind 15 Date: December 2003 16 Contact: email@example.com 17 Description: 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 27 What: /sys/bus/pci/drivers/.../new_id 28 Date: December 2003 29 Contact: firstname.lastname@example.org 30 Description: 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 44 What: /sys/bus/pci/drivers/.../remove_id 45 Date: February 2009 46 Contact: Chris Wright <email@example.com> 47 Description: 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 60 What: /sys/bus/pci/rescan 61 Date: January 2009 62 Contact: Linux PCI developers <firstname.lastname@example.org> 63 Description: 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 68 What: /sys/bus/pci/devices/.../msi_irqs/ 69 Date: September, 2011 70 Contact: Neil Horman <email@example.com> 71 Description: 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 79 What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode 80 Date: September 2011 81 Contact: Neil Horman <firstname.lastname@example.org> 82 Description: 83 This attribute indicates the mode that the irq vector named by 84 the parent directory is in (msi vs. msix) 85 86 What: /sys/bus/pci/devices/.../remove 87 Date: January 2009 88 Contact: Linux PCI developers <email@example.com> 89 Description: 90 Writing a non-zero value to this attribute will 91 hot-remove the PCI device and any of its children. 92 93 What: /sys/bus/pci/devices/.../pci_bus/.../rescan 94 Date: May 2011 95 Contact: Linux PCI developers <firstname.lastname@example.org> 96 Description: 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 102 What: /sys/bus/pci/devices/.../rescan 103 Date: January 2009 104 Contact: Linux PCI developers <email@example.com> 105 Description: 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 111 What: /sys/bus/pci/devices/.../reset 112 Date: July 2009 113 Contact: Michael S. Tsirkin <firstname.lastname@example.org> 114 Description: 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 121 What: /sys/bus/pci/devices/.../vpd 122 Date: February 2008 123 Contact: Ben Hutchings <email@example.com> 124 Description: 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 133 What: /sys/bus/pci/devices/.../virtfnN 134 Date: March 2009 135 Contact: Yu Zhao <firstname.lastname@example.org> 136 Description: 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 142 What: /sys/bus/pci/devices/.../dep_link 143 Date: March 2009 144 Contact: Yu Zhao <email@example.com> 145 Description: 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 152 What: /sys/bus/pci/devices/.../physfn 153 Date: March 2009 154 Contact: Yu Zhao <firstname.lastname@example.org> 155 Description: 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 160 What: /sys/bus/pci/slots/.../module 161 Date: June 2009 162 Contact: email@example.com 163 Description: 164 This symbolic link points to the PCI hotplug controller driver 165 module that manages the hotplug slot. 166 167 What: /sys/bus/pci/devices/.../label 168 Date: July 2010 169 Contact: Narendra K <firstname.lastname@example.org>, email@example.com 170 Description: 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. 177 Users: 178 Userspace applications interested in knowing the 179 firmware assigned name of the PCI device. 180 181 What: /sys/bus/pci/devices/.../index 182 Date: July 2010 183 Contact: Narendra K <firstname.lastname@example.org>, email@example.com 184 Description: 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. 189 Users: 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 195 What: /sys/bus/pci/devices/.../acpi_index 196 Date: July 2010 197 Contact: Narendra K <firstname.lastname@example.org>, email@example.com 198 Description: 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. 205 Users: 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 211 What: /sys/bus/pci/devices/.../d3cold_allowed 212 Date: July 2012 213 Contact: Huang Ying <firstname.lastname@example.org> 214 Description: 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 223 What: /sys/bus/pci/devices/.../sriov_totalvfs 224 Date: November 2012 225 Contact: Donald Dutile <email@example.com> 226 Description: 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 236 What: /sys/bus/pci/devices/.../sriov_numvfs 237 Date: November 2012 238 Contact: Donald Dutile <firstname.lastname@example.org> 239 Description: 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.