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