Skip to contentSkip to conversation

Patch "b43: refuse to load unsupported firmware" has been added to the 3.0-stable tree

DISCUSSION Rafał Miłecki 2 participants 6 messages Nov 17, 2011 2 messages not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1321512890.2885.92.camel@deadeye

#2 lore raw

2011/11/17 Ben Hutchings <[email protected]>:

Quoted 21 lines · gregkh at suse.de

[...]

Quoted 11 lines

From: Rafa Miecki <[email protected]>
Date: Tue, ?8 Nov 2011 17:15:03 +0100
Subject: b43: refuse to load unsupported firmware
To: stable at kernel.org, <Greg KH> greg at kroah.com
Cc: linux-wireless at vger.kernel.org, b43-dev at lists.infradead.org, roman-vl at meta.ua, Rafa Miecki <[email protected]>
Message-ID: <[email protected]>

[This patch is supposed to be applied in 3.1 (and maybe older) branches only.]

New kernels support newer firmware that users may try to incorrectly use with older kernels. Display error and explain the problem in such a case

[...]

Quoted 7 lines

+ ? ? } else if (fwrev >= 598) {
+ ? ? ? ? ? ? b43err(dev->wl, "YOUR FIRMWARE IS TOO NEW. Support for "
+ ? ? ? ? ? ? ? ? ? ?"firmware 598 and up requires kernel 3.2 or newer. You "
+ ? ? ? ? ? ? ? ? ? ?"have to install older firmware or upgrade kernel.\n");
+ ? ? ? ? ? ? b43_print_fw_helptext(dev->wl, 1);
+ ? ? ? ? ? ? err = -EOPNOTSUPP;
+ ? ? ? ? ? ? goto error;

Quoted 6 lines

[...]

This is the wrong way to go about things. ?If the new firmware is incompatible, change the filename (like everyone else does). ?It should be possible to install the different firmware versions in parallel, just as it possible to install the different kernel versions in parallel.

It sounds sane. Unfortunately I see few problems right now, not sure how to solve this now...

1) Broadcom driver doesn't contain info about firmware version
2) Because of that b43-fwcutter can't name files correctly
3) Discovering firmware version requires loading it to the firmware and reading from SHM
4) Broadcom seems to be using internally API versioning. I'm afraid it's not included in drivers as well
5) The only way for b43-fwcutter seems to be hardcoding firmware version linked with specific Broadcom driver
6) We already support same-name-called-firmware-files with 2 different APIs (598 isn't the first split here)

I'm afraid we won't be able to fix that for 3.0/3.1/3.2 releases. I think we can consider cleaning this in future releases, still not sure how however.

Signature · 1 line
Rafa?
#3 lore raw
Quoted 1 line · On Thu, 17 Nov 2011 09:42:04 +0100 Rafa? Mi?ecki <[email protected]> wrote:

1) Broadcom driver doesn't contain info about firmware version

In fact it does. The microcode does contain the version, of course.

Quoted 1 line

2) Because of that b43-fwcutter can't name files correctly

And fwcutter is even able to extract it from the dump. It also does so currently.

Quoted 2 lines

3) Discovering firmware version requires loading it to the firmware and reading from SHM

No.

Signature · 1 line
Greetings, Michael.
#4 lore raw

W dniu 17 listopada 2011 12:19 u?ytkownik Michael B?sch <[email protected]> napisa?:

Quoted 8 lines
Quoted 1 line · On Thu, 17 Nov 2011 09:42:04 +0100 Rafa? Mi?ecki <[email protected]> wrote:

1) Broadcom driver doesn't contain info about firmware version

In fact it does. The microcode does contain the version, of course.

Quoted 1 line

2) Because of that b43-fwcutter can't name files correctly

Quoted 7 lines

And fwcutter is even able to extract it from the dump. It also does so currently.

Quoted 2 lines

3) Discovering firmware version requires loading it to the firmware and reading from SHM

No.

I had no idea about that, but I admit, I didn't read the whole b43-fwcutter code. Thanks for explaining.

What about API level (revsion?)? Do you think b43-fwcutten can extract that? This would be perfect solution to include API level in firmware file name.

Signature · 1 line
Rafa?
#5 lore raw
Quoted 15 lines · On Thu, 17 Nov 2011 12:37:10 +0100 Rafa? Mi?ecki <[email protected]> wrote:

W dniu 17 listopada 2011 12:19 u?ytkownik Michael B?sch <[email protected]> napisa?:

Quoted 14 lines
Quoted 1 line · On Thu, 17 Nov 2011 09:42:04 +0100 Rafa? Mi?ecki <[email protected]> wrote:

1) Broadcom driver doesn't contain info about firmware version

In fact it does. The microcode does contain the version, of course.

Quoted 1 line

2) Because of that b43-fwcutter can't name files correctly

And fwcutter is even able to extract it from the dump. It also does so currently.

Quoted 2 lines

3) Discovering firmware version requires loading it to the firmware and reading from SHM

Quoted 9 lines
Quoted 1 line

No.

I had no idea about that, but I admit, I didn't read the whole b43-fwcutter code. Thanks for explaining.

What about API level (revsion?)? Do you think b43-fwcutten can extract that? This would be perfect solution to include API level in firmware file name.

I'm not sure what you are referring to by "API level". I didn't follow the latest firmware development too closely. Is that something new?

fwcutter contains a tiny trivial disassembler that is able to extract various immediates from the microcode. So if your versioning is stored as immediates in the code, it's trivial to add extraction for it.

fwcutter currently extracts (and prints) ucode version, patchlevel, date and time.

Signature · 1 line
Greetings, Michael.
#6 lore raw

W dniu 17 listopada 2011 12:42 u?ytkownik Michael B?sch <[email protected]> napisa?:

Quoted 28 lines
Quoted 15 lines · On Thu, 17 Nov 2011 12:37:10 +0100 Rafa? Mi?ecki <[email protected]> wrote:

W dniu 17 listopada 2011 12:19 u?ytkownik Michael B?sch <[email protected]> napisa?:

Quoted 14 lines
Quoted 1 line · On Thu, 17 Nov 2011 09:42:04 +0100 Rafa? Mi?ecki <[email protected]> wrote:

1) Broadcom driver doesn't contain info about firmware version

In fact it does. The microcode does contain the version, of course.

Quoted 1 line

2) Because of that b43-fwcutter can't name files correctly

And fwcutter is even able to extract it from the dump. It also does so currently.

Quoted 2 lines

3) Discovering firmware version requires loading it to the firmware and reading from SHM

Quoted 9 lines
Quoted 1 line

No.

I had no idea about that, but I admit, I didn't read the whole b43-fwcutter code. Thanks for explaining.

What about API level (revsion?)? Do you think b43-fwcutten can extract that? This would be perfect solution to include API level in firmware file name.

Quoted 8 lines

I'm not sure what you are referring to by "API level". I didn't follow the latest firmware development too closely. Is that something new?

fwcutter contains a tiny trivial disassembler that is able to extract various immediates from the microcode. So if your versioning is stored as immediates in the code, it's trivial to add extraction for it.

fwcutter currently extracts (and prints) ucode version, patchlevel, date and time.

http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=commit;h=a531257c40920de0161150091eaccbbc1182eb96

It seems Broadcom wants using some basename-apiversion syntax for their firmware files... but indeed it does not make much sense to me.

According to their firmware, current API is 0. I assume it from reading file name which is bcm43xx-0.fw. It does not make much sense, as we had at least 2 earlier APIs.

Looks like dead end.

Don't know what else we can propose. Putting exact version and patchlevel will make it complex (a lot of firmwares are available).

Signature · 1 line
Rafa?
#7 lore raw
Quoted 43 lines · On Thu, 17 Nov 2011 12:49:44 +0100 Rafa? Mi?ecki <[email protected]> wrote:

W dniu 17 listopada 2011 12:42 u?ytkownik Michael B?sch <[email protected]> napisa?:

Quoted 28 lines
Quoted 15 lines · On Thu, 17 Nov 2011 12:37:10 +0100 Rafa? Mi?ecki <[email protected]> wrote:

W dniu 17 listopada 2011 12:19 u?ytkownik Michael B?sch <[email protected]> napisa?:

Quoted 14 lines
Quoted 1 line · On Thu, 17 Nov 2011 09:42:04 +0100 Rafa? Mi?ecki <[email protected]> wrote:

1) Broadcom driver doesn't contain info about firmware version

In fact it does. The microcode does contain the version, of course.

Quoted 1 line

2) Because of that b43-fwcutter can't name files correctly

And fwcutter is even able to extract it from the dump. It also does so currently.

Quoted 2 lines

3) Discovering firmware version requires loading it to the firmware and reading from SHM

Quoted 9 lines
Quoted 1 line

No.

I had no idea about that, but I admit, I didn't read the whole b43-fwcutter code. Thanks for explaining.

What about API level (revsion?)? Do you think b43-fwcutten can extract that? This would be perfect solution to include API level in firmware file name.

Quoted 8 lines

I'm not sure what you are referring to by "API level". I didn't follow the latest firmware development too closely. Is that something new?

fwcutter contains a tiny trivial disassembler that is able to extract various immediates from the microcode. So if your versioning is stored as immediates in the code, it's trivial to add extraction for it.

fwcutter currently extracts (and prints) ucode version, patchlevel, date and time.

http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=commit;h=a531257c40920de0161150091eaccbbc1182eb96

It seems Broadcom wants using some basename-apiversion syntax for their firmware files... but indeed it does not make much sense to me.

Quoted 8 lines

According to their firmware, current API is 0. I assume it from reading file name which is bcm43xx-0.fw. It does not make much sense, as we had at least 2 earlier APIs.

Looks like dead end.

Don't know what else we can propose. Putting exact version and patchlevel will make it complex (a lot of firmwares are available).

No. Simply make up arbitrary incrementing numbers and add it to the directory name. /lib/firmware/b43 for the old ones. /lib/firmware/b43-1 for the next newer one that we support. -2, -3 and so on. What internal ucode rev/patchlevel that corresponds to doesn't really matter.

In the driver you can then probe all directories (starting from the number that is the newest when the driver was released, of course) and see if there's usable firmware in there. This way it will never probe "too new" firmwares.

Signature · 1 line
Greetings, Michael.