tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
devlink: expand the devlink-info documentation
We are having multiple review cycles with all vendors trying
to implement devlink-info. Let's expand the documentation with
more information about what's implemented and motivation behind
this interface in an attempt to make the implementations easier.
Describe what each info section is supposed to contain, and make
some references to other HW interfaces (PCI caps).
Document how firmware management is expected to look, to make
it clear how devlink-info and devlink-flash work in concert.
Name some future work.
v2: - improve wording
v3: - improve wording
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
authored by
Jakub Kicinski
and committed by
David S. Miller
cd556e40
2283a02b
+213
-16
+93
Documentation/networking/devlink/devlink-flash.rst
+93
Documentation/networking/devlink/devlink-flash.rst
···
1
+
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
2
+
3
+
.. _devlink_flash:
4
+
5
+
=============
6
+
Devlink Flash
7
+
=============
8
+
9
+
The ``devlink-flash`` API allows updating device firmware. It replaces the
10
+
older ``ethtool-flash`` mechanism, and doesn't require taking any
11
+
networking locks in the kernel to perform the flash update. Example use::
12
+
13
+
$ devlink dev flash pci/0000:05:00.0 file flash-boot.bin
14
+
15
+
Note that the file name is a path relative to the firmware loading path
16
+
(usually ``/lib/firmware/``). Drivers may send status updates to inform
17
+
user space about the progress of the update operation.
18
+
19
+
Firmware Loading
20
+
================
21
+
22
+
Devices which require firmware to operate usually store it in non-volatile
23
+
memory on the board, e.g. flash. Some devices store only basic firmware on
24
+
the board, and the driver loads the rest from disk during probing.
25
+
``devlink-info`` allows users to query firmware information (loaded
26
+
components and versions).
27
+
28
+
In other cases the device can both store the image on the board, load from
29
+
disk, or automatically flash a new image from disk. The ``fw_load_policy``
30
+
devlink parameter can be used to control this behavior
31
+
(:ref:`Documentation/networking/devlink/devlink-params.rst <devlink_params_generic>`).
32
+
33
+
On-disk firmware files are usually stored in ``/lib/firmware/``.
34
+
35
+
Firmware Version Management
36
+
===========================
37
+
38
+
Drivers are expected to implement ``devlink-flash`` and ``devlink-info``
39
+
functionality, which together allow for implementing vendor-independent
40
+
automated firmware update facilities.
41
+
42
+
``devlink-info`` exposes the ``driver`` name and three version groups
43
+
(``fixed``, ``running``, ``stored``).
44
+
45
+
The ``driver`` attribute and ``fixed`` group identify the specific device
46
+
design, e.g. for looking up applicable firmware updates. This is why
47
+
``serial_number`` is not part of the ``fixed`` versions (even though it
48
+
is fixed) - ``fixed`` versions should identify the design, not a single
49
+
device.
50
+
51
+
``running`` and ``stored`` firmware versions identify the firmware running
52
+
on the device, and firmware which will be activated after reboot or device
53
+
reset.
54
+
55
+
The firmware update agent is supposed to be able to follow this simple
56
+
algorithm to update firmware contents, regardless of the device vendor:
57
+
58
+
.. code-block:: sh
59
+
60
+
# Get unique HW design identifier
61
+
$hw_id = devlink-dev-info['fixed']
62
+
63
+
# Find out which FW flash we want to use for this NIC
64
+
$want_flash_vers = some-db-backed.lookup($hw_id, 'flash')
65
+
66
+
# Update flash if necessary
67
+
if $want_flash_vers != devlink-dev-info['stored']:
68
+
$file = some-db-backed.download($hw_id, 'flash')
69
+
devlink-dev-flash($file)
70
+
71
+
# Find out the expected overall firmware versions
72
+
$want_fw_vers = some-db-backed.lookup($hw_id, 'all')
73
+
74
+
# Update on-disk file if necessary
75
+
if $want_fw_vers != devlink-dev-info['running']:
76
+
$file = some-db-backed.download($hw_id, 'disk')
77
+
write($file, '/lib/firmware/')
78
+
79
+
# Try device reset, if available
80
+
if $want_fw_vers != devlink-dev-info['running']:
81
+
devlink-reset()
82
+
83
+
# Reboot, if reset wasn't enough
84
+
if $want_fw_vers != devlink-dev-info['running']:
85
+
reboot()
86
+
87
+
Note that each reference to ``devlink-dev-info`` in this pseudo-code
88
+
is expected to fetch up-to-date information from the kernel.
89
+
90
+
For the convenience of identifying firmware files some vendors add
91
+
``bundle_id`` information to the firmware versions. This meta-version covers
92
+
multiple per-component versions and can be used e.g. in firmware file names
93
+
(all component versions could get rather long.)
+117
-16
Documentation/networking/devlink/devlink-info.rst
+117
-16
Documentation/networking/devlink/devlink-info.rst
···
5
5
============
6
6
7
7
The ``devlink-info`` mechanism enables device drivers to report device
8
-
information in a generic fashion. It is extensible, and enables exporting
9
-
even device or driver specific information.
8
+
(hardware and firmware) information in a standard, extensible fashion.
10
9
11
-
devlink supports representing the following types of versions
10
+
The original motivation for the ``devlink-info`` API was twofold:
12
11
13
-
.. list-table:: List of version types
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
14
22
:widths: 5 95
15
23
16
-
* - Type
24
+
* - Name
17
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
+
.. note:: ``devlink-info`` API should be extended with a new field
48
+
if devices want to report board/product serial number (often
49
+
reported in PCI *Vital Product Data* capability).
50
+
18
51
* - ``fixed``
19
-
- Represents fixed versions, which cannot change. For example,
52
+
- Group for hardware identifiers, and versions of components
53
+
which are not field-updatable.
54
+
55
+
Versions in this section identify the device design. For example,
20
56
component identifiers or the board version reported in the PCI VPD.
57
+
Data in ``devlink-info`` should be broken into the smallest logical
58
+
components, e.g. PCI VPD may concatenate various information
59
+
to form the Part Number string, while in ``devlink-info`` all parts
60
+
should be reported as separate items.
61
+
62
+
This group must not contain any frequently changing identifiers,
63
+
such as serial numbers. See
64
+
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`
65
+
to understand why.
66
+
21
67
* - ``running``
22
-
- Represents the version of the currently running component. For
23
-
example the running version of firmware. These versions generally
24
-
only update after a reboot.
68
+
- Group for information about currently running software/firmware.
69
+
These versions often only update after a reboot, sometimes device reset.
70
+
25
71
* - ``stored``
26
-
- Represents the version of a component as stored, such as after a
27
-
flash update. Stored values should update to reflect changes in the
28
-
flash even if a reboot has not yet occurred.
72
+
- Group for software/firmware versions in device flash.
73
+
74
+
Stored values must update to reflect changes in the flash even
75
+
if reboot has not yet occurred. If device is not capable of updating
76
+
``stored`` versions when new software is flashed, it must not report
77
+
them.
78
+
79
+
Each version can be reported at most once in each version group. Firmware
80
+
components stored on the flash should feature in both the ``running`` and
81
+
``stored`` sections, if device is capable of reporting ``stored`` versions
82
+
(see :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
83
+
In case software/firmware components are loaded from the disk (e.g.
84
+
``/lib/firmware``) only the running version should be reported via
85
+
the kernel API.
29
86
30
87
Generic Versions
31
88
================
32
89
33
90
It is expected that drivers use the following generic names for exporting
34
-
version information. Other information may be exposed using driver-specific
35
-
names, but these should be documented in the driver-specific file.
91
+
version information. If a generic name for a given component doesn't exist yet,
92
+
driver authors should consult existing driver-specific versions and attempt
93
+
reuse. As last resort, if a component is truly unique, using driver-specific
94
+
names is allowed, but these should be documented in the driver-specific file.
95
+
96
+
All versions should try to use the following terminology:
97
+
98
+
.. list-table:: List of common version suffixes
99
+
:widths: 10 90
100
+
101
+
* - Name
102
+
- Description
103
+
* - ``id``, ``revision``
104
+
- Identifiers of designs and revision, mostly used for hardware versions.
105
+
106
+
* - ``api``
107
+
- Version of API between components. API items are usually of limited
108
+
value to the user, and can be inferred from other versions by the vendor,
109
+
so adding API versions is generally discouraged as noise.
110
+
111
+
* - ``bundle_id``
112
+
- Identifier of a distribution package which was flashed onto the device.
113
+
This is an attribute of a firmware package which covers multiple versions
114
+
for ease of managing firmware images (see
115
+
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
116
+
117
+
``bundle_id`` can appear in both ``running`` and ``stored`` versions,
118
+
but it must not be reported if any of the components covered by the
119
+
``bundle_id`` was changed and no longer matches the version from
120
+
the bundle.
36
121
37
122
board.id
38
123
--------
···
137
52
asic.rev
138
53
--------
139
54
140
-
ASIC design revision.
55
+
ASIC design revision/stepping.
141
56
142
57
board.manufacture
143
58
-----------------
···
176
91
fw.psid
177
92
-------
178
93
179
-
Unique identifier of the firmware parameter set.
94
+
Unique identifier of the firmware parameter set. These are usually
95
+
parameters of a particular board, defined at manufacturing time.
180
96
181
97
fw.roce
182
98
-------
···
189
103
------------
190
104
191
105
Unique identifier of the entire firmware bundle.
106
+
107
+
Future work
108
+
===========
109
+
110
+
The following extensions could be useful:
111
+
112
+
- product serial number - NIC boards often get labeled with a board serial
113
+
number rather than ASIC serial number; it'd be useful to add board serial
114
+
numbers to the API if they can be retrieved from the device;
115
+
116
+
- on-disk firmware file names - drivers list the file names of firmware they
117
+
may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
118
+
however, are per module, rather than per device. It'd be useful to list
119
+
the names of firmware files the driver will try to load for a given device,
120
+
in order of priority.
+2
Documentation/networking/devlink/devlink-params.rst
+2
Documentation/networking/devlink/devlink-params.rst
···
41
41
support reloading via the ``devlink-reload`` command. This command will
42
42
request a reload of the device driver.
43
43
44
+
.. _devlink_params_generic:
45
+
44
46
Generic configuration parameters
45
47
================================
46
48
The following is a list of generic configuration parameters that drivers may