[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 <kubak...@wp.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.
