Small driver fixes
cover Small driver fixes
Couple of things don't work properly with radiotap rx yet. These patches make them work.
PATCH 1/2 zd1211rw-mac80211: return hardware specific tx rate code for rx status
zd1211rw-mac80211 uses different hardware-specific codings to talk about rates when doing transmit and receive. Because mac80211 looks up the rx rate against the rates table used for selecting hardware-specific coding for tx, the rate returned in the rx_status struct needs to be adjusted to use the coding used to hardware-specific tx rates. This patch performs this adjustment.
Without this patch the radiotap-based monitor stuff reports a "0.0Mbps" rate for all packets from this driver.
--- drivers/net/wireless/mac80211/zd1211rw/zd_chip.c | 22 ++++++++++++++++++++++ drivers/net/wireless/mac80211/zd1211rw/zd_chip.h | 2 ++ drivers/net/wireless/mac80211/zd1211rw/zd_mac.c | 2 +- 3 files changed, 25 insertions(+), 1 deletion(-)
drivers/net/wireless/mac80211/zd1211rw/zd_chip.c +22 -0
@@ -1569,6 +1569,28 @@ u16 zd_rx_rate(const void *rx_frame, conreturn rate; } +int zd_rx_rate_using_tx_format (const void *rx_frame, +const struct rx_status *status) +{ +if (status->frame_status &ZD_RX_OFDM ) { +return ZD_CS_OFDM | (zd_ofdm_plcp_header_rate (rx_frame) &0xf ); + } + +switch (zd_cck_plcp_header_rate (rx_frame)) { +case ZD_CCK_SIGNAL_1M : +return ZD_CS_CCK_RATE_1M ; +case ZD_CCK_SIGNAL_2M : +return ZD_CS_CCK_RATE_2M ; +case ZD_CCK_SIGNAL_5M5 : +return ZD_CS_CCK_RATE_5_5M ; +case ZD_CCK_SIGNAL_11M : +return ZD_CS_CCK_RATE_11M ; +default : +return 0 ; + } + +} +int zd_chip_switch_radio_on (struct zd_chip *chip) {int r;
drivers/net/wireless/mac80211/zd1211rw/zd_chip.h +2 -0
@@ -877,6 +877,8 @@ u8 zd_rx_qual_percent(const void *rx_frau8 zd_rx_strength_percent (u8 rssi);u16 zd_rx_rate (const void *rx_frame,const struct rx_status *status); +int zd_rx_rate_using_tx_format (const void *rx_frame, +const struct rx_status *status);struct zd_mc_hash {u32 low;
drivers/net/wireless/mac80211/zd1211rw/zd_mac.c +1 -1
@@ -642,7 +642,7 @@ static int fill_rx_stats(struct ieee8021 stats->signal =zd_rx_qual_percent (buffer, length -sizeof (struct rx_status ), status); - stats->rate =zd_rx_rate (buffer, status); + stats->rate =zd_rx_rate_using_tx_format (buffer, status);return 0 ; }
Re: [PATCH 1/2] zd1211rw-mac80211: return hardware specific tx rate code for rx status
Quoted 6 lines · On Mon, Jun 11, 2007 at 11:38:29AM +0100, [email protected] wrote:
zd1211rw-mac80211 uses different hardware-specific codings to talk about rates when doing transmit and receive. Because mac80211 looks up the rx rate against the rates table used for selecting hardware-specific coding for tx, the rate returned in the
rx_statusstruct needs to be adjusted to use the coding used to hardware-specific tx rates. This patch performs this adjustment.
Quoted 6 lines
Without this patch the radiotap-based monitor stuff reports a "0.0Mbps" rate for all packets from this driver.
CC Daniel Drake <[email protected]>CC Ulrich Kunitz <[email protected]>Signed-off-by Andy Green <[email protected]>
Daniel, Uli -- ack/nak?
Signature · 2 lines
John W. Linville [email protected]
Re: [PATCH 1/2] zd1211rw-mac80211: return hardware specific tx rate code for rx status
Quoted 7 lines · On 07-07-19 15:10 John W. Linville wrote:
Quoted 6 lines · On Mon, Jun 11, 2007 at 11:38:29AM +0100, [email protected] wrote:
zd1211rw-mac80211 uses different hardware-specific codings to talk about rates when doing transmit and receive. Because mac80211 looks up the rx rate against the rates table used for selecting hardware-specific coding for tx, the rate returned in the
rx_statusstruct needs to be adjusted to use the coding used to hardware-specific tx rates. This patch performs this adjustment.
Quoted 8 lines
Quoted 6 lines
Without this patch the radiotap-based monitor stuff reports a "0.0Mbps" rate for all packets from this driver.
CC Daniel Drake <[email protected]>CC Ulrich Kunitz <[email protected]>Signed-off-by Andy Green <[email protected]>Daniel, Uli -- ack/nak?
John,
NAK. The patch introduces unnecessarily a new function.
I have already the correct patch in the queue:
Kind regards,
Uli
Signature · 1 line
Uli Kunitz
PATCH 2/2 bcm43xx-mac80211: Fix reported rx frequency and channel
In reply to [email protected]bcm43xx-mac80211 is reporting bogus frequencies and channels back to mac80211 at the moment (eg, actual ch1 (2412MHz) reported as 2424MHz).
Prior to this patch, the hardware rx channel value is reported as starting at 0x18 and rising by 0x0a per channel. Code in bcm43xx_xmit.c tries to take this value and add 2400 to it to get the rx frequency. It seems the intention is that the hardware reports the (rx freq - 2400), so we want the value starting at 0x0c and rising by 0x05 per channel.
If the value read is shifted one more bit to the right, it will succeed in doing this. Therefore this patch increases the shifting constant by one and reduces the mask by one lsb.
The rx frequency reported in the radiotap rx and then, eg, tcpdump, is then correct. I didn't test ch 14 but I guess the hardware is consistent about it.
drivers/net/wireless/mac80211/bcm43xx/bcm43xx_xmit.h +2 -2
@@ -190,8 +190,8 @@ struct bcm43xx_rxhdr_fw4 {/* RX channel */ #define BCM43xx_RX_CHAN_GAIN 0xFC00/* Gain */ #define BCM43xx_RX_CHAN_GAIN_SHIFT 10 -#define BCM43xx_RX_CHAN_ID 0x03FC/* Channel ID */ -#define BCM43xx_RX_CHAN_ID_SHIFT 2 +#define BCM43xx_RX_CHAN_ID 0x03F8/* Channel ID */ +#define BCM43xx_RX_CHAN_ID_SHIFT 3#define BCM43xx_RX_CHAN_PHYTYPE 0x0003/* PHY type */
Johannes Berg
maintainerRe: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
drivers/net/wireless/mac80211/bcm43xx/bcm43xx_xmit.h struct bcm43xx_rxhdr_fw4 { · line 195
Quoted 12 lines
drivers/net/wireless/mac80211/bcm43xx/bcm43xx_xmit.h +2
-2@@ -190,8 +190,8 @@ struct bcm43xx_rxhdr_fw4 {/* RX channel */ #define BCM43xx_RX_CHAN_GAIN 0xFC00/* Gain */ #define BCM43xx_RX_CHAN_GAIN_SHIFT 10 -#define BCM43xx_RX_CHAN_ID 0x03FC/* Channel ID */ -#define BCM43xx_RX_CHAN_ID_SHIFT 2 +#define BCM43xx_RX_CHAN_ID 0x03F8/* Channel ID */ +#define BCM43xx_RX_CHAN_ID_SHIFT 3#define BCM43xx_RX_CHAN_PHYTYPE 0x0003/* PHY type */
Damn. This is a firmware thing, the firmware later changed because they needed more than 2 bits for the PHY type so things were shifted up by one. That means the actual channel ID mask will be 0x7f8 now and this is in the current specs. Can you please post which firmware you're using? We'll want to force people to use newer firmware with this behaviour -or- figure out at what point they made the transition...
johannes
Johannes Berg
maintainerRe: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 7 lines
Damn. This is a firmware thing, the firmware later changed because they needed more than 2 bits for the PHY type so things were shifted up by one. That means the actual channel ID mask will be
0x7f8now and this is in the current specs. Can you please post which firmware you're using? We'll want to force people to use newer firmware with this behaviour -or- figure out at what point they made the transition...
See bottom of http://bcm-v4.sipsolutions.net/802.11/RX
Actually, I guess we can test this. Beacons contain the channel, we can determine the frequency from that and see what's going on. I'll leave it to Michael to decide what to do.
johannes
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
In reply to [email protected]Quoted 13 lines · On Mon, Jun 11, 2007 at 11:38:30AM +0100, [email protected] wrote:
bcm43xx-mac80211 is reporting bogus frequencies and channels back to mac80211 at the moment (eg, actual ch1 (2412MHz) reported as 2424MHz).
Prior to this patch, the hardware rx channel value is reported as starting at
0x18and rising by0x0aper channel. Code inbcm43xx_xmit.ctries to take this value and add 2400 to it to get the rx frequency. It seems the intention is that the hardware reports the (rx freq - 2400), so we want the value starting at0x0cand rising by0x05per channel.If the value read is shifted one more bit to the right, it will succeed in doing this. Therefore this patch increases the shifting constant by one and reduces the mask by one lsb.
Quoted 7 lines
The rx frequency reported in the radiotap rx and then, eg, tcpdump, is then correct. I didn't test ch 14 but I guess the hardware is consistent about it.
CC Larry Finger <[email protected]>CC Michael Buesch <[email protected]>Signed-off-by Andy Green <[email protected]>
Larry, Michael, Johannes -- ack/nak?
John
Signature · 2 lines
John W. Linville [email protected]
Michael Buesch
NAKRe: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 18 lines · On Thursday 19 July 2007 21:10:52 John W. Linville wrote:
Quoted 17 lines · On Mon, Jun 11, 2007 at 11:38:30AM +0100, [email protected] wrote:
bcm43xx-mac80211 is reporting bogus frequencies and channels back to mac80211 at the moment (eg, actual ch1 (2412MHz) reported as 2424MHz).
Prior to this patch, the hardware rx channel value is reported as starting at
0x18and rising by0x0aper channel. Code inbcm43xx_xmit.ctries to take this value and add 2400 to it to get the rx frequency. It seems the intention is that the hardware reports the (rx freq - 2400), so we want the value starting at0x0cand rising by0x05per channel.If the value read is shifted one more bit to the right, it will succeed in doing this. Therefore this patch increases the shifting constant by one and reduces the mask by one lsb.
The rx frequency reported in the radiotap rx and then, eg, tcpdump, is then correct. I didn't test ch 14 but I guess the hardware is consistent about it.
Quoted 5 lines
Quoted 3 lines
CC Larry Finger <[email protected]>CC Michael Buesch <[email protected]>Signed-off-by Andy Green <[email protected]>Larry, Michael, Johannes -- ack/nak?
nak, the issue is more difficult than this.
The point is that firmware changed and we don't know the exact revision, yet. But it is actually no problem in reality, as the use-it-or-die firmware doesn't have this problem. So if someone uses another firmware than the one we suggest, he will probably run into more problems, as well.
The fix is called: Use the correct firmware.
For now, at least.
Of course, the author of this patch should help us to find out the exact firmware rev where this change happened. So we can come up with a real fix.
Signature · 1 line
Greetings Michael.
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
:
Quoted 19 lines · On Thursday 19 July 2007 21:10:52 John W. Linville wrote:
Quoted 18 lines · On Mon, Jun 11, 2007 at 11:38:30AM +0100, [email protected] wrote:
Quoted 17 lines
bcm43xx-mac80211 is reporting bogus frequencies and channels back to mac80211 at the moment (eg, actual ch1 (2412MHz) reported as 2424MHz).
Prior to this patch, the hardware rx channel value is reported as starting at
0x18and rising by0x0aper channel. Code inbcm43xx_xmit.ctries to take this value and add 2400 to it to get the rx frequency. It seems the intention is that the hardware reports the (rx freq - 2400), so we want the value starting at0x0cand rising by0x05per channel.If the value read is shifted one more bit to the right, it will succeed in doing this. Therefore this patch increases the shifting constant by one and reduces the mask by one lsb.
The rx frequency reported in the radiotap rx and then, eg, tcpdump, is then correct. I didn't test ch 14 but I guess the hardware is consistent about it.
Quoted 6 lines
Quoted 4 lines
Quoted 3 lines
CC Larry Finger <[email protected]>CC Michael Buesch <[email protected]>Signed-off-by Andy Green <[email protected]>Larry, Michael, Johannes -- ack/nak?
nak, the issue is more difficult than this.
Although for this and the zd1211rw patch I found out they were deprecated/more complex already using a "polling method", I must say an explicit ACK or NAK for patches is a great idea.
After seeing patch tracking issues on arm-linux mailing list as well, those not involving me, I started making a PHP project called "patchfillet" for the purpose of extracting patches from a mailing list and trying to track the patch lifecycle in an automated way driven by the contents of the threads (eg, keywords like adding Acked-by: <blah> in a reply) and maybe one day by looking at an upstream git repo commits (I found that the Index: line in git-committed patches can change destroying what would otherwise be a hash match).
The idea is it generates dynamic HTML on a website, and once it can be trusted enough mails reports to the same mailing list about patches without a resolution, patches accepted and rejected for the week and so on. Right now it is able to extract all the patches, inline or attached, from an IMAP server folder into a MySQL database along with message ID and thread info, and to run patches against an external git tree and checkpatch.pl. If this is interesting to anyone by all means send me ideas for what is useful on or off list.
Quoted 11 lines
The point is that firmware changed and we don't know the exact revision, yet. But it is actually no problem in reality, as the use-it-or-die firmware doesn't have this problem. So if someone uses another firmware than the one we suggest, he will probably run into more problems, as well.
The fix is called: Use the correct firmware.
For now, at least.Of course, the author of this patch should help us to find out the exact firmware rev where this change happened. So we can come up with a real fix.
I never heard of a special blessed firmware before, I don't think that the driver made any dmesg when given the non-blessed one, if that is what it is? I was given this firmware by the traditional "person on IRC" and don't know where it came from, but I still have it here if any versioning can be extracted from it.
Unfortunately the only sport I practice is one I named "extreme admin".
This involves maintaining Fedora installs on the machines of remote
friends and relatives during infrequent visits. My bcm43xx card is currently living with my In-laws in Spain (and doing fine using bcm43xx-mac80211 ;-) ).
-Andy
Johannes Berg
maintainerRe: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 8 lines · Andy Green
After seeing patch tracking issues on arm-linux mailing list as well, those not involving me, I started making a PHP project called "patchfillet" for the purpose of extracting patches from a mailing list and trying to track the patch lifecycle in an automated way driven by the contents of the threads (eg, keywords like adding Acked-by: <blah> in a reply) and maybe one day by looking at an upstream git repo commits (I found that the Index: line in git-committed patches can change destroying what would otherwise be a hash match).
Sounds like `patchwork'.
Quoted 1 line
I must say an explicit ACK or NAK for patches is a great idea.
I'd also appreciate explicit davem-style "thanks I merged this" but hey, I get by checking the various git trees all the time :)
johannes
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 6 lines · Johannes Berg
Quoted 1 line · Andy Green
I must say an explicit ACK or NAK for patches is a great idea.
I'd also appreciate explicit davem-style "thanks I merged this" but hey, I get by checking the various git trees all the time :)
Yes, I could do better. Still, checking the "Please pull..." message short logs might be more time efficient.
John
Signature · 2 lines
John W. Linville [email protected]
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
In reply to Andy GreenQuoted 6 lines · Andy Green
I never heard of a special blessed firmware before, I don't think that the driver made any dmesg when given the non-blessed one, if that is what it is? I was given this firmware by the traditional "person on IRC" and don't know where it came from, but I still have it here if any versioning can be extracted from it.
Just as API's and ABI's change, the writers of firmware can change their layout, which is what happened here. Nothing "blessed", just one behavior before, and a second after, the change. The version info can be gotten from fwcutter.
Larry
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 8 lines · Somebody in the thread at some point
Quoted 6 lines · Andy Green
I never heard of a special blessed firmware before, I don't think that the driver made any dmesg when given the non-blessed one, if that is what it is? I was given this firmware by the traditional "person on IRC" and don't know where it came from, but I still have it here if any versioning can be extracted from it.
Quoted 4 lines
Just as API's and ABI's change, the writers of firmware can change their layout, which is what happened here. Nothing "blessed", just one behavior before, and a second after, the change. The version info can be gotten from fwcutter.
Understood, that is why I consider it a bad thing that functionality that can be done in the mac80211 driver is pushed into the binary-only firmware when there is a choice (otherwise known as "paranoia", apparently).
However you stripped some quoting from Michael:
''But it is actually no problem in reality, as the use-it-or-die firmware doesn't have this problem. So if someone uses another firmware than the one we suggest, he will probably run into more problems, as well.
The fix is called: Use the correct firmware.
For now, at least.''
I would summarize this that Michael is telling me one pariticular version of firmware - "use it or die firmware" - is especially blessed/correct. It might be an idea to let people know they have strayed from the dependency of the required firmware version in dmesg if indeed there is an effective dependency of the driver on it.
Can I still get the firmware version from fwcutter if I don't have the original Windows binary the firmware came from?
-Andy
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 4 lines · Andy Green
Understood, that is why I consider it a bad thing that functionality that can be done in the mac80211 driver is pushed into the binary-only firmware when there is a choice (otherwise known as "paranoia", apparently).
Unfortunately, that is a necessary result of this type of reverse-engineering. If Broadcom put some function in the firmware, we have to leave it there as we have no idea what would break.
Quoted 9 lines
However you stripped some quoting from Michael:
''But it is actually no problem in reality, as the use-it-or-die firmware doesn't have this problem. So if someone uses another firmware than the one we suggest, he will probably run into more problems, as well.
The fix is called: Use the correct firmware.
For now, at least.''
Quoted 5 lines
I would summarize this that Michael is telling me one pariticular version of firmware - "use it or die firmware" - is especially blessed/correct. It might be an idea to let people know they have strayed from the dependency of the required firmware version in dmesg if indeed there is an effective dependency of the driver on it.
It isn't that it is blessed or correct, but that it has been tested. Your version has not. Who knows what else might have changed? Once we know the version with the different behavior, a warning message can be prepared. I don't think anyone knew about this problem until you submitted your patch.
Quoted 2 lines
Can I still get the firmware version from fwcutter if I don't have the original Windows binary the firmware came from?
AFAIK, fwcutter can only get the version from the foreign driver. It can be gotten from the dmesg output of your inlaws computer, or if you have the extracted firmware files here, you can bundle them up and email them to me privately.
Larry
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 24 lines · On Friday 20 July 2007 18:58:24 Larry Finger wrote:
Quoted 4 lines · Andy Green
Understood, that is why I consider it a bad thing that functionality that can be done in the mac80211 driver is pushed into the binary-only firmware when there is a choice (otherwise known as "paranoia", apparently).
Unfortunately, that is a necessary result of this type of reverse-engineering. If Broadcom put some function in the firmware, we have to leave it there as we have no idea what would break.
Quoted 9 lines
However you stripped some quoting from Michael:
''But it is actually no problem in reality, as the use-it-or-die firmware doesn't have this problem. So if someone uses another firmware than the one we suggest, he will probably run into more problems, as well.
The fix is called: Use the correct firmware.
For now, at least.''Quoted 5 lines
I would summarize this that Michael is telling me one pariticular version of firmware - "use it or die firmware" - is especially blessed/correct. It might be an idea to let people know they have strayed from the dependency of the required firmware version in dmesg if indeed there is an effective dependency of the driver on it.
Quoted 3 lines
It isn't that it is blessed or correct, but that it has been tested. Your version has not. Who knows what else might have changed? Once we know the version with the different behavior, a warning message can be prepared. I don't think anyone knew about this problem until you submitted your patch.
People don't read dmesg. Adding a "This firmware is unsupported" would have no effect.
I experience same thing for the "bcm43xx-does-not-support-v3-issue". There is a clear error message saying what to do exactly. And _still_ people mail me asking what this message means.
The use-or-die firmware is here:
http://linuxwireless.org/en/users/Drivers/bcm43xx
Quoted 6 lines
Quoted 2 lines
Can I still get the firmware version from fwcutter if I don't have the original Windows binary the firmware came from?
AFAIK, fwcutter can only get the version from the foreign driver. It can be gotten from the dmesg output of your inlaws computer, or if you have the extracted firmware files here, you can bundle them up and email them to me privately.
People don't read dmesg.
q.e.d. ;)
Signature · 1 line
Greetings Michael.
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 26 lines · Somebody in the thread at some point
Quoted 16 lines · On Friday 20 July 2007 18:58:24 Larry Finger wrote:
Quoted 3 lines · Andy Green
Understood, that is why I consider it a bad thing that functionality that can be done in the mac80211 driver is pushed into the binary-only firmware when there is a choice (otherwise known as "paranoia", apparently).
Unfortunately, that is a necessary result of this type of reverse-engineering. If Broadcom put some function in the firmware, we have to leave it there as we have no idea what would break.
Quoted 9 lines
However you stripped some quoting from Michael:
''But it is actually no problem in reality, as the use-it-or-die firmware doesn't have this problem. So if someone uses another firmware than the one we suggest, he will probably run into more problems, as well.
The fix is called: Use the correct firmware.
For now, at least.''Quoted 8 lines
Quoted 5 lines
I would summarize this that Michael is telling me one pariticular version of firmware - "use it or die firmware" - is especially blessed/correct. It might be an idea to let people know they have strayed from the dependency of the required firmware version in dmesg if indeed there is an effective dependency of the driver on it.
It isn't that it is blessed or correct, but that it has been tested. Your version has not. Who knows what else might have changed? Once we know the version with the different behavior, a warning message can be prepared. I don't think anyone knew about this problem until you submitted your patch.
Quoted 5 lines
People don't read dmesg. Adding a "This firmware is unsupported" would have no effect.
I experience same thing for the "bcm43xx-does-not-support-v3-issue". There is a clear error message saying what to do exactly. And _still_ people mail me asking what this message means.
Sure, but naturally you don't hear from the presumably nonzero amount of people who saw and understood the message. Whereas if there was no message at all, only disgusted and baffled people are possible.
Quoted 11 lines
The use-or-die firmware is here:
http://linuxwireless.org/en/users/Drivers/bcm43xxQuoted 5 lines
Quoted 2 lines
Can I still get the firmware version from fwcutter if I don't have the original Windows binary the firmware came from?
AFAIK, fwcutter can only get the version from the foreign driver. It can be gotten from the dmesg output of your inlaws computer, or if you have the extracted firmware files here, you can bundle them up and email them to me privately.
People don't read dmesg.
q.e.d. ;)
Actually, I can't read dmesg on my In-laws' box that has the card the last few weeks: I read dmesg all the time if I suspect kernel-side trouble. It's pretty simple and cheap to do a printk and give someone with problems the ability to dig themselves out of the trouble with a clue and even a URL in this case.
If the driver is dependent on a particular version of an external file, and you can read the version of that file at runtime, you really ought to be issuing a diagnostic if the dependency is violated.
-Andy
Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Quoted 9 lines · On Friday 20 July 2007 19:48:20 Andy Green wrote:
Actually, I can't read dmesg on my In-laws' box that has the card the last few weeks: I read dmesg all the time if I suspect kernel-side trouble. It's pretty simple and cheap to do a printk and give someone with problems the ability to dig themselves out of the trouble with a clue and even a URL in this case.
If the driver is dependent on a particular version of an external file, and you can read the version of that file at runtime, you really ought to be issuing a diagnostic if the dependency is violated.
Well, alternatively you can help to debug this bug, as this is the only known bug regarding fw version.
You could get different versions and test them. So kind of bisecting the actual change version.
Signature · 1 line
Greetings Michael.
Johannes Berg
maintainerRe: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
In reply to Larry FingerQuoted 2 lines · Larry Finger
Unfortunately, that is a necessary result of this type of reverse-engineering. If Broadcom put some function in the firmware, we have to leave it there as we have no idea what would break.
:)
All we're talking here in the thread is this: go to
http://bcm-v4.sipsolutions.net/802.11/RX and you see I said "(newer ucode)" there. We need to find out what revision that is. If people send me a whole bunch of firmware files I can disassemble them to find out. Or, which is faster, they can just test if they see the right info.
johannes