Chris Wright | d22157b | 2009-02-23 21:50:35 -0800 | [diff] [blame] | 1 | What: /sys/bus/pci/drivers/.../bind |
| 2 | Date: December 2003 |
| 3 | Contact: linux-pci@vger.kernel.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: linux-pci@vger.kernel.org |
| 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: linux-pci@vger.kernel.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 | |
Chris Wright | 0994375 | 2009-02-23 21:52:23 -0800 | [diff] [blame] | 44 | What: /sys/bus/pci/drivers/.../remove_id |
| 45 | Date: February 2009 |
| 46 | Contact: Chris Wright <chrisw@sous-sol.org> |
| 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 | |
Alex Chiang | 705b1aa | 2009-03-20 14:56:31 -0600 | [diff] [blame] | 60 | What: /sys/bus/pci/rescan |
| 61 | Date: January 2009 |
| 62 | Contact: Linux PCI developers <linux-pci@vger.kernel.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 | |
Alex Chiang | 77c27c7 | 2009-03-20 14:56:36 -0600 | [diff] [blame] | 69 | What: /sys/bus/pci/devices/.../remove |
| 70 | Date: January 2009 |
| 71 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
| 72 | Description: |
| 73 | Writing a non-zero value to this attribute will |
| 74 | hot-remove the PCI device and any of its children. |
| 75 | Depends on CONFIG_HOTPLUG. |
| 76 | |
Alex Chiang | 738a639 | 2009-03-20 14:56:41 -0600 | [diff] [blame] | 77 | What: /sys/bus/pci/devices/.../rescan |
| 78 | Date: January 2009 |
| 79 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
| 80 | Description: |
| 81 | Writing a non-zero value to this attribute will |
| 82 | force a rescan of the device's parent bus and all |
| 83 | child buses, and re-discover devices removed earlier |
| 84 | from this part of the device tree. |
| 85 | Depends on CONFIG_HOTPLUG. |
| 86 | |
Michael S. Tsirkin | 711d577 | 2009-07-27 23:37:48 +0300 | [diff] [blame] | 87 | What: /sys/bus/pci/devices/.../reset |
| 88 | Date: July 2009 |
| 89 | Contact: Michael S. Tsirkin <mst@redhat.com> |
| 90 | Description: |
| 91 | Some devices allow an individual function to be reset |
| 92 | without affecting other functions in the same device. |
| 93 | For devices that have this support, a file named reset |
| 94 | will be present in sysfs. Writing 1 to this file |
| 95 | will perform reset. |
| 96 | |
Ben Hutchings | 94e6108 | 2008-03-05 16:52:39 +0000 | [diff] [blame] | 97 | What: /sys/bus/pci/devices/.../vpd |
| 98 | Date: February 2008 |
| 99 | Contact: Ben Hutchings <bhutchings@solarflare.com> |
| 100 | Description: |
| 101 | A file named vpd in a device directory will be a |
| 102 | binary file containing the Vital Product Data for the |
| 103 | device. It should follow the VPD format defined in |
| 104 | PCI Specification 2.1 or 2.2, but users should consider |
| 105 | that some devices may have malformatted data. If the |
| 106 | underlying VPD has a writable section then the |
| 107 | corresponding section of this file will be writable. |
Yu Zhao | 01db495 | 2009-03-20 11:25:17 +0800 | [diff] [blame] | 108 | |
| 109 | What: /sys/bus/pci/devices/.../virtfnN |
| 110 | Date: March 2009 |
| 111 | Contact: Yu Zhao <yu.zhao@intel.com> |
| 112 | Description: |
| 113 | This symbolic link appears when hardware supports the SR-IOV |
| 114 | capability and the Physical Function driver has enabled it. |
| 115 | The symbolic link points to the PCI device sysfs entry of the |
| 116 | Virtual Function whose index is N (0...MaxVFs-1). |
| 117 | |
| 118 | What: /sys/bus/pci/devices/.../dep_link |
| 119 | Date: March 2009 |
| 120 | Contact: Yu Zhao <yu.zhao@intel.com> |
| 121 | Description: |
| 122 | This symbolic link appears when hardware supports the SR-IOV |
| 123 | capability and the Physical Function driver has enabled it, |
| 124 | and this device has vendor specific dependencies with others. |
| 125 | The symbolic link points to the PCI device sysfs entry of |
| 126 | Physical Function this device depends on. |
| 127 | |
| 128 | What: /sys/bus/pci/devices/.../physfn |
| 129 | Date: March 2009 |
| 130 | Contact: Yu Zhao <yu.zhao@intel.com> |
| 131 | Description: |
| 132 | This symbolic link appears when a device is a Virtual Function. |
| 133 | The symbolic link points to the PCI device sysfs entry of the |
| 134 | Physical Function this device associates with. |
Kenji Kaneshige | c825bc9 | 2009-06-16 11:01:25 +0900 | [diff] [blame] | 135 | |
| 136 | What: /sys/bus/pci/slots/.../module |
| 137 | Date: June 2009 |
| 138 | Contact: linux-pci@vger.kernel.org |
| 139 | Description: |
| 140 | This symbolic link points to the PCI hotplug controller driver |
| 141 | module that manages the hotplug slot. |
Narendra K | 911e1c9 | 2010-07-26 05:56:50 -0500 | [diff] [blame] | 142 | |
| 143 | What: /sys/bus/pci/devices/.../label |
| 144 | Date: July 2010 |
| 145 | Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com |
| 146 | Description: |
| 147 | Reading this attribute will provide the firmware |
| 148 | given name(SMBIOS type 41 string) of the PCI device. |
| 149 | The attribute will be created only if the firmware |
| 150 | has given a name to the PCI device. |
| 151 | Users: |
| 152 | Userspace applications interested in knowing the |
| 153 | firmware assigned name of the PCI device. |
| 154 | |
| 155 | What: /sys/bus/pci/devices/.../index |
| 156 | Date: July 2010 |
| 157 | Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com |
| 158 | Description: |
| 159 | Reading this attribute will provide the firmware |
| 160 | given instance(SMBIOS type 41 device type instance) |
| 161 | of the PCI device. The attribute will be created |
| 162 | only if the firmware has given a device type instance |
| 163 | to the PCI device. |
| 164 | Users: |
| 165 | Userspace applications interested in knowing the |
| 166 | firmware assigned device type instance of the PCI |
| 167 | device that can help in understanding the firmware |
| 168 | intended order of the PCI device. |