On Fri, 27 May 2022 09:27:47 +0200 Jiri Pirko wrote:

Okay. So the output of devlink dev info would be extended by
"components" nest. This nest would carry array of components which
contain versions. The name of the component is openin each array member
nest:

$ devlink dev info
pci/0000:01:00.0:
  driver mlxsw_spectrum2
  versions:
      fixed:
        hw.revision A0
        fw.psid MT_0000000199
      running:
        fw.version 29.2010.2302
        fw 29.2010.2302
  components:
    lc1:

Is the "lc1" free-form or generated by the core based on subobjects?
Is it carried as a string or object type + id?

I guess my suggestion of a CLI mockup has proven its weakness :)

      versions:
        fixed:
          hw.revision 0
          fw.psid MT_0000000111
        running:
          fw 19.2010.1310
          ini.version 4
    lc2:
      versions:
        fixed:
          hw.revision 0
          fw.psid MT_0000000111
        running:
          fw 19.2010.1310
          ini.version 4
    someothercomponentname:
      versions:
        running:
	   fw: 888

Now on top of exsisting "devlink dev flash" cmd without component, user
may specify the component name from the array above:

$ devlink dev flash pci/0000:01:00.0 component lc1 file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2

$ devlink dev flash pci/0000:01:00.0 component someothercomponentname file foo.bin

Note this is generic vehicle, line cards would benefit but it is usable
for multiple ASIC FW partitions for example.

Note that on "devlink dev flash" there is no change. This is implemented
currently. Only "devlink dev info" is extended to show the component
list.

I sort of assumed that the DEVLINK_ATTR_INFO_VERSION_NAME is the
component, the docs also use the word "component" for it. 

For the nfp for instance we had "fw.app" for the datapath microcode and
"fw.mgmt" for the control processor. These are separate partitions on
the flash. I don't think we ever implemented writing them separately
but it's certainly was our internal plan at some point.