The Linux Kernel Logo
  • Development process
  • Submitting patches
  • Code of conduct
  • Maintainer handbook
  • All development-process docs
  • Core API
  • Driver APIs
  • Subsystems
    • Core subsystems
    • Human interfaces
    • Networking interfaces
      • Networking
        • AF_XDP
        • Bare UDP Tunnelling Module Documentation
        • batman-adv
        • SocketCAN - Controller Area Network
        • The UCAN Protocol
        • Hardware Device Drivers
        • Networking Diagnostics
        • Distributed Switch Architecture
        • Linux Devlink Documentation
          • Locking
          • Nested instances
          • Interface documentation
            • Devlink DPIPE
            • Devlink Health
            • Devlink Info
              • Generic Versions
                • board.id
                • board.rev
                • asic.id
                • asic.rev
                • board.manufacture
                • board.part_number
                • fw
                • fw.mgmt
                • fw.mgmt.api
                • fw.app
                • fw.undi
                • fw.ncsi
                • fw.psid
                • fw.roce
                • fw.bundle_id
                • fw.bootloader
              • Future work
            • Devlink Flash
            • Devlink Params
            • Devlink Port
            • Devlink Region
            • Devlink Resource
            • Devlink Reload
            • Devlink Selftests
            • Devlink Trap
            • Devlink Line card
            • Devlink E-Switch Attribute
          • Driver-specific documentation
        • CAIF
        • Netlink interface for ethtool
        • IEEE 802.15.4 Developer’s Guide
        • ISO 15765-2 (ISO-TP)
        • J1939 Documentation
        • Linux Networking and Network Devices APIs
        • MSG_ZEROCOPY
        • FAILOVER
        • Net DIM - Generic Network Dynamic Interrupt Moderation
        • NET_FAILOVER
        • Page Pool API
        • PHY Abstraction Layer
        • phylink
        • IP-Aliasing
        • Ethernet Bridging
        • SNMP counter
        • Checksum Offloads
        • Segmentation Offloads
        • Scaling in the Linux Networking Stack
        • Kernel TLS
        • Kernel TLS offload
        • In-Kernel TLS Handshake
        • Linux NFC subsystem
        • Netdev private dataroom for 6lowpan interfaces
        • 6pack Protocol
        • ARCnet Hardware
        • ARCnet
        • ATM
        • AX.25
        • Linux Ethernet Bonding Driver HOWTO
        • cdc_mbim - Driver for CDC MBIM Mobile Broadband modems
        • DCCP protocol
        • DCTCP (DataCenter TCP)
        • Device Memory TCP
        • DNS Resolver Module
        • Softnet Driver Issues
        • EQL Driver: Serial IP Load Balancing HOWTO
        • LC-trie implementation notes
        • Linux Socket Filtering aka Berkeley Packet Filter (BPF)
        • Generic HDLC layer
        • Generic Netlink
        • Netlink Family Specifications
        • Generic networking statistics for netlink users
        • The Linux kernel GTP tunneling module
        • Identifier Locator Addressing (ILA)
        • IOAM6 Sysfs variables
        • io_uring zero copy Rx
        • IP dynamic address hack-port v0.03
        • IPsec
        • IP Sysctl
        • IPv6
        • IPVLAN Driver HOWTO
        • IPvs-sysctl
        • Kernel Connection Multiplexor
        • L2TP
        • The Linux LAPB Module Interface
        • How to use packet injection with mac80211
        • Management Component Transport Protocol (MCTP)
        • MPLS Sysfs variables
        • Multipath TCP (MPTCP)
        • MPTCP Sysfs variables
        • HOWTO for multiqueue network device support
        • Multi-PF Netdev
        • NAPI
        • Common Networking Struct Cachelines
        • Netconsole
        • Netdev features mess and how to get out from it alive
        • Network Devices, the Kernel, and You!
        • Netfilter Sysfs variables
        • NETIF Msg Level
        • Netmem Support for Network Drivers
        • Resilient Next-hop Groups
        • Netfilter Conntrack Sysfs variables
        • Netfilter’s flowtable infrastructure
        • OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface (TC6) Framework Support
        • Open vSwitch datapath developer documentation
        • Operational States
        • Packet MMAP
        • Linux Phonet protocol family
        • PHY link topology
        • HOWTO for the linux packet generator
        • PLIP: The Parallel Line Internet Protocol Device
        • PPP Generic Driver and Channel Interface
        • The proc/net/tcp and proc/net/tcp6 variables
        • Power Sourcing Equipment (PSE) Documentation
        • How to use radiotap headers
        • RDS
        • Linux wireless regulatory documentation
        • Network Function Representors
        • RxRPC Network Protocol
        • SOCKET OPTIONS
        • SECURITY
        • EXAMPLE CLIENT USAGE
        • Linux Kernel SCTP
        • LSM/SeLinux secid
        • Seg6 Sysfs variables
        • struct sk_buff
        • SMC Sysctl
        • NIC SR-IOV APIs
        • Interface statistics
        • Stream Parser (strparser)
        • Ethernet switch device driver model (switchdev)
        • Sysfs tagging
        • TC Actions - Environmental Rules
        • TC queue based filtering
        • TCP Authentication Option Linux implementation (RFC5925)
        • Thin-streams and TCP
        • Team
        • Timestamping
        • Linux Kernel TIPC
        • Transparent proxy support
        • Universal TUN/TAP device driver
        • The UDP-Lite protocol (RFC 3828)
        • Virtual Routing and Forwarding (VRF)
        • Virtual eXtensible Local Area Networking documentation
        • Linux X.25 Project
        • X.25 Device Driver Interface
        • XFRM device - offloading the IPsec computations
        • XFRM proc - /proc/net/xfrm_* files
        • XFRM
        • XFRM Syscall
        • XDP RX Metadata
        • AF_XDP TX Metadata
      • NetLabel
      • InfiniBand
      • ISDN
      • MHI
    • Storage interfaces
    • Other subsystems
  • Locking
  • Licensing rules
  • Writing documentation
  • Development tools
  • Testing guide
  • Hacking guide
  • Tracing
  • Fault injection
  • Livepatching
  • Rust
  • Administration
  • Build system
  • Reporting issues
  • Userspace tools
  • Userspace API
  • Firmware
  • Firmware and Devicetree
  • CPU architectures
  • Unsorted documentation
  • Translations
The Linux Kernel
  • Kernel subsystem documentation
  • Networking
  • Linux Devlink Documentation
  • Devlink Info
  • View page source

Devlink Info¶

The devlink-info mechanism enables device drivers to report device (hardware and firmware) information in a standard, extensible fashion.

The original motivation for the devlink-info API was twofold:

  • making it possible to automate device and firmware management in a fleet of machines in a vendor-independent fashion (see also Documentation/networking/devlink/devlink-flash.rst);

  • name the per component FW versions (as opposed to the crowded ethtool version string).

devlink-info supports reporting multiple types of objects. Reporting driver versions is generally discouraged - here, and via any other Linux API.

List of top level info objects¶

Name

Description

driver

Name of the currently used device driver, also available through sysfs.

serial_number

Serial number of the device.

This is usually the serial number of the ASIC, also often available in PCI config space of the device in the Device Serial Number capability.

The serial number should be unique per physical device. Sometimes the serial number of the device is only 48 bits long (the length of the Ethernet MAC address), and since PCI DSN is 64 bits long devices pad or encode additional information into the serial number. One example is adding port ID or PCI interface ID in the extra two bytes. Drivers should make sure to strip or normalize any such padding or interface ID, and report only the part of the serial number which uniquely identifies the hardware. In other words serial number reported for two ports of the same device or on two hosts of a multi-host device should be identical.

board.serial_number

Board serial number of the device.

This is usually the serial number of the board, often available in PCI Vital Product Data.

fixed

Group for hardware identifiers, and versions of components which are not field-updatable.

Versions in this section identify the device design. For example, component identifiers or the board version reported in the PCI VPD. Data in devlink-info should be broken into the smallest logical components, e.g. PCI VPD may concatenate various information to form the Part Number string, while in devlink-info all parts should be reported as separate items.

This group must not contain any frequently changing identifiers, such as serial numbers. See Documentation/networking/devlink/devlink-flash.rst to understand why.

running

Group for information about currently running software/firmware. These versions often only update after a reboot, sometimes device reset.

stored

Group for software/firmware versions in device flash.

Stored values must update to reflect changes in the flash even if reboot has not yet occurred. If device is not capable of updating stored versions when new software is flashed, it must not report them.

Each version can be reported at most once in each version group. Firmware components stored on the flash should feature in both the running and stored sections, if device is capable of reporting stored versions (see Documentation/networking/devlink/devlink-flash.rst). In case software/firmware components are loaded from the disk (e.g. /lib/firmware) only the running version should be reported via the kernel API.

Generic Versions¶

It is expected that drivers use the following generic names for exporting version information. If a generic name for a given component doesn’t exist yet, driver authors should consult existing driver-specific versions and attempt reuse. As last resort, if a component is truly unique, using driver-specific names is allowed, but these should be documented in the driver-specific file.

All versions should try to use the following terminology:

List of common version suffixes¶

Name

Description

id, revision

Identifiers of designs and revision, mostly used for hardware versions.

api

Version of API between components. API items are usually of limited value to the user, and can be inferred from other versions by the vendor, so adding API versions is generally discouraged as noise.

bundle_id

Identifier of a distribution package which was flashed onto the device. This is an attribute of a firmware package which covers multiple versions for ease of managing firmware images (see Documentation/networking/devlink/devlink-flash.rst).

bundle_id can appear in both running and stored versions, but it must not be reported if any of the components covered by the bundle_id was changed and no longer matches the version from the bundle.

board.id¶

Unique identifier of the board design.

board.rev¶

Board design revision.

asic.id¶

ASIC design identifier.

asic.rev¶

ASIC design revision/stepping.

board.manufacture¶

An identifier of the company or the facility which produced the part.

board.part_number¶

Part number of the board and its components.

fw¶

Overall firmware version, often representing the collection of fw.mgmt, fw.app, etc.

fw.mgmt¶

Control unit firmware version. This firmware is responsible for house keeping tasks, PHY control etc. but not the packet-by-packet data path operation.

fw.mgmt.api¶

Firmware interface specification version of the software interfaces between driver and firmware.

fw.app¶

Data path microcode controlling high-speed packet processing.

fw.undi¶

UNDI software, may include the UEFI driver, firmware or both.

fw.ncsi¶

Version of the software responsible for supporting/handling the Network Controller Sideband Interface.

fw.psid¶

Unique identifier of the firmware parameter set. These are usually parameters of a particular board, defined at manufacturing time.

fw.roce¶

RoCE firmware version which is responsible for handling roce management.

fw.bundle_id¶

Unique identifier of the entire firmware bundle.

fw.bootloader¶

Version of the bootloader.

Future work¶

The following extensions could be useful:

  • on-disk firmware file names - drivers list the file names of firmware they may need to load onto devices via the MODULE_FIRMWARE() macro. These, however, are per module, rather than per device. It’d be useful to list the names of firmware files the driver will try to load for a given device, in order of priority.

Previous Next

© Copyright The kernel development community.

Built with Sphinx using a theme provided by Read the Docs.