netdev - Re: [patch net-next 00/11] mlxsw: Implement dev info and dev flash for line cards

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: <YqtcR8rY44c42Nu7@nanopsycho>
Date:   Thu, 16 Jun 2022 18:37:27 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Ido Schimmel <idosch@...dia.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        petrm@...dia.com, pabeni@...hat.com, edumazet@...gle.com,
        mlxsw@...dia.com
Subject: Re: [patch net-next 00/11] mlxsw: Implement dev info and dev flash
 for line cards

Thu, Jun 16, 2022 at 04:47:50PM CEST, idosch@...dia.com wrote:
>On Thu, Jun 16, 2022 at 03:11:57PM +0200, Jiri Pirko wrote:
>> Thu, Jun 16, 2022 at 09:03:52AM CEST, idosch@...dia.com wrote:
>> >On Wed, Jun 15, 2022 at 07:40:34PM +0200, Jiri Pirko wrote:
>> >> Wed, Jun 15, 2022 at 11:13:35AM CEST, idosch@...dia.com wrote:
>> >> >On Tue, Jun 14, 2022 at 02:33:15PM +0200, Jiri Pirko wrote:
>> >> >> $ devlink dev flash auxiliary/mlxsw_core.lc.0 file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2
>> >> >
>> >> >How is this firmware activated? It is usually done after reload, but I
>> >> >don't see reload implementation for the line card devlink instance.
>> >> 
>> >> Currently, only devlink dev reload of the whole mlxsw instance or
>> >> unprovision/provision of a line card.
>> >
>> >OK, please at least mention it in the commit message that adds flashing
>> >support.
>> >
>> >What about implementing reload support as unprovision/provision?
>> 
>> Yes, that can be done eventually. I was thinking about that as well.
>
>This patch should come before the one that adds flashing. Then both the
>primary and nested devlink instances maintain the same semantics with
>regards to firmware flashing / activation.

Ok.