Documentation/networking/devlink/devlink-info.rst

   1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
   2
   3 ============
   4 Devlink Info
   5 ============
   6
   7 The ``devlink-info`` mechanism enables device drivers to report device
   8 (hardware and firmware) information in a standard, extensible fashion.
   9
  10 The 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
  19 versions 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
  81 Each version can be reported at most once in each version group. Firmware
  82 components 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>`).
  85 In case software/firmware components are loaded from the disk (e.g.
  86 ``/lib/firmware``) only the running version should be reported via
  87 the kernel API.
  88
  89 Generic Versions
  90 ================
  91
  92 It is expected that drivers use the following generic names for exporting
  93 version information. If a generic name for a given component doesn't exist yet,
  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.
  97
  98 All 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
 124 board.id
 125 --------
 126
 127 Unique identifier of the board design.
 128
 129 board.rev
 130 ---------
 131
 132 Board design revision.
 133
 134 asic.id
 135 -------
 136
 137 ASIC design identifier.
 138
 139 asic.rev
 140 --------
 141
 142 ASIC design revision/stepping.
 143
 144 board.manufacture
 145 -----------------
 146
 147 An identifier of the company or the facility which produced the part.
 148
 149 board.part_number
 150 -----------------
 151
 152 Part number of the board and its components.
 153
 154 fw
 155 --
 156
 157 Overall firmware version, often representing the collection of
 158 fw.mgmt, fw.app, etc.
 159
 160 fw.mgmt
 161 -------
 162
 163 Control unit firmware version. This firmware is responsible for house
 164 keeping tasks, PHY control etc. but not the packet-by-packet data path
 165 operation.
 166
 167 fw.mgmt.api
 168 -----------
 169
 170 Firmware interface specification version of the software interfaces between
 171 driver and firmware.
 172
 173 fw.app
 174 ------
 175
 176 Data path microcode controlling high-speed packet processing.
 177
 178 fw.undi
 179 -------
 180
 181 UNDI software, may include the UEFI driver, firmware or both.
 182
 183 fw.ncsi
 184 -------
 185
 186 Version of the software responsible for supporting/handling the
 187 Network Controller Sideband Interface.
 188
 189 fw.psid
 190 -------
 191
 192 Unique identifier of the firmware parameter set. These are usually
 193 parameters of a particular board, defined at manufacturing time.
 194
 195 fw.roce
 196 -------
 197
 198 RoCE firmware version which is responsible for handling roce
 199 management.
 200
 201 fw.bundle_id
 202 ------------
 203
 204 Unique identifier of the entire firmware bundle.
 205
 206 fw.bootloader
 207 -------------
 208
 209 Version of the bootloader.
 210
 211 Future work
 212 ===========
 213
 214 The following extensions could be useful:
 215
 216  - on-disk firmware file names - drivers list the file names of firmware they
 217    may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
 218    however, are per module, rather than per device. It'd be useful to list
 219    the names of firmware files the driver will try to load for a given device,
 220    in order of priority.