netdev - Re: [patch net-next 0/9] mlxsw: Support firmware flash

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170529144027.747fc1c6@cakuba.lan>
Date:   Mon, 29 May 2017 14:40:27 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Yotam Gigi <yotamg@...lanox.com>,
        David Miller <davem@...emloft.net>, Yuval.Mintz@...ium.com,
        Jiri Pirko <jiri@...nulli.us>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Ido Schimmel <idosch@...lanox.com>, mlxsw <mlxsw@...lanox.com>,
        ben@...adent.org.uk
Subject: Re: [patch net-next 0/9] mlxsw: Support firmware flash

[swapping Ben's email]

On Mon, 29 May 2017 11:52:27 +0300, Or Gerlitz wrote:
> On Mon, May 29, 2017 at 3:17 AM, Jakub Kicinski <kubakici@...pl> wrote:
> > On Sun, 28 May 2017 10:26:49 +0300, Yotam Gigi wrote:  
> 
> >> This problem is even more relevant in the Mellanox HCA driver team, which would
> >> like to use that code in order to burn the HCA firmware, but not intend to
> >> trigger it on boot time, which means that must have a way for the user to
> >> trigger it.  
> 
> > What would the requirements for the HCA team be?  Is it about loading
> > different code or loading HW settings?  
> 
> For the NIC, as of the (happily growing) large open-systems by nature
> install base, we
> can't effort for the driver not to load when the currently burned fw
> isn't the latest or
> the system doesn't have the latest libfirmware clone. We do have to
> keep the hassle of
> compatibility with older FWs, etc.  As part of the driver/FW API
> design we use cap bits
> for that matter, and never ask/branch on specific FW or HW versions.
> 
> We do want to let user work with the kernel w.o the need to have them
> install MLNX or anyone's
> tool suit and hence the large value we find in the ethtool flashing of
> FW image (the patches
> are ready...)

Thanks for the explanations Or and Yotam!  That does sound like a plain
version upgrade problem.