netdev - Re: [PATCH net-next v3 2/8] devlink: add version reporting to devlink info API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190131075737.GB2523@nanopsycho.orion>
Date:   Thu, 31 Jan 2019 08:57:37 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        oss-drivers@...ronome.com, andrew@...n.ch, f.fainelli@...il.com,
        mkubecek@...e.cz, eugenem@...com, jonathan.lemon@...il.com
Subject: Re: [PATCH net-next v3 2/8] devlink: add version reporting to
 devlink info API

Thu, Jan 31, 2019 at 12:41:27AM CET, jakub.kicinski@...ronome.com wrote:
>ethtool -i has a few fixed-size fields which can be used to report
>firmware version and expansion ROM version. Unfortunately, modern
>hardware has more firmware components. There is usually some
>datapath microcode, management controller, PXE drivers, and a
>CPLD load. Running ethtool -i on modern controllers reveals the
>fact that vendors cram multiple values into firmware version field.
>
>Here are some examples from systems I could lay my hands on quickly:
>
>tg3:  "FFV20.2.17 bc 5720-v1.39"
>i40e: "6.01 0x800034a4 1.1747.0"
>nfp:  "0.0.3.5 0.25 sriov-2.1.16 nic"
>
>Add a new devlink API to allow retrieving multiple versions, and
>provide user-readable name for those versions.
>
>While at it break down the versions into three categories:
> - fixed - this is the board/fixed component version, usually vendors
>           report information like the board version in the PCI VPD,
>           but it will benefit from naming and common API as well;
> - running - this is the running firmware version;
> - stored - this is firmware in the flash, after firmware update
>            this value will reflect the flashed version, while the
>            running version may only be updated after reboot.
>
>v3:
> - add per-type helpers instead of using the special argument (Jiri).
>RFCv2:
> - remove the nesting in attr DEVLINK_ATTR_INFO_VERSIONS (now
>   versions are mixed with other info attrs)l
> - have the driver report versions from the same callback as
>   other info.
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>

Acked-by: Jiri Pirko <jiri@...lanox.com>