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
| ||
|
Date: Thu, 20 Feb 2020 15:40:37 +0000 From: Ariel Elior <aelior@...vell.com> To: Sudarsana Reddy Kalluru <skalluru@...vell.com>, Paul Menzel <pmenzel@...gen.mpg.de>, GR-everest-linux-l2 <GR-everest-linux-l2@...vell.com> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, "it+linux-netdev@...gen.mpg.de" <it+linux-netdev@...gen.mpg.de>, "David S. Miller" <davem@...emloft.net> Subject: RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression policy > -----Original Message----- > From: Sudarsana Reddy Kalluru <skalluru@...vell.com> > Sent: Thursday, February 20, 2020 11:17 AM > To: Paul Menzel <pmenzel@...gen.mpg.de>; Ariel Elior > <aelior@...vell.com>; GR-everest-linux-l2 <GR-everest-linux- > l2@...vell.com> > Cc: netdev@...r.kernel.org; LKML <linux-kernel@...r.kernel.org>; it+linux- > netdev@...gen.mpg.de; David S. Miller <davem@...emloft.net> > Subject: RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression > policy > > Hi Paul, > Bnx2x driver and the storm FW are tightly coupled, and the info is exchanged > between them via shmem (i.e., common structures which might change > between the releases). Also, FW provides some offset addresses to the driver > which could change between the FW releases, following is one such commit, > https://www.spinics.net/lists/netdev/msg609889.html > Hence it's not very straight forward to provide the backward compatibility i.e., > newer (updated) kernel driver with the older FW. > Currently we don’t have plans to implement the new model mentioned below. > > Thanks, > Sudarsana Hi, There are additional reasons why backwards/forwards compatibility considerations are not applicable here. This Fw is not nvram based, and does not reside in the device. It is programed to the device on every driver load. The driver will never face a device "already initialized" with a version of FW it is not familiar with. The device also has traditional management FW in nvram in the device with which we have a backwards and forwards compatibility mechanism, which works just fine. But the FW under discussion is fastpath Fw, used to craft every packet going out of the device and analyze and place every packet coming into the device. Supporting multiple versions of FW would be tantamount to implementing dozens of versions of start_xmit and napi_poll in the driver (not to mention multiple fastpath handles of all the offloads the device supports, roce, iscsi, fcoe and iwarp, as all of these are offloaded by the FW). The entire device initialization sequence also changes significantly from one FW version to the Next. All of these differences are abstracted away in the FW file, which includes the init sequence and the compiled FW. The amount of changes required in driver are very significant when moving from one version to the next. Trying to keep all those versions alive concurrently would cause this already very large driver to be 20x larger. We don't have a method of keeping the device operational if the kernel was upgraded but firmware tree was not updated. The best that can be done is report the problem, which is what we do. Thanks, Ariel
Powered by blists - more mailing lists