bnx2: update bnx2-mips-09 firmware to bnx2-mips-09-6.2.1b
PATCH 1/1 bnx2: update bnx2-mips-09 firmware to bnx2-mips-09-6.2.1b
Commit c2c20ef43d00 "bnx2: Update driver to use new mips firmware" updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a in firmware/bnx2/ with the new version.
This means that the bnx2 driver stopped working altogether for users who use CONFIG_FIRMWARE_IN_KERNEL to compile firmware together with drivers into their kernel, rather than having a runtime firmware loader.
---
This is a regression from v3.2 that's present in both v3.3 and v3.4 as well as HEAD so I've Cc:ed [email protected].
firmware/Makefile | 2 +- firmware/WHENCE | 2 +- firmware/bnx2/bnx2-mips-09-6.2.1b.fw.ihex | 6497 +++++++++++++++++++++++++++++ 3 files changed, 6499 insertions(+), 2 deletions(-) create mode 100644 firmware/bnx2/bnx2-mips-09-6.2.1b.fw.ihex
firmware/Makefile +1 -1
@@ -34,7 +34,7 @@ fw-shipped-$(CONFIG_ATM_AMBASSADOR) += atmsar11.fw fw-shipped-$(CONFIG_BNX2X) += bnx2x/bnx2x-e1-6.2.9.0.fw \ bnx2x/bnx2x-e1h-6.2.9.0.fw \ bnx2x/bnx2x-e2-6.2.9.0.fw -fw-shipped-$(CONFIG_BNX2) += bnx2/bnx2-mips-09-6.2.1a.fw \ +fw-shipped-$(CONFIG_BNX2) += bnx2/bnx2-mips-09-6.2.1b.fw \ bnx2/bnx2-rv2p-09-6.0.17.fw \ bnx2/bnx2-rv2p-09ax-6.0.17.fw \ bnx2/bnx2-mips-06-6.2.1.fw \
firmware/WHENCE +1 -1
@@ -664,7 +664,7 @@ Driver: BNX2 - Broadcom NetXtremeII File: bnx2/bnx2-mips-06-6.2.1.fw File: bnx2/bnx2-rv2p-06-6.0.15.fw -File: bnx2/bnx2-mips-09-6.2.1a.fw +File: bnx2/bnx2-mips-09-6.2.1b.fw File: bnx2/bnx2-rv2p-09-6.0.17.fw File: bnx2/bnx2-rv2p-09ax-6.0.17.fw
firmware/bnx2/bnx2-mips-09-6.2.1b.fw.ihex new file +6497 -0
2,984 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
1.7.10
Part of the diff is not shown here. View the raw message.
Quoted 5 lines · Chris Webb
Commit
c2c20ef43d00"bnx2: Update driver to use new mips firmware" updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a infirmware/bnx2/with the new version.
Quoted 7 lines
This means that the bnx2 driver stopped working altogether for users who use
CONFIG_FIRMWARE_IN_KERNELto compile firmware together with drivers into their kernel, rather than having a runtime firmware loader.Cc <[email protected]>Signed-off-by Chris Webb <[email protected]>---
Have you read firmware/README.AddingFirmware ?
Quoted 1 line · Eric Dumazet
Have you read
firmware/README.AddingFirmware?
I hadn't, but now I have, and if firmware upgrades are considered 'adding new firmware', I agree this patch is wrong, and should have just removed the obsolete bnx2-mips-09-6.2.1a file that is no longer used by the bnx2 driver.
However, not having dealt with cards that need these kinds of horrible binary blobs before, I'm a little uncertain how I should be building upstream kernels with CONFIG_FIRMWARE_IN_KERNEL and pulling in the correct blobs from a linux-firmware checkout.
Is there a more automatic method than going through the source for each configured driver and setting CONFIG_EXTRA_FIRMWARE manually to list the relevant firmwares? Is there any way to give the kernel the location of linux-firmware and have it compile in everything needed for the selected drivers, as used to happen with the firmware/ subdirectory? CONFIG_EXTRA_FIRMWARE_DIR doesn't seem to do anything with CONFIG_EXTRA_FIRMWARE empty, so I don't think it does what I'm hoping?
Cheers,
Chris.
Quoted 8 lines · Chris Webb
Is there a more automatic method than going through the source for each configured driver and setting
CONFIG_EXTRA_FIRMWAREmanually to list the relevant firmwares? Is there any way to give the kernel the location of linux-firmware and have it compile in everything needed for the selected drivers, as used to happen with thefirmware/subdirectory?CONFIG_EXTRA_FIRMWARE_DIRdoesn't seem to do anything withCONFIG_EXTRA_FIRMWAREempty, so I don't think it does what I'm hoping?
Most users will just download the linux-firmware tree:
//git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
and copy all the firmware files to /lib/firmware.
Quoted 13 lines · Chris Webb
Quoted 1 line · Eric Dumazet
Have you read
firmware/README.AddingFirmware?I hadn't, but now I have, and if firmware upgrades are considered 'adding new firmware', I agree this patch is wrong, and should have just removed the obsolete bnx2-mips-09-6.2.1a file that is no longer used by the bnx2 driver.
However, not having dealt with cards that need these kinds of horrible binary blobs before, I'm a little uncertain how I should be building upstream kernels with
CONFIG_FIRMWARE_IN_KERNELand pulling in the correct blobs from a linux-firmware checkout.
Quoted 7 lines
Is there a more automatic method than going through the source for each configured driver and setting
CONFIG_EXTRA_FIRMWAREmanually to list the relevant firmwares? Is there any way to give the kernel the location of linux-firmware and have it compile in everything needed for the selected drivers, as used to happen with thefirmware/subdirectory?CONFIG_EXTRA_FIRMWARE_DIRdoesn't seem to do anything withCONFIG_EXTRA_FIRMWAREempty, so I don't think it does what I'm hoping?
I had a go at making CONFIG_FIRMWARE_IN_KERNEL pick the right blobs automatically <http://thread.gmane.org/gmane.linux.kernel/1230462>, but I couldn't get the Kbuild rules quite right. No-one responded and I haven't had another try since.
Ben.
Signature · 3 lines
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert CoveyouQuoted 9 lines · Chris Webb
Commit
c2c20ef43d00"bnx2: Update driver to use new mips firmware" updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a infirmware/bnx2/with the new version.This means that the bnx2 driver stopped working altogether for users who use
CONFIG_FIRMWARE_IN_KERNELto compile firmware together with drivers into their kernel, rather than having a runtime firmware loader.
Still not fixed in mainline? I encountered the same problem with v3.6-rc1-133-g42a579a.
From: Jike Song <[email protected]>
Date: Wed, 8 Aug 2012 13:50:42 +0800
Quoted 6 lines · Chris Webb
Quoted 5 lines
Commit
c2c20ef43d00"bnx2: Update driver to use new mips firmware" updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a infirmware/bnx2/with the new version.
Quoted 7 lines
Quoted 4 lines
This means that the bnx2 driver stopped working altogether for users who use
CONFIG_FIRMWARE_IN_KERNELto compile firmware together with drivers into their kernel, rather than having a runtime firmware loader.Still not fixed in mainline? I encountered the same problem with v3.6-rc1-133-g42a579a.
The current firmware for all drivers are not distributed in the kernel sources any longer, they are maintained in a completely seperate repository.
The old ones are just kept around in the kernel sources for compatability.
This is a FAQ.
Quoted 17 lines · David Miller
From: Jike Song <[email protected]>
Date: Wed, 8 Aug 2012 13:50:42 +0800Quoted 6 lines · Chris Webb
Quoted 5 lines
Commit
c2c20ef43d00"bnx2: Update driver to use new mips firmware" updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a infirmware/bnx2/with the new version.Quoted 7 lines
Quoted 4 lines
This means that the bnx2 driver stopped working altogether for users who use
CONFIG_FIRMWARE_IN_KERNELto compile firmware together with drivers into their kernel, rather than having a runtime firmware loader.Still not fixed in mainline? I encountered the same problem with v3.6-rc1-133-g42a579a.
Quoted 8 lines
The current firmware for all drivers are not distributed in the kernel sources any longer, they are maintained in a completely seperate repository.
The old ones are just kept around in the kernel sources for compatability.
This is a FAQ.
Well, if the drivers provided with the kernel don't work out of the box anymore, maybe we should also move them to a separate repository. All it is going to do otherwise is to cause invalid bug reports because users don't understand why using the latest driver does not work.
That way it would be clear that an in-kernel driver has to be self-sustaining to be maintainable, otherwise it has nothing to do there.
Just my 2 cents,
Willy
Quoted 8 lines · Willy Tarreau
Well, if the drivers provided with the kernel don't work out of the box anymore, maybe we should also move them to a separate repository. All it is going to do otherwise is to cause invalid bug reports because users don't understand why using the latest driver does not work.
That way it would be clear that an in-kernel driver has to be self-sustaining to be maintainable, otherwise it has nothing to do there.
People compiling their own kernels are supposed to be able to handle this problem themselves.
If not, they can use a distro.
Hi Eric,
Quoted 8 lines · Eric Dumazet
Quoted 6 lines · Willy Tarreau
Well, if the drivers provided with the kernel don't work out of the box anymore, maybe we should also move them to a separate repository. All it is going to do otherwise is to cause invalid bug reports because users don't understand why using the latest driver does not work.
Quoted 7 lines
Quoted 2 lines
That way it would be clear that an in-kernel driver has to be self-sustaining to be maintainable, otherwise it has nothing to do there.
People compiling their own kernels are supposed to be able to handle this problem themselves.
If not, they can use a distro.
But similarly, people who compile their own kernels are also supposed to be able to retrieve up-to-date drivers from another tree. I know many people who use the intel NIC drivers from sf.net and (less) other ones using myricom's drivers for instance.
I don't really see the value of keeping in the tree drivers that don't work out of the box, if it's only causing issues and bug reports.
Regards,
Willy
Quoted 19 lines · Willy Tarreau
Hi Eric,
Quoted 8 lines · Eric Dumazet
Quoted 6 lines · Willy Tarreau
Well, if the drivers provided with the kernel don't work out of the box anymore, maybe we should also move them to a separate repository. All it is going to do otherwise is to cause invalid bug reports because users don't understand why using the latest driver does not work.
Quoted 7 lines
Quoted 2 lines
That way it would be clear that an in-kernel driver has to be self-sustaining to be maintainable, otherwise it has nothing to do there.
People compiling their own kernels are supposed to be able to handle this problem themselves.
If not, they can use a distro.
Quoted 7 lines
But similarly, people who compile their own kernels are also supposed to be able to retrieve up-to-date drivers from another tree. I know many people who use the intel NIC drivers from sf.net and (less) other ones using myricom's drivers for instance.
I don't really see the value of keeping in the tree drivers that don't work out of the box, if it's only causing issues and bug reports.
Only the firmware is in a separate git tree, called linux-firmware, that about all kernel developers are aware of.
The drivers themselves are in linux tree, and they are generally in quite good shape, because of that.