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		Depends on CONFIG_HOTPLUG.
 68
 69What:		/sys/bus/pci/devices/.../msi_irqs/
 70Date:		September, 2011
 71Contact:	Neil Horman <nhorman@tuxdriver.com>
 72Description:
 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
 80What:		/sys/bus/pci/devices/.../msi_irqs/<N>/mode
 81Date:		September 2011
 82Contact:	Neil Horman <nhorman@tuxdriver.com>
 83Description:
 84		This attribute indicates the mode that the irq vector named by
 85		the parent directory is in (msi vs. msix)
 86
 87What:		/sys/bus/pci/devices/.../remove
 88Date:		January 2009
 89Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 90Description:
 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
 95What:		/sys/bus/pci/devices/.../pci_bus/.../rescan
 96Date:		May 2011
 97Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 98Description:
 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
104What:		/sys/bus/pci/devices/.../rescan
105Date:		January 2009
106Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
107Description:
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
114What:		/sys/bus/pci/devices/.../reset
115Date:		July 2009
116Contact:	Michael S. Tsirkin <mst@redhat.com>
117Description:
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
124What:		/sys/bus/pci/devices/.../vpd
125Date:		February 2008
126Contact:	Ben Hutchings <bhutchings@solarflare.com>
127Description:
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
136What:		/sys/bus/pci/devices/.../virtfnN
137Date:		March 2009
138Contact:	Yu Zhao <yu.zhao@intel.com>
139Description:
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
145What:		/sys/bus/pci/devices/.../dep_link
146Date:		March 2009
147Contact:	Yu Zhao <yu.zhao@intel.com>
148Description:
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
155What:		/sys/bus/pci/devices/.../physfn
156Date:		March 2009
157Contact:	Yu Zhao <yu.zhao@intel.com>
158Description:
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
163What:		/sys/bus/pci/slots/.../module
164Date:		June 2009
165Contact:	linux-pci@vger.kernel.org
166Description:
167		This symbolic link points to the PCI hotplug controller driver
168		module that manages the hotplug slot.
169
170What:		/sys/bus/pci/devices/.../label
171Date:		July 2010
172Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
173Description:
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.
180Users:
181		Userspace applications interested in knowing the
182		firmware assigned name of the PCI device.
183
184What:		/sys/bus/pci/devices/.../index
185Date:		July 2010
186Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
187Description:
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.
192Users:
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
198What:		/sys/bus/pci/devices/.../acpi_index
199Date:		July 2010
200Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
201Description:
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.
208Users:
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.