Documentation/ABI/testing/sysfs-bus-pci

   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
  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
  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
  69 What:           /sys/bus/pci/devices/.../msi_irqs/
  70 Date:           September, 2011
  71 Contact:        Neil Horman <nhorman@tuxdriver.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 <nhorman@tuxdriver.com>
  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 <linux-pci@vger.kernel.org>
  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 <linux-pci@vger.kernel.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 <linux-pci@vger.kernel.org>
 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 <mst@redhat.com>
 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 <bhutchings@solarflare.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 <yu.zhao@intel.com>
 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 <yu.zhao@intel.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 <yu.zhao@intel.com>
 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:        linux-pci@vger.kernel.org
 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 <narendra_k@dell.com>, linux-bugs@dell.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 <narendra_k@dell.com>, linux-bugs@dell.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 <narendra_k@dell.com>, linux-bugs@dell.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.