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
  68 What:           /sys/bus/pci/devices/.../msi_irqs/
  69 Date:           September, 2011
  70 Contact:        Neil Horman <nhorman@tuxdriver.com>
  71 Description:
  72                 The /sys/devices/.../msi_irqs directory contains a variable set
  73                 of files, with each file being named after a corresponding msi
  74                 irq vector allocated to that device.
  75
  76 What:           /sys/bus/pci/devices/.../msi_irqs/<N>
  77 Date:           September 2011
  78 Contact:        Neil Horman <nhorman@tuxdriver.com>
  79 Description:
  80                 This attribute indicates the mode that the irq vector named by
  81                 the file is in (msi vs. msix)
  82
  83 What:           /sys/bus/pci/devices/.../remove
  84 Date:           January 2009
  85 Contact:        Linux PCI developers <linux-pci@vger.kernel.org>
  86 Description:
  87                 Writing a non-zero value to this attribute will
  88                 hot-remove the PCI device and any of its children.
  89
  90 What:           /sys/bus/pci/devices/.../pci_bus/.../rescan
  91 Date:           May 2011
  92 Contact:        Linux PCI developers <linux-pci@vger.kernel.org>
  93 Description:
  94                 Writing a non-zero value to this attribute will
  95                 force a rescan of the bus and all child buses,
  96                 and re-discover devices removed earlier from this
  97                 part of the device tree.
  98
  99 What:           /sys/bus/pci/devices/.../rescan
 100 Date:           January 2009
 101 Contact:        Linux PCI developers <linux-pci@vger.kernel.org>
 102 Description:
 103                 Writing a non-zero value to this attribute will
 104                 force a rescan of the device's parent bus and all
 105                 child buses, and re-discover devices removed earlier
 106                 from this part of the device tree.
 107
 108 What:           /sys/bus/pci/devices/.../reset
 109 Date:           July 2009
 110 Contact:        Michael S. Tsirkin <mst@redhat.com>
 111 Description:
 112                 Some devices allow an individual function to be reset
 113                 without affecting other functions in the same device.
 114                 For devices that have this support, a file named reset
 115                 will be present in sysfs.  Writing 1 to this file
 116                 will perform reset.
 117
 118 What:           /sys/bus/pci/devices/.../vpd
 119 Date:           February 2008
 120 Contact:        Ben Hutchings <bwh@kernel.org>
 121 Description:
 122                 A file named vpd in a device directory will be a
 123                 binary file containing the Vital Product Data for the
 124                 device.  It should follow the VPD format defined in
 125                 PCI Specification 2.1 or 2.2, but users should consider
 126                 that some devices may have malformatted data.  If the
 127                 underlying VPD has a writable section then the
 128                 corresponding section of this file will be writable.
 129
 130 What:           /sys/bus/pci/devices/.../virtfnN
 131 Date:           March 2009
 132 Contact:        Yu Zhao <yu.zhao@intel.com>
 133 Description:
 134                 This symbolic link appears when hardware supports the SR-IOV
 135                 capability and the Physical Function driver has enabled it.
 136                 The symbolic link points to the PCI device sysfs entry of the
 137                 Virtual Function whose index is N (0...MaxVFs-1).
 138
 139 What:           /sys/bus/pci/devices/.../dep_link
 140 Date:           March 2009
 141 Contact:        Yu Zhao <yu.zhao@intel.com>
 142 Description:
 143                 This symbolic link appears when hardware supports the SR-IOV
 144                 capability and the Physical Function driver has enabled it,
 145                 and this device has vendor specific dependencies with others.
 146                 The symbolic link points to the PCI device sysfs entry of
 147                 Physical Function this device depends on.
 148
 149 What:           /sys/bus/pci/devices/.../physfn
 150 Date:           March 2009
 151 Contact:        Yu Zhao <yu.zhao@intel.com>
 152 Description:
 153                 This symbolic link appears when a device is a Virtual Function.
 154                 The symbolic link points to the PCI device sysfs entry of the
 155                 Physical Function this device associates with.
 156
 157 What:           /sys/bus/pci/slots/.../module
 158 Date:           June 2009
 159 Contact:        linux-pci@vger.kernel.org
 160 Description:
 161                 This symbolic link points to the PCI hotplug controller driver
 162                 module that manages the hotplug slot.
 163
 164 What:           /sys/bus/pci/devices/.../label
 165 Date:           July 2010
 166 Contact:        Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
 167 Description:
 168                 Reading this attribute will provide the firmware
 169                 given name (SMBIOS type 41 string or ACPI _DSM string) of
 170                 the PCI device. The attribute will be created only
 171                 if the firmware has given a name to the PCI device.
 172                 ACPI _DSM string name will be given priority if the
 173                 system firmware provides SMBIOS type 41 string also.
 174 Users:
 175                 Userspace applications interested in knowing the
 176                 firmware assigned name of the PCI device.
 177
 178 What:           /sys/bus/pci/devices/.../index
 179 Date:           July 2010
 180 Contact:        Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
 181 Description:
 182                 Reading this attribute will provide the firmware
 183                 given instance (SMBIOS type 41 device type instance) of the
 184                 PCI device. The attribute will be created only if the firmware
 185                 has given an instance number to the PCI device.
 186 Users:
 187                 Userspace applications interested in knowing the
 188                 firmware assigned device type instance of the PCI
 189                 device that can help in understanding the firmware
 190                 intended order of the PCI device.
 191
 192 What:           /sys/bus/pci/devices/.../acpi_index
 193 Date:           July 2010
 194 Contact:        Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
 195 Description:
 196                 Reading this attribute will provide the firmware
 197                 given instance (ACPI _DSM instance number) of the PCI device.
 198                 The attribute will be created only if the firmware has given
 199                 an instance number to the PCI device. ACPI _DSM instance number
 200                 will be given priority if the system firmware provides SMBIOS
 201                 type 41 device type instance also.
 202 Users:
 203                 Userspace applications interested in knowing the
 204                 firmware assigned instance number of the PCI
 205                 device that can help in understanding the firmware
 206                 intended order of the PCI device.
 207
 208 What:           /sys/bus/pci/devices/.../d3cold_allowed
 209 Date:           July 2012
 210 Contact:        Huang Ying <ying.huang@intel.com>
 211 Description:
 212                 d3cold_allowed is bit to control whether the corresponding PCI
 213                 device can be put into D3Cold state.  If it is cleared, the
 214                 device will never be put into D3Cold state.  If it is set, the
 215                 device may be put into D3Cold state if other requirements are
 216                 satisfied too.  Reading this attribute will show the current
 217                 value of d3cold_allowed bit.  Writing this attribute will set
 218                 the value of d3cold_allowed bit.
 219
 220 What:           /sys/bus/pci/devices/.../sriov_totalvfs
 221 Date:           November 2012
 222 Contact:        Donald Dutile <ddutile@redhat.com>
 223 Description:
 224                 This file appears when a physical PCIe device supports SR-IOV.
 225                 Userspace applications can read this file to determine the
 226                 maximum number of Virtual Functions (VFs) a PCIe physical
 227                 function (PF) can support. Typically, this is the value reported
 228                 in the PF's SR-IOV extended capability structure's TotalVFs
 229                 element.  Drivers have the ability at probe time to reduce the
 230                 value read from this file via the pci_sriov_set_totalvfs()
 231                 function.
 232
 233 What:           /sys/bus/pci/devices/.../sriov_numvfs
 234 Date:           November 2012
 235 Contact:        Donald Dutile <ddutile@redhat.com>
 236 Description:
 237                 This file appears when a physical PCIe device supports SR-IOV.
 238                 Userspace applications can read and write to this file to
 239                 determine and control the enablement or disablement of Virtual
 240                 Functions (VFs) on the physical function (PF). A read of this
 241                 file will return the number of VFs that are enabled on this PF.
 242                 A number written to this file will enable the specified
 243                 number of VFs. A userspace application would typically read the
 244                 file and check that the value is zero, and then write the number
 245                 of VFs that should be enabled on the PF; the value written
 246                 should be less than or equal to the value in the sriov_totalvfs
 247                 file. A userspace application wanting to disable the VFs would
 248                 write a zero to this file. The core ensures that valid values
 249                 are written to this file, and returns errors when values are not
 250                 valid.  For example, writing a 2 to this file when sriov_numvfs
 251                 is not 0 and not 2 already will return an error. Writing a 10
 252                 when the value of sriov_totalvfs is 8 will return an error.
 253
 254 What:           /sys/bus/pci/devices/.../driver_override
 255 Date:           April 2014
 256 Contact:        Alex Williamson <alex.williamson@redhat.com>
 257 Description:
 258                 This file allows the driver for a device to be specified which
 259                 will override standard static and dynamic ID matching.  When
 260                 specified, only a driver with a name matching the value written
 261                 to driver_override will have an opportunity to bind to the
 262                 device.  The override is specified by writing a string to the
 263                 driver_override file (echo pci-stub > driver_override) and
 264                 may be cleared with an empty string (echo > driver_override).
 265                 This returns the device to standard matching rules binding.
 266                 Writing to driver_override does not automatically unbind the
 267                 device from its current driver or make any attempt to
 268                 automatically load the specified driver.  If no driver with a
 269                 matching name is currently loaded in the kernel, the device
 270                 will not bind to any driver.  This also allows devices to
 271                 opt-out of driver binding using a driver_override name such as
 272                 "none".  Only a single driver may be specified in the override,
 273                 there is no support for parsing delimiters.