Based on kernel version 3.9. Page generated on 2013-05-02 22:53 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 Depends on CONFIG_HOTPLUG. 68 69 What: /sys/bus/pci/devices/.../msi_irqs/ 70 Date: September, 2011 71 Contact: Neil Horman <email@example.com> 72 Description: 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 80 What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode 81 Date: September 2011 82 Contact: Neil Horman <firstname.lastname@example.org> 83 Description: 84 This attribute indicates the mode that the irq vector named by 85 the parent directory is in (msi vs. msix) 86 87 What: /sys/bus/pci/devices/.../remove 88 Date: January 2009 89 Contact: Linux PCI developers <email@example.com> 90 Description: 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 95 What: /sys/bus/pci/devices/.../pci_bus/.../rescan 96 Date: May 2011 97 Contact: Linux PCI developers <firstname.lastname@example.org> 98 Description: 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 104 What: /sys/bus/pci/devices/.../rescan 105 Date: January 2009 106 Contact: Linux PCI developers <email@example.com> 107 Description: 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 114 What: /sys/bus/pci/devices/.../reset 115 Date: July 2009 116 Contact: Michael S. Tsirkin <firstname.lastname@example.org> 117 Description: 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 124 What: /sys/bus/pci/devices/.../vpd 125 Date: February 2008 126 Contact: Ben Hutchings <email@example.com> 127 Description: 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 136 What: /sys/bus/pci/devices/.../virtfnN 137 Date: March 2009 138 Contact: Yu Zhao <firstname.lastname@example.org> 139 Description: 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 145 What: /sys/bus/pci/devices/.../dep_link 146 Date: March 2009 147 Contact: Yu Zhao <email@example.com> 148 Description: 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 155 What: /sys/bus/pci/devices/.../physfn 156 Date: March 2009 157 Contact: Yu Zhao <firstname.lastname@example.org> 158 Description: 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 163 What: /sys/bus/pci/slots/.../module 164 Date: June 2009 165 Contact: email@example.com 166 Description: 167 This symbolic link points to the PCI hotplug controller driver 168 module that manages the hotplug slot. 169 170 What: /sys/bus/pci/devices/.../label 171 Date: July 2010 172 Contact: Narendra K <firstname.lastname@example.org>, email@example.com 173 Description: 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. 180 Users: 181 Userspace applications interested in knowing the 182 firmware assigned name of the PCI device. 183 184 What: /sys/bus/pci/devices/.../index 185 Date: July 2010 186 Contact: Narendra K <firstname.lastname@example.org>, email@example.com 187 Description: 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. 192 Users: 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 198 What: /sys/bus/pci/devices/.../acpi_index 199 Date: July 2010 200 Contact: Narendra K <firstname.lastname@example.org>, email@example.com 201 Description: 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. 208 Users: 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 214 What: /sys/bus/pci/devices/.../d3cold_allowed 215 Date: July 2012 216 Contact: Huang Ying <firstname.lastname@example.org> 217 Description: 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 226 What: /sys/bus/pci/devices/.../sriov_totalvfs 227 Date: November 2012 228 Contact: Donald Dutile <email@example.com> 229 Description: 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 239 What: /sys/bus/pci/devices/.../sriov_numvfs 240 Date: November 2012 241 Contact: Donald Dutile <firstname.lastname@example.org> 242 Description: 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.