Documentation/ABI/testing/sysfs-bus-pci - maze/linux - Git at Google

 What:		/sys/bus/pci/drivers/.../bind
 Date:		December 2003
 Contact:	linux-pci@vger.kernel.org
 Description:
 		Writing a device location to this file will cause
 		the driver to attempt to bind to the device found at
 		this location.	This is useful for overriding default
 		bindings.  The format for the location is: DDDD:BB:DD.F.
 		That is Domain:Bus:Device.Function and is the same as
 		found in /sys/bus/pci/devices/.  For example:
 		# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind
 		(Note: kernels before 2.6.28 may require echo -n).

 What:		/sys/bus/pci/drivers/.../unbind
 Date:		December 2003
 Contact:	linux-pci@vger.kernel.org
 Description:
 		Writing a device location to this file will cause the
 		driver to attempt to unbind from the device found at
 		this location.	This may be useful when overriding default
 		bindings.  The format for the location is: DDDD:BB:DD.F.
 		That is Domain:Bus:Device.Function and is the same as
 		found in /sys/bus/pci/devices/. For example:
 		# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
 		(Note: kernels before 2.6.28 may require echo -n).

 What:		/sys/bus/pci/drivers/.../new_id
 Date:		December 2003
 Contact:	linux-pci@vger.kernel.org
 Description:
 		Writing a device ID to this file will attempt to
 		dynamically add a new device ID to a PCI device driver.
 		This may allow the driver to support more hardware than
 		was included in the driver's static device ID support
 		table at compile time.  The format for the device ID is:
 		VVVV DDDD SVVV SDDD CCCC MMMM PPPP.  That is Vendor ID,
 		Device ID, Subsystem Vendor ID, Subsystem Device ID,
 		Class, Class Mask, and Private Driver Data.  The Vendor ID
 		and Device ID fields are required, the rest are optional.
 		Upon successfully adding an ID, the driver will probe
 		for the device and attempt to bind to it.  For example:
 		# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id

 What:		/sys/bus/pci/drivers/.../remove_id
 Date:		February 2009
 Contact:	Chris Wright <chrisw@sous-sol.org>
 Description:
 		Writing a device ID to this file will remove an ID
 		that was dynamically added via the new_id sysfs entry.
 		The format for the device ID is:
 		VVVV DDDD SVVV SDDD CCCC MMMM.	That is Vendor ID, Device
 		ID, Subsystem Vendor ID, Subsystem Device ID, Class,
 		and Class Mask.  The Vendor ID and Device ID fields are
 		required, the rest are optional.  After successfully
 		removing an ID, the driver will no longer support the
 		device.  This is useful to ensure auto probing won't
 		match the driver to the device.  For example:
 		# echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id

 What:		/sys/bus/pci/rescan
 Date:		January 2009
 Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 Description:
 		Writing a non-zero value to this attribute will
 		force a rescan of all PCI buses in the system, and
 		re-discover previously removed devices.

 What:		/sys/bus/pci/devices/.../msi_irqs/
 Date:		September, 2011
 Contact:	Neil Horman <nhorman@tuxdriver.com>
 Description:
 		The /sys/devices/.../msi_irqs directory contains a variable set
 		of sub-directories, with each sub-directory being named after a
 		corresponding msi irq vector allocated to that device.  Each
 		numbered sub-directory N contains attributes of that irq.
 		Note that this directory is not created for device drivers which
 		do not support msi irqs

 What:		/sys/bus/pci/devices/.../msi_irqs/<N>/mode
 Date:		September 2011
 Contact:	Neil Horman <nhorman@tuxdriver.com>
 Description:
 		This attribute indicates the mode that the irq vector named by
 		the parent directory is in (msi vs. msix)

 What:		/sys/bus/pci/devices/.../remove
 Date:		January 2009
 Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 Description:
 		Writing a non-zero value to this attribute will
 		hot-remove the PCI device and any of its children.

 What:		/sys/bus/pci/devices/.../pci_bus/.../rescan
 Date:		May 2011
 Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 Description:
 		Writing a non-zero value to this attribute will
 		force a rescan of the bus and all child buses,
 		and re-discover devices removed earlier from this
 		part of the device tree.

 What:		/sys/bus/pci/devices/.../rescan
 Date:		January 2009
 Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 Description:
 		Writing a non-zero value to this attribute will
 		force a rescan of the device's parent bus and all
 		child buses, and re-discover devices removed earlier
 		from this part of the device tree.

 What:		/sys/bus/pci/devices/.../reset
 Date:		July 2009
 Contact:	Michael S. Tsirkin <mst@redhat.com>
 Description:
 		Some devices allow an individual function to be reset
 		without affecting other functions in the same device.
 		For devices that have this support, a file named reset
 		will be present in sysfs.  Writing 1 to this file
 		will perform reset.

 What:		/sys/bus/pci/devices/.../vpd
 Date:		February 2008
 Contact:	Ben Hutchings <bhutchings@solarflare.com>
 Description:
 		A file named vpd in a device directory will be a
 		binary file containing the Vital Product Data for the
 		device.  It should follow the VPD format defined in
 		PCI Specification 2.1 or 2.2, but users should consider
 		that some devices may have malformatted data.  If the
 		underlying VPD has a writable section then the
 		corresponding section of this file will be writable.

 What:		/sys/bus/pci/devices/.../virtfnN
 Date:		March 2009
 Contact:	Yu Zhao <yu.zhao@intel.com>
 Description:
 		This symbolic link appears when hardware supports the SR-IOV
 		capability and the Physical Function driver has enabled it.
 		The symbolic link points to the PCI device sysfs entry of the
 		Virtual Function whose index is N (0...MaxVFs-1).

 What:		/sys/bus/pci/devices/.../dep_link
 Date:		March 2009
 Contact:	Yu Zhao <yu.zhao@intel.com>
 Description:
 		This symbolic link appears when hardware supports the SR-IOV
 		capability and the Physical Function driver has enabled it,
 		and this device has vendor specific dependencies with others.
 		The symbolic link points to the PCI device sysfs entry of
 		Physical Function this device depends on.

 What:		/sys/bus/pci/devices/.../physfn
 Date:		March 2009
 Contact:	Yu Zhao <yu.zhao@intel.com>
 Description:
 		This symbolic link appears when a device is a Virtual Function.
 		The symbolic link points to the PCI device sysfs entry of the
 		Physical Function this device associates with.

 What:		/sys/bus/pci/slots/.../module
 Date:		June 2009
 Contact:	linux-pci@vger.kernel.org
 Description:
 		This symbolic link points to the PCI hotplug controller driver
 		module that manages the hotplug slot.

 What:		/sys/bus/pci/devices/.../label
 Date:		July 2010
 Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
 Description:
 		Reading this attribute will provide the firmware
 		given name (SMBIOS type 41 string or ACPI _DSM string) of
 		the PCI device.	The attribute will be created only
 		if the firmware	has given a name to the PCI device.
 		ACPI _DSM string name will be given priority if the
 		system firmware provides SMBIOS type 41 string also.
 Users:
 		Userspace applications interested in knowing the
 		firmware assigned name of the PCI device.

 What:		/sys/bus/pci/devices/.../index
 Date:		July 2010
 Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
 Description:
 		Reading this attribute will provide the firmware
 		given instance (SMBIOS type 41 device type instance) of the
 		PCI device. The attribute will be created only if the firmware
 		has given an instance number to the PCI device.
 Users:
 		Userspace applications interested in knowing the
 		firmware assigned device type instance of the PCI
 		device that can help in understanding the firmware
 		intended order of the PCI device.

 What:		/sys/bus/pci/devices/.../acpi_index
 Date:		July 2010
 Contact:	Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
 Description:
 		Reading this attribute will provide the firmware
 		given instance (ACPI _DSM instance number) of the PCI device.
 		The attribute will be created only if the firmware has given
 		an instance number to the PCI device. ACPI _DSM instance number
 		will be given priority if the system firmware provides SMBIOS
 		type 41 device type instance also.
 Users:
 		Userspace applications interested in knowing the
 		firmware assigned instance number of the PCI
 		device that can help in understanding the firmware
 		intended order of the PCI device.

 What:		/sys/bus/pci/devices/.../d3cold_allowed
 Date:		July 2012
 Contact:	Huang Ying <ying.huang@intel.com>
 Description:
 		d3cold_allowed is bit to control whether the corresponding PCI
 		device can be put into D3Cold state.  If it is cleared, the
 		device will never be put into D3Cold state.  If it is set, the
 		device may be put into D3Cold state if other requirements are
 		satisfied too.  Reading this attribute will show the current
 		value of d3cold_allowed bit.  Writing this attribute will set
 		the value of d3cold_allowed bit.

 What:		/sys/bus/pci/devices/.../sriov_totalvfs
 Date:		November 2012
 Contact:	Donald Dutile <ddutile@redhat.com>
 Description:
 		This file appears when a physical PCIe device supports SR-IOV.
 		Userspace applications can read this file to determine the
 		maximum number of Virtual Functions (VFs) a PCIe physical
 		function (PF) can support. Typically, this is the value reported
 		in the PF's SR-IOV extended capability structure's TotalVFs
 		element.  Drivers have the ability at probe time to reduce the
 		value read from this file via the pci_sriov_set_totalvfs()
 		function.

 What:		/sys/bus/pci/devices/.../sriov_numvfs
 Date:		November 2012
 Contact:	Donald Dutile <ddutile@redhat.com>
 Description:
 		This file appears when a physical PCIe device supports SR-IOV.
 		Userspace applications can read and write to this file to
 		determine and control the enablement or disablement of Virtual
 		Functions (VFs) on the physical function (PF). A read of this
 		file will return the number of VFs that are enabled on this PF.
 		A number written to this file will enable the specified
 		number of VFs. A userspace application would typically read the
 		file and check that the value is zero, and then write the number
 		of VFs that should be enabled on the PF; the value written
 		should be less than or equal to the value in the sriov_totalvfs
 		file. A userspace application wanting to disable the VFs would
 		write a zero to this file. The core ensures that valid values
 		are written to this file, and returns errors when values are not
 		valid.  For example, writing a 2 to this file when sriov_numvfs
 		is not 0 and not 2 already will return an error. Writing a 10
 		when the value of sriov_totalvfs is 8 will return an error.
	What: /sys/bus/pci/drivers/.../bind
	Date: December 2003
	Contact: linux-pci@vger.kernel.org
	Description:
	Writing a device location to this file will cause
	the driver to attempt to bind to the device found at
	this location. This is useful for overriding default
	bindings. The format for the location is: DDDD:BB:DD.F.
	That is Domain:Bus:Device.Function and is the same as
	found in /sys/bus/pci/devices/. For example:
	# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind
	(Note: kernels before 2.6.28 may require echo -n).

	What: /sys/bus/pci/drivers/.../unbind
	Date: December 2003
	Contact: linux-pci@vger.kernel.org
	Description:
	Writing a device location to this file will cause the
	driver to attempt to unbind from the device found at
	this location. This may be useful when overriding default
	bindings. The format for the location is: DDDD:BB:DD.F.
	That is Domain:Bus:Device.Function and is the same as
	found in /sys/bus/pci/devices/. For example:
	# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
	(Note: kernels before 2.6.28 may require echo -n).

	What: /sys/bus/pci/drivers/.../new_id
	Date: December 2003
	Contact: linux-pci@vger.kernel.org
	Description:
	Writing a device ID to this file will attempt to
	dynamically add a new device ID to a PCI device driver.
	This may allow the driver to support more hardware than
	was included in the driver's static device ID support
	table at compile time. The format for the device ID is:
	VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID,
	Device ID, Subsystem Vendor ID, Subsystem Device ID,
	Class, Class Mask, and Private Driver Data. The Vendor ID
	and Device ID fields are required, the rest are optional.
	Upon successfully adding an ID, the driver will probe
	for the device and attempt to bind to it. For example:
	# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id

	What: /sys/bus/pci/drivers/.../remove_id
	Date: February 2009
	Contact: Chris Wright <chrisw@sous-sol.org>
	Description:
	Writing a device ID to this file will remove an ID
	that was dynamically added via the new_id sysfs entry.
	The format for the device ID is:
	VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device
	ID, Subsystem Vendor ID, Subsystem Device ID, Class,
	and Class Mask. The Vendor ID and Device ID fields are
	required, the rest are optional. After successfully
	removing an ID, the driver will no longer support the
	device. This is useful to ensure auto probing won't
	match the driver to the device. For example:
	# echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id

	What: /sys/bus/pci/rescan
	Date: January 2009
	Contact: Linux PCI developers <linux-pci@vger.kernel.org>
	Description:
	Writing a non-zero value to this attribute will
	force a rescan of all PCI buses in the system, and
	re-discover previously removed devices.

	What: /sys/bus/pci/devices/.../msi_irqs/
	Date: September, 2011
	Contact: Neil Horman <nhorman@tuxdriver.com>
	Description:
	The /sys/devices/.../msi_irqs directory contains a variable set
	of sub-directories, with each sub-directory being named after a
	corresponding msi irq vector allocated to that device. Each
	numbered sub-directory N contains attributes of that irq.
	Note that this directory is not created for device drivers which
	do not support msi irqs

	What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode
	Date: September 2011
	Contact: Neil Horman <nhorman@tuxdriver.com>
	Description:
	This attribute indicates the mode that the irq vector named by
	the parent directory is in (msi vs. msix)

	What: /sys/bus/pci/devices/.../remove
	Date: January 2009
	Contact: Linux PCI developers <linux-pci@vger.kernel.org>
	Description:
	Writing a non-zero value to this attribute will
	hot-remove the PCI device and any of its children.

	What: /sys/bus/pci/devices/.../pci_bus/.../rescan
	Date: May 2011
	Contact: Linux PCI developers <linux-pci@vger.kernel.org>
	Description:
	Writing a non-zero value to this attribute will
	force a rescan of the bus and all child buses,
	and re-discover devices removed earlier from this
	part of the device tree.

	What: /sys/bus/pci/devices/.../rescan
	Date: January 2009
	Contact: Linux PCI developers <linux-pci@vger.kernel.org>
	Description:
	Writing a non-zero value to this attribute will
	force a rescan of the device's parent bus and all
	child buses, and re-discover devices removed earlier
	from this part of the device tree.

	What: /sys/bus/pci/devices/.../reset
	Date: July 2009
	Contact: Michael S. Tsirkin <mst@redhat.com>
	Description:
	Some devices allow an individual function to be reset
	without affecting other functions in the same device.
	For devices that have this support, a file named reset
	will be present in sysfs. Writing 1 to this file
	will perform reset.

	What: /sys/bus/pci/devices/.../vpd
	Date: February 2008
	Contact: Ben Hutchings <bhutchings@solarflare.com>
	Description:
	A file named vpd in a device directory will be a
	binary file containing the Vital Product Data for the
	device. It should follow the VPD format defined in
	PCI Specification 2.1 or 2.2, but users should consider
	that some devices may have malformatted data. If the
	underlying VPD has a writable section then the
	corresponding section of this file will be writable.

	What: /sys/bus/pci/devices/.../virtfnN
	Date: March 2009
	Contact: Yu Zhao <yu.zhao@intel.com>
	Description:
	This symbolic link appears when hardware supports the SR-IOV
	capability and the Physical Function driver has enabled it.
	The symbolic link points to the PCI device sysfs entry of the
	Virtual Function whose index is N (0...MaxVFs-1).

	What: /sys/bus/pci/devices/.../dep_link
	Date: March 2009
	Contact: Yu Zhao <yu.zhao@intel.com>
	Description:
	This symbolic link appears when hardware supports the SR-IOV
	capability and the Physical Function driver has enabled it,
	and this device has vendor specific dependencies with others.
	The symbolic link points to the PCI device sysfs entry of
	Physical Function this device depends on.

	What: /sys/bus/pci/devices/.../physfn
	Date: March 2009
	Contact: Yu Zhao <yu.zhao@intel.com>
	Description:
	This symbolic link appears when a device is a Virtual Function.
	The symbolic link points to the PCI device sysfs entry of the
	Physical Function this device associates with.

	What: /sys/bus/pci/slots/.../module
	Date: June 2009
	Contact: linux-pci@vger.kernel.org
	Description:
	This symbolic link points to the PCI hotplug controller driver
	module that manages the hotplug slot.

	What: /sys/bus/pci/devices/.../label
	Date: July 2010
	Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
	Description:
	Reading this attribute will provide the firmware
	given name (SMBIOS type 41 string or ACPI _DSM string) of
	the PCI device. The attribute will be created only
	if the firmware has given a name to the PCI device.
	ACPI _DSM string name will be given priority if the
	system firmware provides SMBIOS type 41 string also.
	Users:
	Userspace applications interested in knowing the
	firmware assigned name of the PCI device.

	What: /sys/bus/pci/devices/.../index
	Date: July 2010
	Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
	Description:
	Reading this attribute will provide the firmware
	given instance (SMBIOS type 41 device type instance) of the
	PCI device. The attribute will be created only if the firmware
	has given an instance number to the PCI device.
	Users:
	Userspace applications interested in knowing the
	firmware assigned device type instance of the PCI
	device that can help in understanding the firmware
	intended order of the PCI device.

	What: /sys/bus/pci/devices/.../acpi_index
	Date: July 2010
	Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
	Description:
	Reading this attribute will provide the firmware
	given instance (ACPI _DSM instance number) of the PCI device.
	The attribute will be created only if the firmware has given
	an instance number to the PCI device. ACPI _DSM instance number
	will be given priority if the system firmware provides SMBIOS
	type 41 device type instance also.
	Users:
	Userspace applications interested in knowing the
	firmware assigned instance number of the PCI
	device that can help in understanding the firmware
	intended order of the PCI device.

	What: /sys/bus/pci/devices/.../d3cold_allowed
	Date: July 2012
	Contact: Huang Ying <ying.huang@intel.com>
	Description:
	d3cold_allowed is bit to control whether the corresponding PCI
	device can be put into D3Cold state. If it is cleared, the
	device will never be put into D3Cold state. If it is set, the
	device may be put into D3Cold state if other requirements are
	satisfied too. Reading this attribute will show the current
	value of d3cold_allowed bit. Writing this attribute will set
	the value of d3cold_allowed bit.

	What: /sys/bus/pci/devices/.../sriov_totalvfs
	Date: November 2012
	Contact: Donald Dutile <ddutile@redhat.com>
	Description:
	This file appears when a physical PCIe device supports SR-IOV.
	Userspace applications can read this file to determine the
	maximum number of Virtual Functions (VFs) a PCIe physical
	function (PF) can support. Typically, this is the value reported
	in the PF's SR-IOV extended capability structure's TotalVFs
	element. Drivers have the ability at probe time to reduce the
	value read from this file via the pci_sriov_set_totalvfs()
	function.

	What: /sys/bus/pci/devices/.../sriov_numvfs
	Date: November 2012
	Contact: Donald Dutile <ddutile@redhat.com>
	Description:
	This file appears when a physical PCIe device supports SR-IOV.
	Userspace applications can read and write to this file to
	determine and control the enablement or disablement of Virtual
	Functions (VFs) on the physical function (PF). A read of this
	file will return the number of VFs that are enabled on this PF.
	A number written to this file will enable the specified
	number of VFs. A userspace application would typically read the
	file and check that the value is zero, and then write the number
	of VFs that should be enabled on the PF; the value written
	should be less than or equal to the value in the sriov_totalvfs
	file. A userspace application wanting to disable the VFs would
	write a zero to this file. The core ensures that valid values
	are written to this file, and returns errors when values are not
	valid. For example, writing a 2 to this file when sriov_numvfs
	is not 0 and not 2 already will return an error. Writing a 10
	when the value of sriov_totalvfs is 8 will return an error.