Lines Matching +full:per +full:- +full:board

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.
36        The serial number should be unique per physical device.
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.
135 -------
140 --------
144 board.manufacture
145 -----------------
150 --
156 -------
159 keeping tasks, PHY control etc. but not the packet-by-packet data path
163 -----------
169 ------
171 Data path microcode controlling high-speed packet processing.
174 -------
179 -------
185 -------
188 parameters of a particular board, defined at manufacturing time.
191 -------
197 ------------
206  - on-disk firmware file names - drivers list the file names of firmware they
208    however, are per module, rather than per device. It'd be useful to list