Re: bnx2x: Latest firmware requirement breaks no regression policy
From: Paul Menzel
Date: Wed Feb 19 2020 - 07:43:55 EST
Thank you for your reply.
On 2020-02-19 09:49, Sudarsana Reddy Kalluru wrote:
> The firmware file referred below (i.e., storm FW) should be present
> on the host (i.e., /lib/firmware/bnx2x/ path), not the device. Driver
> must require this version of the FW to initialize the device, and
> hence provide the network functionality. Also, the driver is not
> backward compatible with older FW versions.
> So it's not possible to handle the below error scenario in the driver,
> > bnx2x 0000:41:00.0: Direct firmware load for bnx2x/bnx2x-e1h-220.127.116.11.fw failed with error -2
> > bnx2x: [bnx2x_init_firmware:13557(net02)]Can't load firmware file bnx2x/bnx2x-e1h-18.104.22.168.fw
> At the most, we can validate the existence of FW file on the host
> during the kernel build or installation.
That is what I thought about the current state. But why was this
design decision made? Itâs not user-friendly, and as written breaks
the no regression policy. Users can update the Linux kernel without
any regressions, and everything working as before. Dave, what is
Where are the driver requirements/implementation short-comings
If an older Linux kernel works with a certain firmware version, why
shouldnât a newer Linux kernel work with that firmware version.
Maybe some features are missing, but at least I should get the same
state as with the older version.
Do you have plans to switch the driver to a model, where the
features/requirements of the firmware are queried by the driver, so
older versions can be supported?
> FW image name from driver sources:
> #define FW_FILE_NAME_E1 "bnx2x/bnx2x-e1-" FW_FILE_VERSION ".fw"
> #define FW_FILE_NAME_E1H "bnx2x/bnx2x-e1h-" FW_FILE_VERSION ".fw"
> #define FW_FILE_NAME_E2 "bnx2x/bnx2x-e2-" FW_FILE_VERSION ".fw"
> FW image path on the host:
Yes, that is what I found in my original research, and that is how
we fixed it, but with the non-working interface it was more work
Description: S/MIME Cryptographic Signature