[RFC] bcm43xx: Replacement of TODO statements in keymac_write
Routine keymac_write in bcm43xx has two TODO statements that generate lots of
useless log output for early chip versions. This patch replaces them with code
to store the keys.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Michael,
Is this correct? The whole business of words versus bytes in shared memory
is very confusing.
Larry
-
bcm43xx.h |1 +
bcm43xx_main.c | 21 +
2 files changed, 18 insertions(+), 4 deletions(-)
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -156,6 +156,7 @@
/* MacFilter offsets. */
#define BCM43xx_MACFILTER_SELF 0x
#define BCM43xx_MACFILTER_ASSOC0x0003
+#define BCM43xx_MACFILTER_MAC 0x0010
/* Chipcommon registers. */
#define BCM43xx_CHIPCOMMON_CAPABILITIES0x04
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -378,6 +378,7 @@ static void bcm43xx_macfilter_clear(stru
const u8 zero_addr[ETH_ALEN] = { 0 };
bcm43xx_macfilter_set(bcm, offset, zero_addr);
+ bcm43xx_shm_write32(bcm, BCM43xx_SHM_SHARED, 0x003E, 0);
}
static void bcm43xx_write_mac_bssid_templates(struct bcm43xx_private *bcm)
@@ -1108,12 +1109,24 @@ static void keymac_write(struct bcm43xx_
(index * 2) + 1,
cpu_to_be16(*((u16 *)(addr + 1;
} else {
- if (index 8) {
- TODO(); /* Put them in the macaddress filter */
+ if (index 4) {
+ bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_MAC +
+ index * 6, (const u8 *)addr);
} else {
- TODO();
/* Put them BCM43xx_SHM_SHARED, stating index 0x0120.
- Keep in mind to update the count of keymacs in
0x003E as well! */
+ Update the count of keymacs in 0x003E as well */
+ bcm43xx_shm_write32(bcm,
+ BCM43xx_SHM_SHARED,
+ (index - 4) * 6 + 0x120,
+ cpu_to_be32(*addr));
+ bcm43xx_shm_write16(bcm,
+ BCM43xx_SHM_SHARED,
+ (index - 4) * 6 + 0x124,
+ cpu_to_be16(*((u16 *)(addr + 1;
+ bcm43xx_shm_write32(bcm,/* update count */
+ BCM43xx_SHM_SHARED, 0x003E,
+ bcm43xx_shm_read32(bcm,
+ BCM43xx_SHM_SHARED, 0x003E) + 1);
}
}
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx: Replacement of TODO statements in keymac_write
On Tuesday 31 July 2007 17:06:04 Larry Finger wrote:
Routine keymac_write in bcm43xx has two TODO statements that generate lots of
useless log output for early chip versions. This patch replaces them with code
to store the keys.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Michael,
Is this correct? The whole business of words versus bytes in shared memory
is very confusing.
No, it's completely broken. It's broken like all the other
hwcrypto stuff in the softmac driver. :)
Please simply remove all that hwcrypto stuff and always force
swcrypto.
Larry
-
bcm43xx.h |1 +
bcm43xx_main.c | 21 +
2 files changed, 18 insertions(+), 4 deletions(-)
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -156,6 +156,7 @@
/* MacFilter offsets. */
#define BCM43xx_MACFILTER_SELF 0x
#define BCM43xx_MACFILTER_ASSOC 0x0003
+#define BCM43xx_MACFILTER_MAC0x0010
/* Chipcommon registers. */
#define BCM43xx_CHIPCOMMON_CAPABILITIES 0x04
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -378,6 +378,7 @@ static void bcm43xx_macfilter_clear(stru
const u8 zero_addr[ETH_ALEN] = { 0 };
bcm43xx_macfilter_set(bcm, offset, zero_addr);
+ bcm43xx_shm_write32(bcm, BCM43xx_SHM_SHARED, 0x003E, 0);
}
static void bcm43xx_write_mac_bssid_templates(struct bcm43xx_private *bcm)
@@ -1108,12 +1109,24 @@ static void keymac_write(struct bcm43xx_
(index * 2) + 1,
cpu_to_be16(*((u16 *)(addr + 1;
} else {
- if (index 8) {
- TODO(); /* Put them in the macaddress filter */
+ if (index 4) {
+ bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_MAC +
+ index * 6, (const u8 *)addr);
} else {
- TODO();
/* Put them BCM43xx_SHM_SHARED, stating index 0x0120.
-Keep in mind to update the count of keymacs in
0x003E as well! */
+Update the count of keymacs in 0x003E as well */
+ bcm43xx_shm_write32(bcm,
+ BCM43xx_SHM_SHARED,
+ (index - 4) * 6 + 0x120,
+ cpu_to_be32(*addr));
+ bcm43xx_shm_write16(bcm,
+ BCM43xx_SHM_SHARED,
+ (index - 4) * 6 + 0x124,
+ cpu_to_be16(*((u16 *)(addr + 1;
+ bcm43xx_shm_write32(bcm,/* update count */
+ BCM43xx_SHM_SHARED, 0x003E,
+ bcm43xx_shm_read32(bcm,
+ BCM43xx_SHM_SHARED, 0x003E) + 1);
}
}
}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be needed. IMHO it should be selected automatically when debug is selected. With debug_fs enabled I can remove and insert the module, scan network and associate just fine. When 0-4 meters away from AP I get a steady rate of 18.5Mbps with iperf. When walking further away the transmission stops completely. This is when module is loaded and interface brought up next to the AP. I then get 54Mbit connection. When loading the module from 5 metres away I get 1Mbit connection which is not very stable, but still usable. Rate doesn't seem to change when signal drops. If it were I'm sure bcm4301 would be on par or better than the driver for that other os. I feel it's very close with this driver. I've never got more than 500kbit TX speed with the bcm43xx driver. Keep up the good work! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
On Wednesday 01 August 2007 01:18:46 Richard Jonsson wrote: I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be needed. IMHO it should be selected automatically when debug is selected. Whoops, no. This is a biiig bug and it should _not_ be SELECTed ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
On 7/31/07, Richard Jonsson [EMAIL PROTECTED] wrote: When 0-4 meters away from AP I get a steady rate of 18.5Mbps with iperf. When walking further away the transmission stops completely. This is when module is loaded and interface brought up next to the AP. I then get 54Mbit connection. When loading the module from 5 metres away I get 1Mbit connection which is not very stable, but still usable. Rate doesn't seem to change when signal drops. If it were I'm sure bcm4301 would be on par or better than the driver for that other os. Same here, BCM4306, Apple PowerBook G4 17. It works great until I get more than a few yards away, then...nothing. -- Andrew Barr We matter more than pounds and pence, your economic theory makes no sense... ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
Michael Buesch wrote: On Wednesday 01 August 2007 01:18:46 Richard Jonsson wrote: I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be needed. IMHO it should be selected automatically when debug is selected. Whoops, no. This is a biiig bug and it should _not_ be SELECTed ;) Why? My system has CONFIG_DEBUG_FS selected. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
On Wednesday 01 August 2007 01:29:36 Larry Finger wrote: Michael Buesch wrote: On Wednesday 01 August 2007 01:18:46 Richard Jonsson wrote: I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be needed. IMHO it should be selected automatically when debug is selected. Whoops, no. This is a biiig bug and it should _not_ be SELECTed ;) Why? My system has CONFIG_DEBUG_FS selected. With not SELECTed I mean the KConfig SELECT statement. That shouldn't be used here. He was talking about selected automatically, which is what KConfig SELECT does. And I said that this was not desired here. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
Andrew J. Barr wrote: On 7/31/07, Richard Jonsson [EMAIL PROTECTED] wrote: When 0-4 meters away from AP I get a steady rate of 18.5Mbps with iperf. When walking further away the transmission stops completely. This is when module is loaded and interface brought up next to the AP. I then get 54Mbit connection. When loading the module from 5 metres away I get 1Mbit connection which is not very stable, but still usable. Rate doesn't seem to change when signal drops. If it were I'm sure bcm4301 would be on par or better than the driver for that other os. Same here, BCM4306, Apple PowerBook G4 17. It works great until I get more than a few yards away, then...nothing. Please enter the command 'echo 1 /sys/kernel/debug/bcm43xx/phyX/debug_xmitpower', where X is the correct value. It will start at 0 when just booted and increase by 1 each time the modules is reloaded. Send me the TX power output from dmesg. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
/sys/kernel/debug/bcm43xx/phyX
Michael, Is it expected that X in the subject will increase by 1 each time the bcm43xx-mac80211 module is unloaded and reloaded? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Reason for power problem with bcm43xx
Guys, Tonight I was looking at the output from TXpower debug as I moved my computer away from the AP, and began to wonder why the desired power was not changing as I did so. After dumping the portion of shared memory used in the calculation, I found that addresses 0x0058, 0x005A, 0x0070 and 0x0072 always contain 0x7F7F, which is supposed to be the indication that no transmissions have been sent. Somewhere we seem to have missed a signal to the firmware to update these TSSI values, and the desired power never changes. Suddenly, the low power and the lack of adaptability with distance are no longer a mystery. Does this ring any bells in the reverse engineering camp? Would making a ring buffer containing the last 4 RSSI values be a first approximation to the TSSI's? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Reason for power problem with bcm43xx
Larry Finger wrote: Guys, Tonight I was looking at the output from TXpower debug as I moved my computer away from the AP, and began to wonder why the desired power was not changing as I did so. After dumping the portion of shared memory used in the calculation, I found that addresses 0x0058, 0x005A, 0x0070 and 0x0072 always contain 0x7F7F, which is supposed to be the indication that no transmissions have been sent. Somewhere we seem to have missed a signal to the firmware to update these TSSI values, and the desired power never changes. Suddenly, the low power and the lack of adaptability with distance are no longer a mystery. Never mind - I found the place where the TSSI values are reset. I still wonder why desired power isn't a function of received power. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
