About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / ABI / testing / sysfs-bus-pci




Custom Search

Based on kernel version 3.15.4. Page generated on 2014-07-07 08:59 EST.

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.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.