1.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
2
3============
4Devlink Info
5============
6
7The ``devlink-info`` mechanism enables device drivers to report device
8(hardware and firmware) information in a standard, extensible fashion.
9
10The original motivation for the ``devlink-info`` API was twofold:
11
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
16   version string).
17
18``devlink-info`` supports reporting multiple types of objects. Reporting driver
19versions is generally discouraged - here, and via any other Linux API.
20
21.. list-table:: List of top level info objects
22   :widths: 5 95
23
24   * - Name
25     - Description
26   * - ``driver``
27     - Name of the currently used device driver, also available through sysfs.
28
29   * - ``serial_number``
30     - Serial number of the device.
31
32       This is usually the serial number of the ASIC, also often available
33       in PCI config space of the device in the *Device Serial Number*
34       capability.
35
36       The serial number should be unique per physical device.
37       Sometimes the serial number of the device is only 48 bits long (the
38       length of the Ethernet MAC address), and since PCI DSN is 64 bits long
39       devices pad or encode additional information into the serial number.
40       One example is adding port ID or PCI interface ID in the extra two bytes.
41       Drivers should make sure to strip or normalize any such padding
42       or interface ID, and report only the part of the serial number
43       which uniquely identifies the hardware. In other words serial number
44       reported for two ports of the same device or on two hosts of
45       a multi-host device should be identical.
46
47   * - ``board.serial_number``
48     - Board serial number of the device.
49
50       This is usually the serial number of the board, often available in
51       PCI *Vital Product Data*.
52
53   * - ``fixed``
54     - Group for hardware identifiers, and versions of components
55       which are not field-updatable.
56
57       Versions in this section identify the device design. For example,
58       component identifiers or the board version reported in the PCI VPD.
59       Data in ``devlink-info`` should be broken into the smallest logical
60       components, e.g. PCI VPD may concatenate various information
61       to form the Part Number string, while in ``devlink-info`` all parts
62       should be reported as separate items.
63
64       This group must not contain any frequently changing identifiers,
65       such as serial numbers. See
66       :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`
67       to understand why.
68
69   * - ``running``
70     - Group for information about currently running software/firmware.
71       These versions often only update after a reboot, sometimes device reset.
72
73   * - ``stored``
74     - Group for software/firmware versions in device flash.
75
76       Stored values must update to reflect changes in the flash even
77       if reboot has not yet occurred. If device is not capable of updating
78       ``stored`` versions when new software is flashed, it must not report
79       them.
80
81Each version can be reported at most once in each version group. Firmware
82components stored on the flash should feature in both the ``running`` and
83``stored`` sections, if device is capable of reporting ``stored`` versions
84(see :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
85In case software/firmware components are loaded from the disk (e.g.
86``/lib/firmware``) only the running version should be reported via
87the kernel API.
88
89Generic Versions
90================
91
92It is expected that drivers use the following generic names for exporting
93version information. If a generic name for a given component doesn't exist yet,
94driver authors should consult existing driver-specific versions and attempt
95reuse. As last resort, if a component is truly unique, using driver-specific
96names is allowed, but these should be documented in the driver-specific file.
97
98All versions should try to use the following terminology:
99
100.. list-table:: List of common version suffixes
101   :widths: 10 90
102
103   * - Name
104     - Description
105   * - ``id``, ``revision``
106     - Identifiers of designs and revision, mostly used for hardware versions.
107
108   * - ``api``
109     - Version of API between components. API items are usually of limited
110       value to the user, and can be inferred from other versions by the vendor,
111       so adding API versions is generally discouraged as noise.
112
113   * - ``bundle_id``
114     - Identifier of a distribution package which was flashed onto the device.
115       This is an attribute of a firmware package which covers multiple versions
116       for ease of managing firmware images (see
117       :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
118
119       ``bundle_id`` can appear in both ``running`` and ``stored`` versions,
120       but it must not be reported if any of the components covered by the
121       ``bundle_id`` was changed and no longer matches the version from
122       the bundle.
123
124board.id
125--------
126
127Unique identifier of the board design.
128
129board.rev
130---------
131
132Board design revision.
133
134asic.id
135-------
136
137ASIC design identifier.
138
139asic.rev
140--------
141
142ASIC design revision/stepping.
143
144board.manufacture
145-----------------
146
147An identifier of the company or the facility which produced the part.
148
149fw
150--
151
152Overall firmware version, often representing the collection of
153fw.mgmt, fw.app, etc.
154
155fw.mgmt
156-------
157
158Control unit firmware version. This firmware is responsible for house
159keeping tasks, PHY control etc. but not the packet-by-packet data path
160operation.
161
162fw.mgmt.api
163-----------
164
165Firmware interface specification version of the software interfaces between
166driver and firmware.
167
168fw.app
169------
170
171Data path microcode controlling high-speed packet processing.
172
173fw.undi
174-------
175
176UNDI software, may include the UEFI driver, firmware or both.
177
178fw.ncsi
179-------
180
181Version of the software responsible for supporting/handling the
182Network Controller Sideband Interface.
183
184fw.psid
185-------
186
187Unique identifier of the firmware parameter set. These are usually
188parameters of a particular board, defined at manufacturing time.
189
190fw.roce
191-------
192
193RoCE firmware version which is responsible for handling roce
194management.
195
196fw.bundle_id
197------------
198
199Unique identifier of the entire firmware bundle.
200
201fw.bootloader
202-------------
203
204Version of the bootloader.
205
206Future work
207===========
208
209The following extensions could be useful:
210
211 - on-disk firmware file names - drivers list the file names of firmware they
212   may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
213   however, are per module, rather than per device. It'd be useful to list
214   the names of firmware files the driver will try to load for a given device,
215   in order of priority.
216