sysfs-bus-pci 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124
  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/.../vpd
  81. Date: February 2008
  82. Contact: Ben Hutchings <bhutchings@solarflare.com>
  83. Description:
  84. A file named vpd in a device directory will be a
  85. binary file containing the Vital Product Data for the
  86. device. It should follow the VPD format defined in
  87. PCI Specification 2.1 or 2.2, but users should consider
  88. that some devices may have malformatted data. If the
  89. underlying VPD has a writable section then the
  90. corresponding section of this file will be writable.
  91. What: /sys/bus/pci/devices/.../virtfnN
  92. Date: March 2009
  93. Contact: Yu Zhao <yu.zhao@intel.com>
  94. Description:
  95. This symbolic link appears when hardware supports the SR-IOV
  96. capability and the Physical Function driver has enabled it.
  97. The symbolic link points to the PCI device sysfs entry of the
  98. Virtual Function whose index is N (0...MaxVFs-1).
  99. What: /sys/bus/pci/devices/.../dep_link
  100. Date: March 2009
  101. Contact: Yu Zhao <yu.zhao@intel.com>
  102. Description:
  103. This symbolic link appears when hardware supports the SR-IOV
  104. capability and the Physical Function driver has enabled it,
  105. and this device has vendor specific dependencies with others.
  106. The symbolic link points to the PCI device sysfs entry of
  107. Physical Function this device depends on.
  108. What: /sys/bus/pci/devices/.../physfn
  109. Date: March 2009
  110. Contact: Yu Zhao <yu.zhao@intel.com>
  111. Description:
  112. This symbolic link appears when a device is a Virtual Function.
  113. The symbolic link points to the PCI device sysfs entry of the
  114. Physical Function this device associates with.