sysfs-bus-pci 6.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181
  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. What: /sys/bus/pci/drivers/.../unbind
  14. Date: December 2003
  15. Contact: linux-pci@vger.kernel.org
  16. Description:
  17. Writing a device location to this file will cause the
  18. driver to attempt to unbind from the device found at
  19. this location. This may be useful when overriding default
  20. bindings. The format for the location is: DDDD:BB:DD.F.
  21. That is Domain:Bus:Device.Function and is the same as
  22. found in /sys/bus/pci/devices/. For example:
  23. # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
  24. (Note: kernels before 2.6.28 may require echo -n).
  25. What: /sys/bus/pci/drivers/.../new_id
  26. Date: December 2003
  27. Contact: linux-pci@vger.kernel.org
  28. Description:
  29. Writing a device ID to this file will attempt to
  30. dynamically add a new device ID to a PCI device driver.
  31. This may allow the driver to support more hardware than
  32. was included in the driver's static device ID support
  33. table at compile time. The format for the device ID is:
  34. VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID,
  35. Device ID, Subsystem Vendor ID, Subsystem Device ID,
  36. Class, Class Mask, and Private Driver Data. The Vendor ID
  37. and Device ID fields are required, the rest are optional.
  38. Upon successfully adding an ID, the driver will probe
  39. for the device and attempt to bind to it. For example:
  40. # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
  41. What: /sys/bus/pci/drivers/.../remove_id
  42. Date: February 2009
  43. Contact: Chris Wright <chrisw@sous-sol.org>
  44. Description:
  45. Writing a device ID to this file will remove an ID
  46. that was dynamically added via the new_id sysfs entry.
  47. The format for the device ID is:
  48. VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device
  49. ID, Subsystem Vendor ID, Subsystem Device ID, Class,
  50. and Class Mask. The Vendor ID and Device ID fields are
  51. required, the rest are optional. After successfully
  52. removing an ID, the driver will no longer support the
  53. device. This is useful to ensure auto probing won't
  54. match the driver to the device. For example:
  55. # echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id
  56. What: /sys/bus/pci/rescan
  57. Date: January 2009
  58. Contact: Linux PCI developers <linux-pci@vger.kernel.org>
  59. Description:
  60. Writing a non-zero value to this attribute will
  61. force a rescan of all PCI buses in the system, and
  62. re-discover previously removed devices.
  63. Depends on CONFIG_HOTPLUG.
  64. What: /sys/bus/pci/devices/.../remove
  65. Date: January 2009
  66. Contact: Linux PCI developers <linux-pci@vger.kernel.org>
  67. Description:
  68. Writing a non-zero value to this attribute will
  69. hot-remove the PCI device and any of its children.
  70. Depends on CONFIG_HOTPLUG.
  71. What: /sys/bus/pci/devices/.../rescan
  72. Date: January 2009
  73. Contact: Linux PCI developers <linux-pci@vger.kernel.org>
  74. Description:
  75. Writing a non-zero value to this attribute will
  76. force a rescan of the device's parent bus and all
  77. child buses, and re-discover devices removed earlier
  78. from this part of the device tree.
  79. Depends on CONFIG_HOTPLUG.
  80. What: /sys/bus/pci/devices/.../reset
  81. Date: July 2009
  82. Contact: Michael S. Tsirkin <mst@redhat.com>
  83. Description:
  84. Some devices allow an individual function to be reset
  85. without affecting other functions in the same device.
  86. For devices that have this support, a file named reset
  87. will be present in sysfs. Writing 1 to this file
  88. will perform reset.
  89. What: /sys/bus/pci/devices/.../vpd
  90. Date: February 2008
  91. Contact: Ben Hutchings <bhutchings@solarflare.com>
  92. Description:
  93. A file named vpd in a device directory will be a
  94. binary file containing the Vital Product Data for the
  95. device. It should follow the VPD format defined in
  96. PCI Specification 2.1 or 2.2, but users should consider
  97. that some devices may have malformatted data. If the
  98. underlying VPD has a writable section then the
  99. corresponding section of this file will be writable.
  100. What: /sys/bus/pci/devices/.../virtfnN
  101. Date: March 2009
  102. Contact: Yu Zhao <yu.zhao@intel.com>
  103. Description:
  104. This symbolic link appears when hardware supports the SR-IOV
  105. capability and the Physical Function driver has enabled it.
  106. The symbolic link points to the PCI device sysfs entry of the
  107. Virtual Function whose index is N (0...MaxVFs-1).
  108. What: /sys/bus/pci/devices/.../dep_link
  109. Date: March 2009
  110. Contact: Yu Zhao <yu.zhao@intel.com>
  111. Description:
  112. This symbolic link appears when hardware supports the SR-IOV
  113. capability and the Physical Function driver has enabled it,
  114. and this device has vendor specific dependencies with others.
  115. The symbolic link points to the PCI device sysfs entry of
  116. Physical Function this device depends on.
  117. What: /sys/bus/pci/devices/.../physfn
  118. Date: March 2009
  119. Contact: Yu Zhao <yu.zhao@intel.com>
  120. Description:
  121. This symbolic link appears when a device is a Virtual Function.
  122. The symbolic link points to the PCI device sysfs entry of the
  123. Physical Function this device associates with.
  124. What: /sys/bus/pci/slots/...
  125. Date: April 2005 (possibly older)
  126. KernelVersion: 2.6.12 (possibly older)
  127. Contact: linux-pci@vger.kernel.org
  128. Description:
  129. When the appropriate driver is loaded, it will create a
  130. directory per claimed physical PCI slot in
  131. /sys/bus/pci/slots/. The names of these directories are
  132. specific to the driver, which in turn, are specific to the
  133. platform, but in general, should match the label on the
  134. machine's physical chassis.
  135. The drivers that can create slot directories include the
  136. PCI hotplug drivers, and as of 2.6.27, the pci_slot driver.
  137. The slot directories contain, at a minimum, a file named
  138. 'address' which contains the PCI bus:device:function tuple.
  139. Other files may appear as well, but are specific to the
  140. driver.
  141. What: /sys/bus/pci/slots/.../function[0-7]
  142. Date: March 2010
  143. KernelVersion: 2.6.35
  144. Contact: linux-pci@vger.kernel.org
  145. Description:
  146. If PCI slot directories (as described above) are created,
  147. and the physical slot is actually populated with a device,
  148. symbolic links in the slot directory pointing to the
  149. device's PCI functions are created as well.
  150. What: /sys/bus/pci/devices/.../slot
  151. Date: March 2010
  152. KernelVersion: 2.6.35
  153. Contact: linux-pci@vger.kernel.org
  154. Description:
  155. If PCI slot directories (as described above) are created,
  156. a symbolic link pointing to the slot directory will be
  157. created as well.
  158. What: /sys/bus/pci/slots/.../module
  159. Date: June 2009
  160. Contact: linux-pci@vger.kernel.org
  161. Description:
  162. This symbolic link points to the PCI hotplug controller driver
  163. module that manages the hotplug slot.