| 1 | |
| 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 | Please note that any security versions reported via devlink are purely
|
| 90 | informational. Devlink does not use a secure channel to communicate with
|
| 91 | the device.
|
| 92 |
|
| 93 | Generic Versions
|
| 94 | ================
|
| 95 |
|
| 96 | It is expected that drivers use the following generic names for exporting
|
| 97 | version information. If a generic name for a given component doesn't exist yet,
|
| 98 | driver authors should consult existing driver-specific versions and attempt
|
| 99 | reuse. As last resort, if a component is truly unique, using driver-specific
|
| 100 | names is allowed, but these should be documented in the driver-specific file.
|
| 101 |
|
| 102 | All versions should try to use the following terminology:
|
| 103 |
|
| 104 | .. list-table:: List of common version suffixes
|
| 105 | :widths: 10 90
|
| 106 |
|
| 107 | * - Name
|
| 108 | - Description
|
| 109 | * - ``id``, ``revision``
|
| 110 | - Identifiers of designs and revision, mostly used for hardware versions.
|
| 111 |
|
| 112 | * - ``api``
|
| 113 | - Version of API between components. API items are usually of limited
|
| 114 | value to the user, and can be inferred from other versions by the vendor,
|
| 115 | so adding API versions is generally discouraged as noise.
|
| 116 |
|
| 117 | * - ``bundle_id``
|
| 118 | - Identifier of a distribution package which was flashed onto the device.
|
| 119 | This is an attribute of a firmware package which covers multiple versions
|
| 120 | for ease of managing firmware images (see
|
| 121 | :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
|
| 122 |
|
| 123 | ``bundle_id`` can appear in both ``running`` and ``stored`` versions,
|
| 124 | but it must not be reported if any of the components covered by the
|
| 125 | ``bundle_id`` was changed and no longer matches the version from
|
| 126 | the bundle.
|
| 127 |
|
| 128 | board.id
|
| 129 | --------
|
| 130 |
|
| 131 | Unique identifier of the board design.
|
| 132 |
|
| 133 | board.rev
|
| 134 | ---------
|
| 135 |
|
| 136 | Board design revision.
|
| 137 |
|
| 138 | asic.id
|
| 139 | -------
|
| 140 |
|
| 141 | ASIC design identifier.
|
| 142 |
|
| 143 | asic.rev
|
| 144 | --------
|
| 145 |
|
| 146 | ASIC design revision/stepping.
|
| 147 |
|
| 148 | board.manufacture
|
| 149 | -----------------
|
| 150 |
|
| 151 | An identifier of the company or the facility which produced the part.
|
| 152 |
|
| 153 | board.part_number
|
| 154 | -----------------
|
| 155 |
|
| 156 | Part number of the board and its components.
|
| 157 |
|
| 158 | fw
|
| 159 | --
|
| 160 |
|
| 161 | Overall firmware version, often representing the collection of
|
| 162 | fw.mgmt, fw.app, etc.
|
| 163 |
|
| 164 | fw.mgmt
|
| 165 | -------
|
| 166 |
|
| 167 | Control unit firmware version. This firmware is responsible for house
|
| 168 | keeping tasks, PHY control etc. but not the packet-by-packet data path
|
| 169 | operation.
|
| 170 |
|
| 171 | fw.mgmt.api
|
| 172 | -----------
|
| 173 |
|
| 174 | Firmware interface specification version of the software interfaces between
|
| 175 | driver and firmware.
|
| 176 |
|
| 177 | fw.app
|
| 178 | ------
|
| 179 |
|
| 180 | Data path microcode controlling high-speed packet processing.
|
| 181 |
|
| 182 | fw.undi
|
| 183 | -------
|
| 184 |
|
| 185 | UNDI software, may include the UEFI driver, firmware or both.
|
| 186 |
|
| 187 | fw.ncsi
|
| 188 | -------
|
| 189 |
|
| 190 | Version of the software responsible for supporting/handling the
|
| 191 | Network Controller Sideband Interface.
|
| 192 |
|
| 193 | fw.psid
|
| 194 | -------
|
| 195 |
|
| 196 | Unique identifier of the firmware parameter set. These are usually
|
| 197 | parameters of a particular board, defined at manufacturing time.
|
| 198 |
|
| 199 | fw.roce
|
| 200 | -------
|
| 201 |
|
| 202 | RoCE firmware version which is responsible for handling roce
|
| 203 | management.
|
| 204 |
|
| 205 | fw.bundle_id
|
| 206 | ------------
|
| 207 |
|
| 208 | Unique identifier of the entire firmware bundle.
|
| 209 |
|
| 210 | fw.bootloader
|
| 211 | -------------
|
| 212 |
|
| 213 | Version of the bootloader.
|
| 214 |
|
| 215 | Future work
|
| 216 | ===========
|
| 217 |
|
| 218 | The following extensions could be useful:
|
| 219 |
|
| 220 | - on-disk firmware file names - drivers list the file names of firmware they
|
| 221 | may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
|
| 222 | however, are per module, rather than per device. It'd be useful to list
|
| 223 | the names of firmware files the driver will try to load for a given device,
|
| 224 | in order of priority.
|