Lines Matching +full:device +full:- +full:unique
1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
7 The ``devlink-info`` mechanism enables device drivers to report device
10 The original motivation for the ``devlink-info`` API was twofold:
12 - making it possible to automate device and firmware management in a fleet
13 of machines in a vendor-independent fashion (see also
14 :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`);
15 - name the per component FW versions (as opposed to the crowded ethtool
18 ``devlink-info`` supports reporting multiple types of objects. Reporting driver
19 versions is generally discouraged - here, and via any other Linux API.
21 .. list-table:: List of top level info objects
24 * - Name
25 - Description
26 * - ``driver``
27 - Name of the currently used device driver, also available through sysfs.
29 * - ``serial_number``
30 - Serial number of the device.
33 in PCI config space of the device in the *Device Serial Number*
36 The serial number should be unique per physical device.
37 Sometimes the serial number of the device is only 48 bits long (the
44 reported for two ports of the same device or on two hosts of
45 a multi-host device should be identical.
47 * - ``board.serial_number``
48 - Board serial number of the device.
53 * - ``fixed``
54 - Group for hardware identifiers, and versions of components
55 which are not field-updatable.
57 Versions in this section identify the device design. For example,
59 Data in ``devlink-info`` should be broken into the smallest logical
61 to form the Part Number string, while in ``devlink-info`` all parts
66 :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`
69 * - ``running``
70 - Group for information about currently running software/firmware.
71 These versions often only update after a reboot, sometimes device reset.
73 * - ``stored``
74 - Group for software/firmware versions in device flash.
77 if reboot has not yet occurred. If device is not capable of updating
83 ``stored`` sections, if device is capable of reporting ``stored`` versions
84 (see :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
94 driver authors should consult existing driver-specific versions and attempt
95 reuse. As last resort, if a component is truly unique, using driver-specific
96 names is allowed, but these should be documented in the driver-specific file.
100 .. list-table:: List of common version suffixes
103 * - Name
104 - Description
105 * - ``id``, ``revision``
106 - Identifiers of designs and revision, mostly used for hardware versions.
108 * - ``api``
109 - Version of API between components. API items are usually of limited
113 * - ``bundle_id``
114 - Identifier of a distribution package which was flashed onto the device.
117 :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
125 --------
127 Unique identifier of the board design.
130 ---------
135 -------
140 --------
145 -----------------
150 --
156 -------
159 keeping tasks, PHY control etc. but not the packet-by-packet data path
163 -----------
169 ------
171 Data path microcode controlling high-speed packet processing.
174 -------
179 -------
185 -------
187 Unique identifier of the firmware parameter set. These are usually
191 -------
197 ------------
199 Unique identifier of the entire firmware bundle.
206 - on-disk firmware file names - drivers list the file names of firmware they
208 however, are per module, rather than per device. It'd be useful to list
209 the names of firmware files the driver will try to load for a given device,