networking/devlink/devlink-info.rst

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.
40        One example is adding port ID or PCI interface ID in the extra two bytes.
42        or interface ID, and report only the part of the serial number
45        a multi-host device should be identical.
47    * - ``board.serial_number``
48      - Board serial number of the device.
50        This is usually the serial number of the board, often available in
53    * - ``fixed``
54      - Group for hardware identifiers, and versions of components
55        which are not field-updatable.
58        component identifiers or the board version reported in the PCI VPD.
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.
73    * - ``stored``
74      - Group for software/firmware versions in device flash.
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>`).
124 board.id
125 --------
127 Unique identifier of the board design.
129 board.rev
130 ---------
132 Board design revision.
134 asic.id
135 -------
140 --------
144 board.manufacture
145 -----------------
149 board.part_number
150 -----------------
152 Part number of the board and its components.
155 --
161 -------
164 keeping tasks, PHY control etc. but not the packet-by-packet data path
168 -----------
174 ------
176 Data path microcode controlling high-speed packet processing.
179 -------
184 -------
190 -------
193 parameters of a particular board, defined at manufacturing time.
196 -------
202 ------------
207 -------------
216  - on-disk firmware file names - drivers list the file names of firmware they