Re: bnx2x: Latest firmware requirement breaks no regression policy

[Paul Menzel]

Dear Sudarsana,


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-7.13.11.0.fw failed with error -2
> 	>     bnx2x: [bnx2x_init_firmware:13557(net02)]Can't load firmware file bnx2x/bnx2x-e1h-7.13.11.0.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
your opinion?

Where are the driver requirements/implementation short-comings
documented?

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:
> 	drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:
> 	#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:
> 	/lib/firmware/bnx2x/bnx2x-e1h-7.13.11.0.fw
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
than necessary.


Kind regards,

Paul

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature