1What:		/sys/bus/pci/drivers/.../bind
  2Date:		December 2003
  3Contact:	linux-pci@vger.kernel.org
  4Description:
  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
 14What:		/sys/bus/pci/drivers/.../unbind
 15Date:		December 2003
 16Contact:	linux-pci@vger.kernel.org
 17Description:
 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
 27What:		/sys/bus/pci/drivers/.../new_id
 28Date:		December 2003
 29Contact:	linux-pci@vger.kernel.org
 30Description:
 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
 44What:		/sys/bus/pci/drivers/.../remove_id
 45Date:		February 2009
 46Contact:	Chris Wright <chrisw@sous-sol.org>
 47Description:
 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
 60What:		/sys/bus/pci/rescan
 61Date:		January 2009
 62Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 63Description:
 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
 69What:		/sys/bus/pci/devices/.../remove
 70Date:		January 2009
 71Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 72Description:
 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
 77What:		/sys/bus/pci/devices/.../pci_bus/.../rescan
 78Date:		May 2011
 79Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 80Description:
 81		Writing a non-zero value to this attribute will
 82		force a rescan of the bus and all child buses,
 83		and re-discover devices removed earlier from this
 84		part of the device tree.  Depends on CONFIG_HOTPLUG.
 85
 86What:		/sys/bus/pci/devices/.../rescan
 87Date:		January 2009
 88Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 89Description:
 90		Writing a non-zero value to this attribute will
 91		force a rescan of the device's parent bus and all
 92		child buses, and re-discover devices removed earlier
 93		from this part of the device tree.
 94		Depends on CONFIG_HOTPLUG.
 95
 96What:		/sys/bus/pci/devices/.../reset
 97Date:		July 2009
 98Contact:	Michael S. Tsirkin <mst@redhat.com>
 99Description:
100		Some devices allow an individual function to be reset
101		without affecting other functions in the same device.
102		For devices that have this support, a file named reset
103		will be present in sysfs.  Writing 1 to this file
104		will perform reset.
105
106What:		/sys/bus/pci/devices/.../vpd
107Date:		February 2008
108Contact:	Ben Hutchings <bhutchings@solarflare.com>
109Description:
110		A file named vpd in a device directory will be a
111		binary file containing the Vital Product Data for the
112		device.  It should follow the VPD format defined in
113		PCI Specification 2.1 or 2.2, but users should consider
114		that some devices may have malformatted data.  If the
115		underlying VPD has a writable section then the
116		corresponding section of this file will be writable.
117
118What:		/sys/bus/pci/devices/.../virtfnN
119Date:		March 2009
120Contact:	Yu Zhao <yu.zhao@intel.com>
121Description:
122		This symbolic link appears when hardware supports the SR-IOV
123		capability and the Physical Function driver has enabled it.
124		The symbolic link points to the PCI device sysfs entry of the
125		Virtual Function whose index is N (0...MaxVFs-1).
126
127What:		/sys/bus/pci/devices/.../dep_link
128Date:		March 2009
129Contact:	Yu Zhao <yu.zhao@intel.com>
130Description:
131		This symbolic link appears when hardware supports the SR-IOV
132		capability and the Physical Function driver has enabled it,
133		and this device has vendor specific dependencies with others.
134		The symbolic link points to the PCI device sysfs entry of
135		Physical Function this device depends on.
136
137What:		/sys/bus/pci/devices/.../physfn
138Date:		March 2009
139Contact:	Yu Zhao <yu.zhao@intel.com>
140Description:
141		This symbolic link appears when a device is a Virtual Function.
142		The symbolic link points to the PCI device sysfs entry of the
143		Physical Function this device associates with.
144
145What:		/sys/bus/pci/slots/.../module
146Date:		June 2009
147Contact:	linux-pci@vger.kernel.org
148Description:
149		This symbolic link points to the PCI hotplug controller driver
150		module that manages the hotplug slot.
151
152What:		/sys/bus/pci/devices/.../label
153Date:		July 2010
154Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
155Description:
156		Reading this attribute will provide the firmware
157		given name (SMBIOS type 41 string or ACPI _DSM string) of
158		the PCI device.	The attribute will be created only
159		if the firmware	has given a name to the PCI device.
160		ACPI _DSM string name will be given priority if the
161		system firmware provides SMBIOS type 41 string also.
162Users:
163		Userspace applications interested in knowing the
164		firmware assigned name of the PCI device.
165
166What:		/sys/bus/pci/devices/.../index
167Date:		July 2010
168Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
169Description:
170		Reading this attribute will provide the firmware
171		given instance (SMBIOS type 41 device type instance) of the
172		PCI device. The attribute will be created only if the firmware
173		has given an instance number to the PCI device.
174Users:
175		Userspace applications interested in knowing the
176		firmware assigned device type instance of the PCI
177		device that can help in understanding the firmware
178		intended order of the PCI device.
179
180What:		/sys/bus/pci/devices/.../acpi_index
181Date:		July 2010
182Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
183Description:
184		Reading this attribute will provide the firmware
185		given instance (ACPI _DSM instance number) of the PCI device.
186		The attribute will be created only if the firmware has given
187		an instance number to the PCI device. ACPI _DSM instance number
188		will be given priority if the system firmware provides SMBIOS
189		type 41 device type instance also.
190Users:
191		Userspace applications interested in knowing the
192		firmware assigned instance number of the PCI
193		device that can help in understanding the firmware
194		intended order of the PCI device.

  1What:		/sys/bus/pci/drivers/.../bind
  2Date:		December 2003
  3Contact:	linux-pci@vger.kernel.org
  4Description:
  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
 14What:		/sys/bus/pci/drivers/.../unbind
 15Date:		December 2003
 16Contact:	linux-pci@vger.kernel.org
 17Description:
 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
 27What:		/sys/bus/pci/drivers/.../new_id
 28Date:		December 2003
 29Contact:	linux-pci@vger.kernel.org
 30Description:
 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
 44What:		/sys/bus/pci/drivers/.../remove_id
 45Date:		February 2009
 46Contact:	Chris Wright <chrisw@sous-sol.org>
 47Description:
 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
 60What:		/sys/bus/pci/rescan
 61Date:		January 2009
 62Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 63Description:
 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
 68What:		/sys/bus/pci/devices/.../msi_irqs/
 69Date:		September, 2011
 70Contact:	Neil Horman <nhorman@tuxdriver.com>
 71Description:
 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
 76What:		/sys/bus/pci/devices/.../msi_irqs/<N>
 77Date:		September 2011
 78Contact:	Neil Horman <nhorman@tuxdriver.com>
 79Description:
 80		This attribute indicates the mode that the irq vector named by
 81		the file is in (msi vs. msix)
 82
 83What:		/sys/bus/pci/devices/.../remove
 84Date:		January 2009
 85Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 86Description:
 87		Writing a non-zero value to this attribute will
 88		hot-remove the PCI device and any of its children.
 
 89
 90What:		/sys/bus/pci/devices/.../pci_bus/.../rescan
 91Date:		May 2011
 92Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 93Description:
 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
 99What:		/sys/bus/pci/devices/.../rescan
100Date:		January 2009
101Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
102Description:
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
108What:		/sys/bus/pci/devices/.../reset
109Date:		July 2009
110Contact:	Michael S. Tsirkin <mst@redhat.com>
111Description:
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
118What:		/sys/bus/pci/devices/.../vpd
119Date:		February 2008
120Contact:	Ben Hutchings <bwh@kernel.org>
121Description:
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
130What:		/sys/bus/pci/devices/.../virtfnN
131Date:		March 2009
132Contact:	Yu Zhao <yu.zhao@intel.com>
133Description:
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
139What:		/sys/bus/pci/devices/.../dep_link
140Date:		March 2009
141Contact:	Yu Zhao <yu.zhao@intel.com>
142Description:
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
149What:		/sys/bus/pci/devices/.../physfn
150Date:		March 2009
151Contact:	Yu Zhao <yu.zhao@intel.com>
152Description:
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
157What:		/sys/bus/pci/slots/.../module
158Date:		June 2009
159Contact:	linux-pci@vger.kernel.org
160Description:
161		This symbolic link points to the PCI hotplug controller driver
162		module that manages the hotplug slot.
163
164What:		/sys/bus/pci/devices/.../label
165Date:		July 2010
166Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
167Description:
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.
174Users:
175		Userspace applications interested in knowing the
176		firmware assigned name of the PCI device.
177
178What:		/sys/bus/pci/devices/.../index
179Date:		July 2010
180Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
181Description:
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.
186Users:
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
192What:		/sys/bus/pci/devices/.../acpi_index
193Date:		July 2010
194Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
195Description:
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.
202Users:
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
208What:		/sys/bus/pci/devices/.../d3cold_allowed
209Date:		July 2012
210Contact:	Huang Ying <ying.huang@intel.com>
211Description:
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
220What:		/sys/bus/pci/devices/.../sriov_totalvfs
221Date:		November 2012
222Contact:	Donald Dutile <ddutile@redhat.com>
223Description:
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
233What:		/sys/bus/pci/devices/.../sriov_numvfs
234Date:		November 2012
235Contact:	Donald Dutile <ddutile@redhat.com>
236Description:
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.