netdev - Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices and info

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]

Date:   Tue, 24 May 2022 16:31:45 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Ido Schimmel <idosch@...sch.org>, Ido Schimmel <idosch@...dia.com>,
        netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        jiri@...dia.com, petrm@...dia.com, dsahern@...il.com,
        andrew@...n.ch, mlxsw@...dia.com
Subject: Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices
 and info

Tue, May 24, 2022 at 08:46:38AM CEST, jiri@...nulli.us wrote:
>Mon, May 23, 2022 at 07:56:40PM CEST, kuba@...nel.org wrote:
>>On Mon, 23 May 2022 11:42:07 +0200 Jiri Pirko wrote:
>>> Mon, May 02, 2022 at 04:39:33PM CEST, kuba@...nel.org wrote:
>>> >On Sat, 30 Apr 2022 08:27:35 +0200 Jiri Pirko wrote:  
>>> >> Now I just want to use this component name to target individual line
>>> >> cards. I see it is a nice fit. Don't you think?  
>>> >
>>> >Still on the fence.  
>>> 
>>> Why?
>>
>>IIRC my concern was mixing objects. We have component name coming from
>>lc info, but then use it in dev flash.
>
>Sure. I considered that. The thing is, even if you put the lc component
>names to output of "devlink dev info", you would need to provide lc
>objects as well (somehow) - to contain the versions.
>
>But the component name is related to lc object listed in "devlink lc",
>so "devlink lc info" sounds line the correct place to put it.
>
>If you are concern about "devlink dev flash" using component name from
>"devlink lc info", I would rather introduce "devlink lc flash" so you
>have a match. But from what I see, I don't really see the necessity for
>this match. Do you?

Okay, we can eventually avoid using component name at all for now,
considering one flash object per linecard (with possibility to extend by
component later on). This would look like:

$ devlink lc info pci/0000:01:00.0 lc 8
pci/0000:01:00.0:
  lc 8
    versions:
        fixed:
          hw.revision 0
	  fw.psid MT_0000000749
        running:
          ini.version 4
          fw 19.2010.1310

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

I have to admit I like this.
We would reuse the existing DEVLINK_CMD_FLASH_UPDATE cmd and when
DEVLINK_ATTR_LINECARD_INDEX attribute is present, we call the lc-flash
op. How does this sound?


>
>
>>
>>> >> I see that the manpage is mentioning "the component names from devlink dev info"
>>> >> which is not actually implemented, but exactly what I proposed.  
>>> >
>>> >How do you tie the line card to the component name? lc8_dev0 from 
>>> >the flashing example is not present in the lc info output.  
>>> 
>>> Okay, I will move it there. Makes sense.
>>
>>FWIW I think I meant my comment as a way to underline that what you
>>argue for is not what's implemented (assuming your "not actually
>>implemented" referred to the flashing). I was trying to send you back 
>>to the drawing board rather than break open a box of band-aides.
>
>Sure, lets do this right, I don't want to band-aide anything...