Thu, Jan 31, 2019 at 12:41:27AM CET, [email protected] 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 <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
