[PATCH] b43: Fix upload of beacon packets to the hardware
This fixes uploading of the beacon data and writing of the
TIM and DTIM offsets.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-26
16:57:01.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-26
17:40:07.0 +0100
@@ -1146,15 +1146,58 @@ static void b43_write_beacon_template(st
u16 ram_offset,
u16 shm_size_offset, u8 rate)
{
- int len;
- const u8 *data;
+ int i, len;
+ const struct ieee80211_mgmt *bcn;
+ const u8 *ie;
+ bool tim_found = 0;
- B43_WARN_ON(!dev-cached_beacon);
- len = min((size_t) dev-cached_beacon-len,
+ bcn = (const struct ieee80211_mgmt *)(dev-wl-current_beacon-data);
+ len = min((size_t) dev-wl-current_beacon-len,
0x200 - sizeof(struct b43_plcp_hdr6));
- data = (const u8 *)(dev-cached_beacon-data);
- b43_write_template_common(dev, data,
+
+ b43_write_template_common(dev, (const u8 *)bcn,
len, ram_offset, shm_size_offset, rate);
+
+ /* Find the position of the TIM and the DTIM_period value
+* and write them to SHM. */
+ ie = bcn-u.beacon.variable;
+ for (i = 0; i len - 2; ) {
+ uint8_t ie_id, ie_len;
+
+ ie_id = ie[i];
+ ie_len = ie[i + 1];
+ if (ie_id == 5) {
+ u16 tim_position;
+ u16 dtim_period;
+ /* This is the TIM Information Element */
+
+ /* Check whether the ie_len is in the beacon data
range. */
+ if (len ie_len + 2 + i)
+ break;
+ /* A valid TIM is at least 4 bytes long. */
+ if (ie_len 4)
+ break;
+ tim_found = 1;
+
+ tim_position = sizeof(struct b43_plcp_hdr6);
+ tim_position += offsetof(struct ieee80211_mgmt,
u.beacon.variable);
+ tim_position += i;
+
+ dtim_period = ie[i + 3];
+
+ b43_shm_write16(dev, B43_SHM_SHARED,
+ B43_SHM_SH_TIMBPOS, tim_position);
+ b43_shm_write16(dev, B43_SHM_SHARED,
+ B43_SHM_SH_DTIMPER, dtim_period);
+ break;
+ }
+ i += ie_len + 2;
+ }
+ if (!tim_found) {
+ b43warn(dev-wl, Did not find a valid TIM IE in
+ the beacon template packet. AP or IBSS operation
+ may be broken.\n);
+ }
}
static void b43_write_probe_resp_plcp(struct b43_wldev *dev,
@@ -1182,40 +1225,43 @@ static void b43_write_probe_resp_plcp(st
* 2) Patching duration field
* 3) Stripping TIM
*/
-static u8 *b43_generate_probe_resp(struct b43_wldev *dev,
- u16 * dest_size, u8 rate)
+static const u8 * b43_generate_probe_resp(struct b43_wldev *dev,
+ u16 *dest_size, u8 rate)
{
const u8 *src_data;
u8 *dest_data;
u16 src_size, elem_size, src_pos, dest_pos;
__le16 dur;
struct ieee80211_hdr *hdr;
+ size_t ie_start;
+
+ src_size = dev-wl-current_beacon-len;
+ src_data = (const u8 *)dev-wl-current_beacon-data;
- B43_WARN_ON(!dev-cached_beacon);
- src_size = dev-cached_beacon-len;
- src_data = (const u8 *)dev-cached_beacon-data;
+ /* Get the start offset of the variable IEs in the packet. */
+ ie_start = offsetof(struct ieee80211_mgmt, u.probe_resp.variable);
+ B43_WARN_ON(ie_start != offsetof(struct ieee80211_mgmt,
u.beacon.variable));
- if (unlikely(src_size 0x24)) {
- b43dbg(dev-wl, b43_generate_probe_resp: invalid beacon\n);
+ if (B43_WARN_ON(src_size ie_start))
return NULL;
- }
dest_data = kmalloc(src_size, GFP_ATOMIC);
if (unlikely(!dest_data))
return NULL;
- /* 0x24 is offset of first variable-len Information-Element
-* in beacon frame.
-*/
- memcpy(dest_data, src_data, 0x24);
- src_pos = dest_pos = 0x24;
- for (; src_pos src_size - 2; src_pos += elem_size) {
+ /* Copy the static data and all Information Elements, except the TIM. */
+ memcpy(dest_data, src_data, ie_start);
+ src_pos = ie_start;
+ dest_pos = ie_start;
+ for ( ; src_pos src_size - 2; src_pos += elem_size) {
elem_size = src_data[src_pos + 1] + 2;
- if (src_data
[PATCH] b43: Fix template upload locking.
This fixes the template upload locking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-26
17:57:08.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-26
18:01:03.0 +0100
@@ -1303,26 +1303,21 @@ static void b43_write_probe_resp_templat
kfree(probe_resp_data);
}
-/* Asynchronously update the packet templates in template RAM. */
+/* Asynchronously update the packet templates in template RAM.
+ * Locking: Requires wl-irq_lock to be locked. */
static void b43_update_templates(struct b43_wl *wl, struct sk_buff *beacon)
{
- unsigned long flags;
-
/* This is the top half of the ansynchronous beacon update.
* The bottom half is the beacon IRQ.
* Beacon update must be asynchronous to avoid sending an
* invalid beacon. This can happen for example, if the firmware
* transmits a beacon while we are updating it. */
- spin_lock_irqsave(wl-irq_lock, flags);
-
if (wl-current_beacon)
dev_kfree_skb_any(wl-current_beacon);
wl-current_beacon = beacon;
wl-beacon0_uploaded = 0;
wl-beacon1_uploaded = 0;
-
- spin_unlock_irqrestore(wl-irq_lock, flags);
}
static void b43_set_ssid(struct b43_wldev *dev, const u8 * ssid, u8 ssid_len)
@@ -3587,6 +3582,7 @@ static int b43_op_beacon_set_tim(struct
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct sk_buff *beacon;
+ unsigned long flags;
/* We could modify the existing beacon and set the aid bit in
* the TIM field, but that would probably require resizing and
@@ -3595,7 +3591,9 @@ static int b43_op_beacon_set_tim(struct
beacon = ieee80211_beacon_get(hw, wl-vif, NULL);
if (unlikely(!beacon))
return -ENOMEM;
+ spin_lock_irqsave(wl-irq_lock, flags);
b43_update_templates(wl, beacon);
+ spin_unlock_irqrestore(wl-irq_lock, flags);
return 0;
}
@@ -3605,8 +3603,11 @@ static int b43_op_ibss_beacon_update(str
struct ieee80211_tx_control *ctl)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
+ unsigned long flags;
+ spin_lock_irqsave(wl-irq_lock, flags);
b43_update_templates(wl, beacon);
+ spin_unlock_irqrestore(wl-irq_lock, flags);
return 0;
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Put multicast frames on the mcast queue
This queues frames flagged as send after DTIM by mac80211
on the special multicast queue. The firmware will take care
to send the packet after the DTIM.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2007-12-26
18:04:52.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2007-12-26 18:07:11.0
+0100
@@ -171,14 +171,17 @@ enum {
#define B43_SHM_SH_SLOTT 0x0010 /* Slot time */
#define B43_SHM_SH_DTIMPER 0x0012 /* DTIM period */
#define B43_SHM_SH_NOSLPZNATDTIM 0x004C /* NOSLPZNAT DTIM */
-/* SHM_SHARED beacon variables */
+/* SHM_SHARED beacon/AP variables */
#define B43_SHM_SH_BTL00x0018 /* Beacon template
length 0 */
#define B43_SHM_SH_BTL10x001A /* Beacon template
length 1 */
#define B43_SHM_SH_BTSFOFF 0x001C /* Beacon TSF offset */
#define B43_SHM_SH_TIMBPOS 0x001E /* TIM B position in beacon */
+#define B43_SHM_SH_DTIMP 0x0012 /* DTIP period */
+#define B43_SHM_SH_MCASTCOOKIE 0x00A8 /* Last bcast/mcast frame ID */
#define B43_SHM_SH_SFFBLIM 0x0044 /* Short frame fallback retry
limit */
#define B43_SHM_SH_LFFBLIM 0x0046 /* Long frame fallback retry
limit */
#define B43_SHM_SH_BEACPHYCTL 0x0054 /* Beacon PHY TX control word
(see PHY TX control) */
+#define B43_SHM_SH_EXTNPHYCTL 0x00B0 /* Extended bytes for beacon
PHY control (N) */
/* SHM_SHARED ACK/CTS control */
#define B43_SHM_SH_ACKCTSPHYCTL0x0022 /* ACK/CTS PHY control
word (see PHY TX control) */
/* SHM_SHARED probe response variables */
@@ -612,9 +615,12 @@ struct b43_wl {
/* Pointer to the ieee80211 hardware data structure */
struct ieee80211_hw *hw;
- spinlock_t irq_lock;
struct mutex mutex;
+ spinlock_t irq_lock;
+ /* Lock for LEDs access. */
spinlock_t leds_lock;
+ /* Lock for SHM access. */
+ spinlock_t shm_lock;
/* We can only have one operating interface (802.11 core)
* at a time. General information about this interface follows.
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c2007-12-26
17:57:08.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/dma.c 2007-12-26 18:14:15.0
+0100
@@ -37,6 +37,8 @@
#include linux/pci.h
#include linux/delay.h
#include linux/skbuff.h
+#include linux/etherdevice.h
+
/* 32bit DMA ops. */
static
@@ -315,26 +317,24 @@ static struct b43_dmaring *priority_to_t
case 3:
ring = dev-dma.tx_ring0;
break;
- case 4:
- ring = dev-dma.tx_ring4;
- break;
- case 5:
- ring = dev-dma.tx_ring5;
- break;
}
return ring;
}
-/* Bcm43xx-ring to mac80211-queue mapping */
+/* b43-ring to mac80211-queue mapping */
static inline int txring_to_priority(struct b43_dmaring *ring)
{
- static const u8 idx_to_prio[] = { 3, 2, 1, 0, 4, 5, };
+ static const u8 idx_to_prio[] = { 3, 2, 1, 0, };
+ unsigned int index;
/*FIXME: have only one queue, for now */
return 0;
- return idx_to_prio[ring-index];
+ index = ring-index;
+ if (B43_WARN_ON(index = ARRAY_SIZE(idx_to_prio)))
+ index = 0;
+ return idx_to_prio[index];
}
u16 b43_dmacontroller_base(int dma64bit, int controller_idx)
@@ -1043,26 +1043,30 @@ static u16 generate_cookie(struct b43_dm
* in the lower 12 bits.
* Note that the cookie must never be 0, as this
* is a special value used in RX path.
+* It can also not be 0x because that is special
+* for multicast frames.
*/
switch (ring-index) {
case 0:
- cookie = 0xA000;
+ cookie = 0x1000;
break;
case 1:
- cookie = 0xB000;
+ cookie = 0x2000;
break;
case 2:
- cookie = 0xC000;
+ cookie = 0x3000;
break;
case 3:
- cookie = 0xD000;
+ cookie = 0x4000;
break;
case 4:
- cookie = 0xE000;
+ cookie = 0x5000;
break;
case 5:
- cookie = 0xF000;
+ cookie = 0x6000;
break;
+ default:
+ B43_WARN_ON(1);
}
B43_WARN_ON(slot ~0x0FFF);
cookie |= (u16) slot;
@@ -1078,22 +1082,22 @@ struct b43_dmaring *parse_cookie(struct
struct b43_dmaring *ring = NULL;
switch (cookie
[PATCH] b43: Fix tim search buffer overrun
Use the length of the variable section of the beacon instead of the
whole beacon length for bounds checking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-26
18:20:38.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-27
22:05:07.0 +0100
@@ -1161,7 +1161,7 @@ static void b43_write_beacon_template(st
u16 ram_offset,
u16 shm_size_offset, u8 rate)
{
- int i, len;
+ unsigned int i, len, variable_len;
const struct ieee80211_mgmt *bcn;
const u8 *ie;
bool tim_found = 0;
@@ -1176,7 +1176,8 @@ static void b43_write_beacon_template(st
/* Find the position of the TIM and the DTIM_period value
* and write them to SHM. */
ie = bcn-u.beacon.variable;
- for (i = 0; i len - 2; ) {
+ variable_len = len - offsetof(struct ieee80211_mgmt, u.beacon.variable);
+ for (i = 0; i variable_len - 2; ) {
uint8_t ie_id, ie_len;
ie_id = ie[i];
@@ -1187,7 +1188,7 @@ static void b43_write_beacon_template(st
/* This is the TIM Information Element */
/* Check whether the ie_len is in the beacon data
range. */
- if (len ie_len + 2 + i)
+ if (variable_len ie_len + 2 + i)
break;
/* A valid TIM is at least 4 bytes long. */
if (ie_len 4)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix rxheader channel parsing
This patch fixes the parsing of the RX data header channel field.
The current code parses the header incorrectly and passes a wrong
channel number and frequency for each frame to mac80211.
The FIXMEs added by this patch don't matter for now as the code
where they live won't get executed anyway. They will be fixed later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this is a bugfix, it should go into 2.6.24 if still possible.
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/xmit.c 2007-12-30
20:30:03.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/xmit.c2008-01-02
18:13:15.0 +0100
@@ -549,21 +549,32 @@ void b43_rx(struct b43_wldev *dev, struc
switch (chanstat B43_RX_CHAN_PHYTYPE) {
case B43_PHYTYPE_A:
status.phymode = MODE_IEEE80211A;
- status.freq = chanid;
- status.channel = b43_freq_to_channel_a(chanid);
- break;
- case B43_PHYTYPE_B:
- status.phymode = MODE_IEEE80211B;
- status.freq = chanid + 2400;
- status.channel = b43_freq_to_channel_bg(chanid + 2400);
+ B43_WARN_ON(1);
+ /* FIXME: We don't really know which value the chanid
contains.
+*So the following assignment might be wrong. */
+ status.channel = chanid;
+ status.freq = b43_channel_to_freq_5ghz(status.channel);
break;
case B43_PHYTYPE_G:
status.phymode = MODE_IEEE80211G;
+ /* chanid is the radio channel cookie value as used
+* to tune the radio. */
status.freq = chanid + 2400;
- status.channel = b43_freq_to_channel_bg(chanid + 2400);
+ status.channel = b43_freq_to_channel_2ghz(status.freq);
+ break;
+ case B43_PHYTYPE_N:
+ status.phymode = 0xDEAD /*FIXME MODE_IEEE80211N*/;
+ /* chanid is the SHM channel cookie. Which is the plain
+* channel number in b43. */
+ status.channel = chanid;
+ if (chanstat B43_RX_CHAN_5GHZ)
+ status.freq = b43_freq_to_channel_5ghz(status.freq);
+ else
+ status.freq = b43_freq_to_channel_2ghz(status.freq);
break;
default:
B43_WARN_ON(1);
+ goto drop;
}
dev-stats.last_rx = jiffies;
Index: wireless-2.6/drivers/net/wireless/b43/xmit.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/xmit.h 2007-12-30
20:30:03.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/xmit.h2008-01-02
16:42:24.0 +0100
@@ -142,49 +142,56 @@ struct b43_rxhdr_fw4 {
} __attribute__ ((__packed__));
/* PHY RX Status 0 */
-#define B43_RX_PHYST0_GAINCTL 0x4000 /* Gain Control */
-#define B43_RX_PHYST0_PLCPHCF 0x0200
-#define B43_RX_PHYST0_PLCPFV 0x0100
-#define B43_RX_PHYST0_SHORTPRMBL 0x0080 /* Received with Short Preamble
*/
+#define B43_RX_PHYST0_GAINCTL 0x4000 /* Gain Control */
+#define B43_RX_PHYST0_PLCPHCF 0x0200
+#define B43_RX_PHYST0_PLCPFV 0x0100
+#define B43_RX_PHYST0_SHORTPRMBL 0x0080 /* Received with Short Preamble
*/
#define B43_RX_PHYST0_LCRS 0x0040
-#define B43_RX_PHYST0_ANT 0x0020 /* Antenna */
-#define B43_RX_PHYST0_UNSRATE 0x0010
+#define B43_RX_PHYST0_ANT 0x0020 /* Antenna */
+#define B43_RX_PHYST0_UNSRATE 0x0010
#define B43_RX_PHYST0_CLIP 0x000C
#define B43_RX_PHYST0_CLIP_SHIFT 2
-#define B43_RX_PHYST0_FTYPE0x0003 /* Frame type */
-#define B43_RX_PHYST0_CCK 0x /* Frame type: CCK */
-#define B43_RX_PHYST0_OFDM0x0001 /* Frame type: OFDM */
-#define B43_RX_PHYST0_PRE_N 0x0002 /* Pre-standard N-PHY frame */
-#define B43_RX_PHYST0_STD_N 0x0003 /* Standard N-PHY frame */
+#define B43_RX_PHYST0_FTYPE0x0003 /* Frame type */
+#define B43_RX_PHYST0_CCK 0x /* Frame type: CCK */
+#define B43_RX_PHYST0_OFDM0x0001 /* Frame type: OFDM */
+#define B43_RX_PHYST0_PRE_N 0x0002 /* Pre-standard N-PHY frame */
+#define B43_RX_PHYST0_STD_N 0x0003 /* Standard N-PHY frame */
/* PHY RX Status 2 */
-#define B43_RX_PHYST2_LNAG 0xC000 /* LNA Gain */
+#define B43_RX_PHYST2_LNAG 0xC000 /* LNA Gain */
#define B43_RX_PHYST2_LNAG_SHIFT 14
-#define B43_RX_PHYST2_PNAG 0x3C00 /* PNA Gain */
+#define B43_RX_PHYST2_PNAG 0x3C00 /* PNA Gain */
#define B43_RX_PHYST2_PNAG_SHIFT 10
-#define B43_RX_PHYST2_FOFF 0x03FF /* F offset */
+#define B43_RX_PHYST2_FOFF 0x03FF
Re: [PATCH] b43: Fix rxheader channel parsing
On Wednesday 02 January 2008 19:52:08 Larry Finger wrote:
Michael Buesch wrote:
This patch fixes the parsing of the RX data header channel field.
The current code parses the header incorrectly and passes a wrong
channel number and frequency for each frame to mac80211.
The FIXMEs added by this patch don't matter for now as the code
where they live won't get executed anyway. They will be fixed later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this is a bugfix, it should go into 2.6.24 if still possible.
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/xmit.c 2007-12-30
20:30:03.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/xmit.c2008-01-02
18:13:15.0 +0100
@@ -549,21 +549,32 @@ void b43_rx(struct b43_wldev *dev, struc
switch (chanstat B43_RX_CHAN_PHYTYPE) {
case B43_PHYTYPE_A:
status.phymode = MODE_IEEE80211A;
- status.freq = chanid;
- status.channel = b43_freq_to_channel_a(chanid);
- break;
- case B43_PHYTYPE_B:
- status.phymode = MODE_IEEE80211B;
- status.freq = chanid + 2400;
- status.channel = b43_freq_to_channel_bg(chanid + 2400);
+ B43_WARN_ON(1);
+ /* FIXME: We don't really know which value the chanid
contains.
+*So the following assignment might be wrong. */
+ status.channel = chanid;
+ status.freq = b43_channel_to_freq_5ghz(status.channel);
break;
Shouldn't you just drop this case? No B PHY devices will ever use b43 and the
default branch will
issue the WARN_ON anyway.
I guess you misread the patch.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix rxheader channel parsing
On Wednesday 02 January 2008 20:37:41 Ehud Gavron wrote: Happy New Year, Michael! :) Yeah, thanks. :) Happy New Year to everyone on the list. Let's work on making The Linux Wireless Year (tm) out of it. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Device busy error
On Wednesday 02 January 2008 21:18:29 David Ellingsworth wrote: While using the b43legacy driver with my 4306 card, wpa_supplicant and iwconfig both report that the device is busy when trying to switch from monitor mode to managed mode after having used kismet or airodump-ng. So far the only resolution to the issue has been to rmmod and then modprobe the driver again. Any help in finding the cause of the error would be appreciated. ifconfig wlanX down before switching modes. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Device busy error
You have a bogus Reply-To: [EMAIL PROTECTED] inside of your mailheaders, which confuses mailclients. See the attached bounce. -- Greetings Michael. This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] Unrouteable address -- This is a copy of the message, including all the headers. -- Return-path: [EMAIL PROTECTED] Received: from t1fa0.t.pppool.de ([89.55.31.160] helo=powermac.local) by vs166246.vserver.de with esmtpa (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1JAAl5-0004Yv-Ft; Wed, 02 Jan 2008 21:04:15 + From: Michael Buesch [EMAIL PROTECTED] To: bcm43xx-dev@lists.berlios.de, [EMAIL PROTECTED] Subject: Re: Device busy error Date: Wed, 2 Jan 2008 22:03:40 +0100 User-Agent: KMail/1.9.6 References: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: [EMAIL PROTECTED] On Wednesday 02 January 2008 21:18:29 David Ellingsworth wrote: While using the b43legacy driver with my 4306 card, wpa_supplicant and iwconfig both report that the device is busy when trying to switch from monitor mode to managed mode after having used kismet or airodump-ng. So far the only resolution to the issue has been to rmmod and then modprobe the driver again. Any help in finding the cause of the error would be appreciated. ifconfig wlanX down before switching modes. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Fix probing of PCI cores if PCI and PCIE core is available
This will make sure that always the correct core is selected, even if
there are both a PCI and PCI-E core on a PCI or PCI-E card.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this is a bugfix it should probably go into 2.6.24.
Index: wireless-2.6/drivers/ssb/scan.c
===
--- wireless-2.6.orig/drivers/ssb/scan.c2008-01-02 18:49:22.0
+0100
+++ wireless-2.6/drivers/ssb/scan.c 2008-01-03 18:56:30.0 +0100
@@ -388,6 +388,17 @@ int ssb_bus_scan(struct ssb_bus *bus,
case SSB_DEV_PCI:
case SSB_DEV_PCIE:
#ifdef CONFIG_SSB_DRIVER_PCICORE
+ if (bus-bustype == SSB_BUSTYPE_PCI) {
+ /* Ignore PCI cores on PCI-E cards.
+* Ignore PCI-E cores on PCI cards. */
+ if (dev-id.coreid == SSB_DEV_PCI) {
+ if (bus-host_pci-is_pcie)
+ continue;
+ } else {
+ if (!bus-host_pci-is_pcie)
+ continue;
+ }
+ }
if (bus-pcicore.dev) {
ssb_printk(KERN_WARNING PFX
WARNING: Multiple PCI(E) cores
found\n);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43-ssb-bridge: Add PCI ID for BCM43XG
This adds the PCI ID 0x4329 for the BCM43XG.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is stuff for 2.6.25
Index: wireless-2.6/drivers/ssb/b43_pci_bridge.c
===
--- wireless-2.6.orig/drivers/ssb/b43_pci_bridge.c 2007-12-11
01:08:40.0 +0100
+++ wireless-2.6/drivers/ssb/b43_pci_bridge.c 2008-01-03 18:08:44.0
+0100
@@ -28,6 +28,7 @@ static const struct pci_device_id b43_pc
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4328) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4329) },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add NPHY kconfig option
This adds a new Kconfig option for enabling probing of N-PHYs. This option will be removed again once the stuff works. For now it is to help in development. This way real users won't execute the broken N-PHY codepaths, but the developers can easily enable N-PHY stuff. To enable N-PHY probing simply remove the BROKEN dependency and enable the option in the kernel config. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- 2.6.25 stuff. Index: wireless-2.6/drivers/net/wireless/b43/Kconfig === --- wireless-2.6.orig/drivers/net/wireless/b43/Kconfig 2008-01-04 15:01:42.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/Kconfig 2008-01-04 16:59:38.0 +0100 @@ -61,6 +61,16 @@ config B43_PCMCIA If unsure, say N. +config B43_NPHY + bool Pre IEEE 802.11n support (BROKEN) + depends on B43 EXPERIMENTAL BROKEN + ---help--- + Support for the IEEE 802.11n draft. + + THIS IS BROKEN AND DOES NOT WORK YET. + + SAY N. + # This config option automatically enables b43 LEDS support, # if it's possible. config B43_LEDS Index: wireless-2.6/drivers/net/wireless/b43/main.c === --- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-04 15:01:42.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-04 16:57:24.0 +0100 @@ -81,6 +81,7 @@ static const struct ssb_device_id b43_ss SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 7), SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 9), SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 10), + SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 11), SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 13), SSB_DEVTABLE_END }; @@ -3097,6 +3098,12 @@ static int b43_phy_versioning(struct b43 if (phy_rev 9) unsupported = 1; break; +#ifdef CONFIG_B43_NPHY + case B43_PHYTYPE_N: + if (phy_rev 1) + unsupported = 1; + break; +#endif default: unsupported = 1; }; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix any N-PHY related WARN_ON() in the attach stage.
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2008-01-04
15:01:42.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2008-01-04 17:28:03.0
+0100
@@ -332,17 +332,22 @@ enum {
#define B43_MACCMD_CCA 0x0008 /* Clear channel
assessment */
#define B43_MACCMD_BGNOISE 0x0010 /* Background noise */
-/* 802.11 core specific TM State Low flags */
+/* 802.11 core specific TM State Low (SSB_TMSLOW) flags */
#define B43_TMSLOW_GMODE 0x2000 /* G Mode Enable */
-#define B43_TMSLOW_PLLREFSEL 0x0020 /* PLL Frequency
Reference Select */
+#define B43_TMSLOW_PHYCLKSPEED 0x00C0 /* PHY clock speed mask
(N-PHY only) */
+#define B43_TMSLOW_PHYCLKSPEED_40MHZ 0x /* 40 MHz PHY */
+#define B43_TMSLOW_PHYCLKSPEED_80MHZ 0x0040 /* 80 MHz PHY */
+#define B43_TMSLOW_PHYCLKSPEED_160MHZ 0x0080 /* 160 MHz PHY */
+#define B43_TMSLOW_PLLREFSEL 0x0020 /* PLL Frequency
Reference Select (rev = 5) */
#define B43_TMSLOW_MACPHYCLKEN 0x0010 /* MAC PHY Clock
Control Enable (rev = 5) */
#define B43_TMSLOW_PHYRESET0x0008 /* PHY Reset */
#define B43_TMSLOW_PHYCLKEN0x0004 /* PHY Clock Enable */
-/* 802.11 core specific TM State High flags */
+/* 802.11 core specific TM State High (SSB_TMSHIGH) flags */
+#define B43_TMSHIGH_DUALBAND_PHY 0x0008 /* Dualband PHY
available */
#define B43_TMSHIGH_FCLOCK 0x0004 /* Fast Clock Available
(rev = 5) */
-#define B43_TMSHIGH_APHY 0x0002 /* A-PHY available (rev
= 5) */
-#define B43_TMSHIGH_GPHY 0x0001 /* G-PHY available (rev
= 5) */
+#define B43_TMSHIGH_HAVE_5GHZ_PHY 0x0002 /* 5 GHz PHY available
(rev = 5) */
+#define B43_TMSHIGH_HAVE_2GHZ_PHY 0x0001 /* 2.4 GHz PHY
available (rev = 5) */
/* Generic-Interrupt reasons. */
#define B43_IRQ_MAC_SUSPENDED 0x0001
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-04
16:57:24.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-04
18:05:07.0 +0100
@@ -132,7 +132,7 @@ static struct ieee80211_rate __b43_ratet
.power_level= 0xFF, \
.antenna_max= 0xFF, \
}
-static struct ieee80211_channel b43_bg_chantable[] = {
+static struct ieee80211_channel b43_2ghz_chantable[] = {
CHANTAB_ENT(1, 2412),
CHANTAB_ENT(2, 2417),
CHANTAB_ENT(3, 2422),
@@ -148,9 +148,10 @@ static struct ieee80211_channel b43_bg_c
CHANTAB_ENT(13, 2472),
CHANTAB_ENT(14, 2484),
};
+#define b43_2ghz_chantable_sizeARRAY_SIZE(b43_2ghz_chantable)
-#define b43_bg_chantable_size ARRAY_SIZE(b43_bg_chantable)
-static struct ieee80211_channel b43_a_chantable[] = {
+#if 0
+static struct ieee80211_channel b43_5ghz_chantable[] = {
CHANTAB_ENT(36, 5180),
CHANTAB_ENT(40, 5200),
CHANTAB_ENT(44, 5220),
@@ -165,8 +166,8 @@ static struct ieee80211_channel b43_a_ch
CHANTAB_ENT(161, 5805),
CHANTAB_ENT(165, 5825),
};
-
-#define b43_a_chantable_size ARRAY_SIZE(b43_a_chantable)
+#define b43_5ghz_chantable_sizeARRAY_SIZE(b43_5ghz_chantable)
+#endif
static void b43_wireless_core_exit(struct b43_wldev *dev);
static int b43_wireless_core_init(struct b43_wldev *dev);
@@ -1658,7 +1659,7 @@ static int b43_request_firmware(struct b
switch (dev-phy.type) {
case B43_PHYTYPE_A:
if ((rev = 5) (rev = 10)) {
- if (tmshigh B43_TMSHIGH_GPHY)
+ if (tmshigh B43_TMSHIGH_HAVE_2GHZ_PHY)
filename = a0g1initvals5;
else
filename = a0g0initvals5;
@@ -1684,7 +1685,7 @@ static int b43_request_firmware(struct b
switch (dev-phy.type) {
case B43_PHYTYPE_A:
if ((rev = 5) (rev = 10)) {
- if (tmshigh B43_TMSHIGH_GPHY)
+ if (tmshigh B43_TMSHIGH_HAVE_2GHZ_PHY)
filename = a0g1bsinitvals5;
else
filename = a0g0bsinitvals5;
@@ -3695,72 +3696,30 @@ static void b43_chip_reset(struct work_s
}
static int b43_setup_modes(struct
Re: [PATCH] b43: Fix any N-PHY related WARN_ON() in the attach stage.
On Friday 04 January 2008, Michael Buesch wrote: This fixes all WARN_ON()s in the attach stage. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- This is stuff for 2.6.25 I'm sorry, this patch was the wrong one. I'll immediately send the correct one. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH v2] b43: Fix any N-PHY related WARN_ON() in the attach stage.
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
This is patch version 2. Sorry for the inconvenience.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2008-01-04
15:01:42.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2008-01-04 17:28:03.0
+0100
@@ -332,17 +332,22 @@ enum {
#define B43_MACCMD_CCA 0x0008 /* Clear channel
assessment */
#define B43_MACCMD_BGNOISE 0x0010 /* Background noise */
-/* 802.11 core specific TM State Low flags */
+/* 802.11 core specific TM State Low (SSB_TMSLOW) flags */
#define B43_TMSLOW_GMODE 0x2000 /* G Mode Enable */
-#define B43_TMSLOW_PLLREFSEL 0x0020 /* PLL Frequency
Reference Select */
+#define B43_TMSLOW_PHYCLKSPEED 0x00C0 /* PHY clock speed mask
(N-PHY only) */
+#define B43_TMSLOW_PHYCLKSPEED_40MHZ 0x /* 40 MHz PHY */
+#define B43_TMSLOW_PHYCLKSPEED_80MHZ 0x0040 /* 80 MHz PHY */
+#define B43_TMSLOW_PHYCLKSPEED_160MHZ 0x0080 /* 160 MHz PHY */
+#define B43_TMSLOW_PLLREFSEL 0x0020 /* PLL Frequency
Reference Select (rev = 5) */
#define B43_TMSLOW_MACPHYCLKEN 0x0010 /* MAC PHY Clock
Control Enable (rev = 5) */
#define B43_TMSLOW_PHYRESET0x0008 /* PHY Reset */
#define B43_TMSLOW_PHYCLKEN0x0004 /* PHY Clock Enable */
-/* 802.11 core specific TM State High flags */
+/* 802.11 core specific TM State High (SSB_TMSHIGH) flags */
+#define B43_TMSHIGH_DUALBAND_PHY 0x0008 /* Dualband PHY
available */
#define B43_TMSHIGH_FCLOCK 0x0004 /* Fast Clock Available
(rev = 5) */
-#define B43_TMSHIGH_APHY 0x0002 /* A-PHY available (rev
= 5) */
-#define B43_TMSHIGH_GPHY 0x0001 /* G-PHY available (rev
= 5) */
+#define B43_TMSHIGH_HAVE_5GHZ_PHY 0x0002 /* 5 GHz PHY available
(rev = 5) */
+#define B43_TMSHIGH_HAVE_2GHZ_PHY 0x0001 /* 2.4 GHz PHY
available (rev = 5) */
/* Generic-Interrupt reasons. */
#define B43_IRQ_MAC_SUSPENDED 0x0001
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-04
16:57:24.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-06
00:05:04.0 +0100
@@ -132,7 +132,7 @@ static struct ieee80211_rate __b43_ratet
.power_level= 0xFF, \
.antenna_max= 0xFF, \
}
-static struct ieee80211_channel b43_bg_chantable[] = {
+static struct ieee80211_channel b43_2ghz_chantable[] = {
CHANTAB_ENT(1, 2412),
CHANTAB_ENT(2, 2417),
CHANTAB_ENT(3, 2422),
@@ -148,9 +148,10 @@ static struct ieee80211_channel b43_bg_c
CHANTAB_ENT(13, 2472),
CHANTAB_ENT(14, 2484),
};
+#define b43_2ghz_chantable_sizeARRAY_SIZE(b43_2ghz_chantable)
-#define b43_bg_chantable_size ARRAY_SIZE(b43_bg_chantable)
-static struct ieee80211_channel b43_a_chantable[] = {
+#if 0
+static struct ieee80211_channel b43_5ghz_chantable[] = {
CHANTAB_ENT(36, 5180),
CHANTAB_ENT(40, 5200),
CHANTAB_ENT(44, 5220),
@@ -165,8 +166,8 @@ static struct ieee80211_channel b43_a_ch
CHANTAB_ENT(161, 5805),
CHANTAB_ENT(165, 5825),
};
-
-#define b43_a_chantable_size ARRAY_SIZE(b43_a_chantable)
+#define b43_5ghz_chantable_sizeARRAY_SIZE(b43_5ghz_chantable)
+#endif
static void b43_wireless_core_exit(struct b43_wldev *dev);
static int b43_wireless_core_init(struct b43_wldev *dev);
@@ -1658,7 +1659,7 @@ static int b43_request_firmware(struct b
switch (dev-phy.type) {
case B43_PHYTYPE_A:
if ((rev = 5) (rev = 10)) {
- if (tmshigh B43_TMSHIGH_GPHY)
+ if (tmshigh B43_TMSHIGH_HAVE_2GHZ_PHY)
filename = a0g1initvals5;
else
filename = a0g0initvals5;
@@ -1684,7 +1685,7 @@ static int b43_request_firmware(struct b
switch (dev-phy.type) {
case B43_PHYTYPE_A:
if ((rev = 5) (rev = 10)) {
- if (tmshigh B43_TMSHIGH_GPHY)
+ if (tmshigh B43_TMSHIGH_HAVE_2GHZ_PHY)
filename = a0g1bsinitvals5;
else
filename = a0g0bsinitvals5;
@@ -3134,6 +3135,8 @@ static int
b43 will need a firmware upgrade soon
The b43 driver will need an incompatible firmware upgrade, soon. I'm probably going to do this in 2.6.25 or 2.6.26. The update will require people to download and extract updated officially supported firmware. The firmware will be linked to from the usual place at linuxwireless.org. The driver will print a verbose error message when it detects too old firmware and abort initialization. This is needed in order to add support for new devices (N-PHY). Broadcom changed the ABI of the firmware, so we are forced to also change the ABI of the driver. I'm very sorry for the inconvenience. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sunday 06 January 2008 21:05:23 Hendrik Sattler wrote: Am Sonntag 06 Januar 2008 schrieb Michael Buesch: The b43 driver will need an incompatible firmware upgrade, soon. I'm probably going to do this in 2.6.25 or 2.6.26. The update will require people to download and extract updated officially supported firmware. The firmware will be linked to from the usual place at linuxwireless.org. The driver will print a verbose error message when it detects too old firmware and abort initialization. This is needed in order to add support for new devices (N-PHY). Broadcom changed the ABI of the firmware, so we are forced to also change the ABI of the driver. I'm very sorry for the inconvenience. Do these firmware files go to a different directory then? I would like to run my current kernel (b43 from git or 2.6.24) and the new one without having to exchange files every time I boot another kernel version. And yes, WLAN is my _only_ connection to the internet. see fwpostfix module parameter -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? Go and complain at Broadcom please. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sunday 06 January 2008 21:34:35 John W. Linville wrote: On Sun, Jan 06, 2008 at 06:02:38PM +0100, Michael Buesch wrote: This is needed in order to add support for new devices (N-PHY). Broadcom changed the ABI of the firmware, so we are forced to also change the ABI of the driver. Do we have reasonable confidence that the newer firmware will run on all the devices currently supported by b43? Or are we looking at another b43legacy type of situation? We need to check this. Maybe we can support both firmware images in the driver. Not sure yet. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sunday 06 January 2008 23:01:00 John W. Linville wrote: On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote: On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? Go and complain at Broadcom please. Broadcom doesn't really have this problem, since they are free to include the binary firmware in their Windows/Mac/whatever drivers. If the driver needs different firmware, why not have it ask for different filenames? As I suggested elsewhere, this could be as simple as setting a default value for fwpostfix... I'm not sure why people are complaining about stuff that's not done, yet. I just said that we need an update to an incompatible firmware soon. HOW that happens is an entirely different question. It seems like we _might_ be able to support both fw versions for some limited time. If that is not possible for whatever reason, I will change the fw filenames, of course. (And people will complain about that, too. Because the rule for broadcom firmware is: Always complain about whatever you do. ;) ) The _just_ wanted to tell people about a serious change _before_ it happens. I'm not sure why this results in all kinds of complaints. Thanks anyway for the feedback. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Monday 07 January 2008 00:28:15 Rafael J. Wysocki wrote: On Monday, 7 of January 2008, Michael Buesch wrote: On Sunday 06 January 2008 23:01:00 John W. Linville wrote: On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote: On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? Go and complain at Broadcom please. Broadcom doesn't really have this problem, since they are free to include the binary firmware in their Windows/Mac/whatever drivers. If the driver needs different firmware, why not have it ask for different filenames? As I suggested elsewhere, this could be as simple as setting a default value for fwpostfix... I'm not sure why people are complaining about stuff that's not done, yet. I just said that we need an update to an incompatible firmware soon. HOW that happens is an entirely different question. It seems like we _might_ be able to support both fw versions for some limited time. If that is not possible for whatever reason, I will change the fw filenames, of course. (And people will complain about that, too. Because the rule for broadcom firmware is: Always complain about whatever you do. ;) ) The _just_ wanted to tell people about a serious change _before_ it happens. I'm not sure why this results in all kinds of complaints. Most probably, because the people don't want that to happen. ;-) People don't want N-PHY support? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Monday 07 January 2008 00:51:55 Rafael J. Wysocki wrote: On Monday, 7 of January 2008, Michael Buesch wrote: On Monday 07 January 2008 00:28:15 Rafael J. Wysocki wrote: On Monday, 7 of January 2008, Michael Buesch wrote: On Sunday 06 January 2008 23:01:00 John W. Linville wrote: On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote: On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? Go and complain at Broadcom please. Broadcom doesn't really have this problem, since they are free to include the binary firmware in their Windows/Mac/whatever drivers. If the driver needs different firmware, why not have it ask for different filenames? As I suggested elsewhere, this could be as simple as setting a default value for fwpostfix... I'm not sure why people are complaining about stuff that's not done, yet. I just said that we need an update to an incompatible firmware soon. HOW that happens is an entirely different question. It seems like we _might_ be able to support both fw versions for some limited time. If that is not possible for whatever reason, I will change the fw filenames, of course. (And people will complain about that, too. Because the rule for broadcom firmware is: Always complain about whatever you do. ;) ) The _just_ wanted to tell people about a serious change _before_ it happens. I'm not sure why this results in all kinds of complaints. Most probably, because the people don't want that to happen. ;-) People don't want N-PHY support? Well, as it sometimes is said the better is an enemy of the good. If they feel comfortable without the N-PHY, why would they want it? Still, if you can add the support for it as a feature that doesn't affect the people's working configurations, no one will complain. Impossible, sorry. We are going to add support for new firmware, which will be needed for N-PHY, or we don't. And I think it's clear which way we are going. What's the problem with all of this? Other drivers change firmware to incompatible versions on a regular basis. Look at ipw2200. There was a time when they changed the firmware basically on every kernel release. That wasn't a problem. Why would it be a problem here? How the technical implementation of all that stuff works in the end is not up to this discussion. Maybe we can support both firmware in one driver for some limited time. Maybe we rename the firmware files once again. I think it's likely to end up with a driver supporting 2 fw versions for a few release cycles. But I simply can not tell you, yet. I just wanted to tell people that a firmware change is going to happen soon. Just informational stuff. Nothing people need to complain, suggest or argue about. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Monday 07 January 2008 01:12:25 Rafał Miłecki wrote: 2008/1/7, Michael Buesch [EMAIL PROTECTED]: People don't want N-PHY support? Well, if your definition of people is similar to my one, they definitely want it! :-) I think we are just a little afraid of _possible_ problem with a few kernels installed at one time. Sometimes I need to run basic kernel of my distro and use b43 with is included in it. On the other hand I want to test the newest kernel with improved b43 :) Don't worry about that. This will be possible, of course. Everybody on earth runs a similiar configuration. Even me. ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add N-PHY related initvals firmware filenames.
This adds the initval filenames for the N-PHY firmware. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- Stuff for 2.6.25 Index: wireless-2.6/drivers/net/wireless/b43/main.c === --- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-06 00:12:08.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-06 00:12:08.0 +0100 @@ -1671,12 +1671,18 @@ static int b43_request_firmware(struct b filename = b0g0initvals5; else if (rev = 13) filename = lp0initvals13; else goto err_no_initvals; break; + case B43_PHYTYPE_N: + if ((rev = 11) (rev = 12)) + filename = n0initvals11; + else + goto err_no_initvals; + break; default: goto err_no_initvals; } err = do_request_fw(dev, filename, fw-initvals); if (err) goto err_load; @@ -1699,12 +1705,18 @@ static int b43_request_firmware(struct b filename = b0g0bsinitvals5; else if (rev = 11) filename = NULL; else goto err_no_initvals; break; + case B43_PHYTYPE_N: + if ((rev = 11) (rev = 12)) + filename = n0bsinitvals11; + else + goto err_no_initvals; + break; default: goto err_no_initvals; } err = do_request_fw(dev, filename, fw-initvals_band); if (err) goto err_load; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Injection?
On Tuesday 08 January 2008 16:31:53 David Ellingsworth wrote: mac80211 supposedly has support for packet injection. Like you however, I have have not been able to get packet injection to work with the b43/b43legacy drivers and the developers have expressed that they are not interested in supporting packet injection. mac80211 has support for packet injection and people say it works. I didn't try it myself, yet. But I don't see a reason for it to work with one driver but not with b43. I am now thinking that it might be possible to use b43_pio_txpacket and possibly dma_tx_fragment Cheers, Dan. If you do however get packet injection working for the b43 driver, I would be interested in evaluating your patch and possibly porting it to the b43legacy driver. I think there's no patch needed. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Injection?
On Tuesday 08 January 2008 21:23:18 Daniel wrote: Hello, Johannes Berg wrote: mac80211 has support for packet injection and people say it works. This is a very good point, mac80211 (if patched) can handle packet injection. It should work without any patches. The patch is in the aircrack-ng SVN(maybe their tarballs just I only checked the SVN). http://trac.aircrack-ng.org/svn/trunk/patches/ieee80211_inject.patch This is not a patch against mac80211. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add N-PHY register definitions
This patch adds all register definitions for the N-PHY. This adds two new files: nphy.h and nphy.c No functional changes to existing code. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- Stuff for 2.6.25 Index: wireless-2.6/drivers/net/wireless/b43/nphy.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ wireless-2.6/drivers/net/wireless/b43/nphy.h2008-01-09 16:02:31.0 +0100 @@ -0,0 +1,706 @@ +#ifndef B43_NPHY_H_ +#define B43_NPHY_H_ + +#include phy.h + + +/* N-PHY registers. */ + +#define B43_NPHY_BBCFG B43_PHY_N(0x001) /* BB config */ +#define B43_NPHY_BBCFG_RSTCCA 0x4000 /* Reset CCA */ +#define B43_NPHY_BBCFG_RSTRX 0x8000 /* Reset RX */ +#define B43_NPHY_CHANNEL B43_PHY_N(0x005) /* Channel */ +#define B43_NPHY_TXERR B43_PHY_N(0x007) /* TX error */ +#define B43_NPHY_BANDCTL B43_PHY_N(0x009) /* Band control */ +#define B43_NPHY_4WI_ADDR B43_PHY_N(0x00B) /* Four-wire bus address */ +#define B43_NPHY_4WI_DATAHIB43_PHY_N(0x00C) /* Four-wire bus data high */ +#define B43_NPHY_4WI_DATALOB43_PHY_N(0x00D) /* Four-wire bus data low */ +#define B43_NPHY_BIST_STAT0B43_PHY_N(0x00E) /* Built-in self test status 0 */ +#define B43_NPHY_BIST_STAT1B43_PHY_N(0x00F) /* Built-in self test status 1 */ + +#define B43_NPHY_C1_DESPWR B43_PHY_N(0x018) /* Core 1 desired power */ +#define B43_NPHY_C1_CCK_DESPWR B43_PHY_N(0x019) /* Core 1 CCK desired power */ +#define B43_NPHY_C1_BCLIPBKOFF B43_PHY_N(0x01A) /* Core 1 barely clip backoff */ +#define B43_NPHY_C1_CCK_BCLIPBKOFF B43_PHY_N(0x01B) /* Core 1 CCK barely clip backoff */ +#define B43_NPHY_C1_CGAINI B43_PHY_N(0x01C) /* Core 1 compute gain info */ +#define B43_NPHY_C1_CGAINI_GAINBKOFF 0x001F /* Gain backoff */ +#define B43_NPHY_C1_CGAINI_CLIPGBKOFF 0x03E0 /* Clip gain backoff */ +#define B43_NPHY_C1_CGAINI_GAINSTEP 0x1C00 /* Gain step */ +#define B43_NPHY_C1_CGAINI_CL2DETECT 0x2000 /* Clip 2 detect mask */ +#define B43_NPHY_C1_CCK_CGAINI B43_PHY_N(0x01D) /* Core 1 CCK compute gain info */ +#define B43_NPHY_C1_CCK_CGAINI_GAINBKOFF 0x001F /* Gain backoff */ +#define B43_NPHY_C1_CCK_CGAINI_CLIPGBKOFF 0x01E0 /* CCK barely clip gain backoff */ +#define B43_NPHY_C1_MINMAX_GAINB43_PHY_N(0x01E) /* Core 1 min/max gain */ +#define B43_NPHY_C1_MINGAIN 0x00FF /* Minimum gain */ +#define B43_NPHY_C1_MINGAIN_SHIFT 0 +#define B43_NPHY_C1_MAXGAIN 0xFF00 /* Maximum gain */ +#define B43_NPHY_C1_MAXGAIN_SHIFT 8 +#define B43_NPHY_C1_CCK_MINMAX_GAINB43_PHY_N(0x01F) /* Core 1 CCK min/max gain */ +#define B43_NPHY_C1_CCK_MINGAIN 0x00FF /* Minimum gain */ +#define B43_NPHY_C1_CCK_MINGAIN_SHIFT 0 +#define B43_NPHY_C1_CCK_MAXGAIN 0xFF00 /* Maximum gain */ +#define B43_NPHY_C1_CCK_MAXGAIN_SHIFT 8 +#define B43_NPHY_C1_INITGAIN B43_PHY_N(0x020) /* Core 1 initial gain code */ +#define B43_NPHY_C1_INITGAIN_EXTLNA 0x0001 /* External LNA index */ +#define B43_NPHY_C1_INITGAIN_LNA 0x0006 /* LNA index */ +#define B43_NPHY_C1_INITGAIN_LNAIDX_SHIFT 1 +#define B43_NPHY_C1_INITGAIN_HPVGA1 0x0078 /* HPVGA1 index */ +#define B43_NPHY_C1_INITGAIN_HPVGA1_SHIFT 3 +#define B43_NPHY_C1_INITGAIN_HPVGA2 0x0F80 /* HPVGA2 index */ +#define B43_NPHY_C1_INITGAIN_HPVGA2_SHIFT 7 +#define B43_NPHY_C1_INITGAIN_TRRX 0x1000 /* TR RX index */ +#define B43_NPHY_C1_INITGAIN_TRTX 0x2000 /* TR TX index */ +#define B43_NPHY_C1_CLIP1_HIGAIN B43_PHY_N(0x021) /* Core 1 clip1 high gain code */ +#define B43_NPHY_C1_CLIP1_MEDGAIN B43_PHY_N(0x022) /* Core 1 clip1 medium gain code */ +#define B43_NPHY_C1_CLIP1_LOGAIN B43_PHY_N(0x023) /* Core 1 clip1 low gain code */ +#define B43_NPHY_C1_CLIP2_GAIN B43_PHY_N(0x024) /* Core 1 clip2 gain code */ +#define B43_NPHY_C1_FILTERGAIN B43_PHY_N(0x025) /* Core 1 filter gain */ +#define B43_NPHY_C1_LPF_QHPF_BWB43_PHY_N(0x026) /* Core 1 LPF Q HP F bandwidth */ +#define B43_NPHY_C1_CLIPWBTHRESB43_PHY_N(0x027) /* Core 1 clip wideband threshold */ +#define B43_NPHY_C1_CLIPWBTHRES_CLIP2 0x003F /* Clip 2 */ +#define B43_NPHY_C1_CLIPWBTHRES_CLIP2_SHIFT 0 +#define B43_NPHY_C1_CLIPWBTHRES_CLIP1 0x0FC0 /* Clip 1 */ +#define B43_NPHY_C1_CLIPWBTHRES_CLIP1_SHIFT 6 +#define B43_NPHY_C1_W1THRESB43_PHY_N(0x028) /* Core 1
[PATCH RFT] b43legacy: Remove the PHY spinlock
This fixes a sparse warning about weird locking.
The spinlock is not needed, so simply remove it.
This also adds some sanity checks to the PHY and radio locking
to protect against recursive locking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is only compiletime tested.
Index: wireless-2.6/drivers/net/wireless/b43legacy/b43legacy.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43legacy/b43legacy.h
2007-12-20 18:53:57.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43legacy/b43legacy.h 2008-01-09
19:56:43.0 +0100
@@ -412,13 +412,12 @@ struct b43legacy_phy {
/* Radio versioning */
u16 radio_manuf;/* Radio manufacturer */
u16 radio_ver; /* Radio version */
u8 calibrated:1;
u8 radio_rev; /* Radio revision */
- bool locked;/* Only used in b43legacy_phy_{un}lock() */
bool dyn_tssi_tbl; /* tssi2dbm is kmalloc()ed. */
/* ACI (adjacent channel interference) flags. */
bool aci_enable;
bool aci_wlan_automatic;
bool aci_hw_rssi;
@@ -455,17 +454,12 @@ struct b43legacy_phy {
s16 max_lb_gain;/* Maximum Loopback gain in hdB */
s16 trsw_rx_gain; /* TRSW RX gain in hdB */
s16 lna_lod_gain; /* LNA lod */
s16 lna_gain; /* LNA */
s16 pga_gain; /* PGA */
- /* PHY lock for core.rev 3
-* This lock is only used by b43legacy_phy_{un}lock()
-*/
- spinlock_t lock;
-
/* Desired TX power level (in dBm). This is set by the user and
* adjusted in b43legacy_phy_xmitpower(). */
u8 power_level;
/* Values from b43legacy_calc_loopback_gain() */
u16 loopback_gain[2];
@@ -483,15 +477,12 @@ struct b43legacy_phy {
};
/* A PHY */
struct {
u16 txpwr_offset;
};
-#ifdef CONFIG_B43LEGACY_DEBUG
- bool manual_txpower_control; /* Manual TX-power control enabled? */
-#endif
/* Current Interference Mitigation mode */
int interfmode;
/* Stack of saved values from the Interference Mitigation code.
* Each value in the stack is layed out as follows:
* bit 0-11: offset
* bit 12-15: register ID
@@ -513,12 +504,19 @@ struct b43legacy_phy {
u16 lofcal;
u16 initval;
/* PHY TX errors counter. */
atomic_t txerr_cnt;
+
+#if B43legacy_DEBUG
+ /* Manual TX-power control enabled? */
+ bool manual_txpower_control;
+ /* PHY registers locked by b43legacy_phy_lock()? */
+ bool phy_locked;
+#endif /* B43legacy_DEBUG */
};
/* Data structures for DMA transmission, per 80211 core. */
struct b43legacy_dma {
struct b43legacy_dmaring *tx_ring0;
struct b43legacy_dmaring *tx_ring1;
Index: wireless-2.6/drivers/net/wireless/b43legacy/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43legacy/main.c 2008-01-09
16:59:33.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43legacy/main.c 2008-01-09
20:03:16.0 +0100
@@ -2844,14 +2844,12 @@ static void setup_struct_phy_for_init(st
struct b43legacy_lopair *lo;
int i;
memset(phy-minlowsig, 0xFF, sizeof(phy-minlowsig));
memset(phy-minlowsigpos, 0, sizeof(phy-minlowsigpos));
- /* Flags */
- phy-locked = 0;
/* Assume the radio is enabled. If it's not enabled, the state will
* immediately get fixed on the first periodic work run. */
dev-radio_hw_enable = 1;
phy-savedpctlreg = 0x;
phy-aci_enable = 0;
@@ -2878,13 +2876,12 @@ static void setup_struct_phy_for_init(st
for (i = 0; i ARRAY_SIZE(phy-nrssi_lt); i++)
phy-nrssi_lt[i] = i;
phy-lofcal = 0x;
phy-initval = 0x;
- spin_lock_init(phy-lock);
phy-interfmode = B43legacy_INTERFMODE_NONE;
phy-channel = 0xFF;
}
static void setup_struct_wldev_for_init(struct b43legacy_wldev *dev)
{
@@ -3010,13 +3007,12 @@ static void prepare_phy_data_for_init(st
phy-antenna_diversity = 0x;
memset(phy-minlowsig, 0xFF, sizeof(phy-minlowsig));
memset(phy-minlowsigpos, 0, sizeof(phy-minlowsigpos));
/* Flags */
phy-calibrated = 0;
- phy-locked = 0;
if (phy-_lo_pairs)
memset(phy-_lo_pairs, 0,
sizeof(struct b43legacy_lopair) * B43legacy_LO_COUNT);
memset(phy-loopback_gain, 0, sizeof(phy-loopback_gain));
}
Index: wireless-2.6/drivers/net/wireless/b43legacy/phy.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43legacy/phy.c 2008-01-09
16:59:33.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43legacy
[PATCH RFT] b43: Add support for new firmware
B43_TXH_PHY1_CRATE_7_80x0600 /* 7/8 */
+#define B43_TXH_PHY1_MODUL 0x3800 /* Modulation scheme */
+#define B43_TXH_PHY1_MODUL_BPSK 0x /* BPSK */
+#define B43_TXH_PHY1_MODUL_QPSK 0x0800 /* QPSK */
+#define B43_TXH_PHY1_MODUL_QAM16 0x1000 /* QAM16 */
+#define B43_TXH_PHY1_MODUL_QAM64 0x1800 /* QAM64 */
+#define B43_TXH_PHY1_MODUL_QAM256 0x2000 /* QAM256 */
+
+
+/* r351 firmware compatibility stuff. */
+static inline
+bool b43_is_old_txhdr_format(struct b43_wldev *dev)
+{
+ return (dev-fw.rev = 351);
+}
+
+static inline
+size_t b43_txhdr_size(struct b43_wldev *dev)
+{
+ if (b43_is_old_txhdr_format(dev))
+ return 100 + sizeof(struct b43_plcp_hdr6);
+ return 104 + sizeof(struct b43_plcp_hdr6);
+}
+
void b43_generate_txhdr(struct b43_wldev *dev,
u8 * txhdr,
const unsigned char *fragment_data,
unsigned int fragment_len,
const struct ieee80211_tx_control *txctl, u16 cookie);
Index: wireless-2.6/Documentation/feature-removal-schedule.txt
===
--- wireless-2.6.orig/Documentation/feature-removal-schedule.txt
2007-12-20 18:53:57.0 +0100
+++ wireless-2.6/Documentation/feature-removal-schedule.txt 2008-01-10
20:29:48.0 +0100
@@ -355,6 +355,15 @@ What: rc80211-simple rate control algori
When: 2.6.26
Files: net/mac80211/rc80211-simple.c
Why: This algorithm was provided for reference but always exhibited bad
responsiveness and performance and has some serious flaws. It has been
replaced by rc80211-pid.
Who: Stefano Brivio [EMAIL PROTECTED]
+
+---
+
+What: b43 support for firmware revision 410
+When: July 2008
+Why: The support code for the old firmware hurts code
readability/maintainability
+ and slightly hurts runtime performance. Bugfixes for the old firmware
+ are not provided by Broadcom anymore.
+Who: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/phy.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/phy.h2008-01-09
18:48:42.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/phy.h 2008-01-10 19:57:45.0
+0100
@@ -177,12 +177,14 @@ void b43_gtab_write(struct b43_wldev *de
enum {
B43_ANTENNA0, /* Antenna 0 */
B43_ANTENNA1, /* Antenna 0 */
B43_ANTENNA_AUTO1, /* Automatic, starting with antenna 1 */
B43_ANTENNA_AUTO0, /* Automatic, starting with antenna 0 */
+ B43_ANTENNA2,
+ B43_ANTENNA3 = 8,
B43_ANTENNA_AUTO = B43_ANTENNA_AUTO0,
B43_ANTENNA_DEFAULT = B43_ANTENNA_AUTO,
};
enum {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: Add support for new firmware
On Friday 11 January 2008 17:40:04 Larry Finger wrote:
Michael Buesch wrote:
This patch adds support for new firmware.
Please test this on old and new firmware.
I have tested this patch with old firmware. It seems to work; however my
testing is not complete as
my computer has started hanging with the Caps Lock light flashing. The
crash is not caused by this
patch as it happened with 2.6.24-rc5, which has run for many days. I do have
a suggestion for
changing the patch (see below).
+static inline
+size_t b43_txhdr_size(struct b43_wldev *dev)
+{
+ if (b43_is_old_txhdr_format(dev))
+ return 100 + sizeof(struct b43_plcp_hdr6);
+ return 104 + sizeof(struct b43_plcp_hdr6);
+}
Why not eliminate most of the magic numbers in this part with
size_t b43_txhdr_size(struct b43_wldev *dev)
{
if (b43_is_old_txhdr_format(dev))
return sizeof(struct b43_txhdr) - 4;
return sizeof(struct b43_txhdr);
}
Because this is IMO as magic as the above.
The struct b43_txhdr is _not_ meant to be used as an object anymore,
as it now contains this union magic stuff. So we must only use it
as a pointer type. The sizeof, however, uses it as an object.
I'm perfectly fine with the hardcoded constants. And they really
are constants, as they are defined by the hard(firm)ware.
I think this all leads to the same issue as Should we use
#defines for the PCI IDs in PCI ID tables?.
However, this code will go away in summer anyway. So it doesn't
really matter. It really is just a hack.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix radio ID register reading
This fixes reading of the high 16 bits of the radio ID
on new devices. 2055 radios want lo16 to be read first.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-13
13:26:18.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-13
13:59:27.0 +0100
@@ -3136,16 +3136,15 @@ static int b43_phy_versioning(struct b43
else if (dev-dev-bus-chip_rev == 1)
tmp = 0x4205017F;
else
tmp = 0x5205017F;
} else {
b43_write16(dev, B43_MMIO_RADIO_CONTROL, B43_RADIOCTL_ID);
- tmp = b43_read16(dev, B43_MMIO_RADIO_DATA_HIGH);
- tmp = 16;
+ tmp = b43_read16(dev, B43_MMIO_RADIO_DATA_LOW);
b43_write16(dev, B43_MMIO_RADIO_CONTROL, B43_RADIOCTL_ID);
- tmp |= b43_read16(dev, B43_MMIO_RADIO_DATA_LOW);
+ tmp |= (u32)b43_read16(dev, B43_MMIO_RADIO_DATA_HIGH) 16;
}
radio_manuf = (tmp 0x0FFF);
radio_ver = (tmp 0x0000) 12;
radio_rev = (tmp 0xF000) 28;
if (radio_manuf != 0x17F /* Broadcom */)
unsupported = 1;
@@ -3164,13 +3163,13 @@ static int b43_phy_versioning(struct b43
break;
case B43_PHYTYPE_G:
if (radio_ver != 0x2050)
unsupported = 1;
break;
case B43_PHYTYPE_N:
- if (radio_ver != 5)
+ if (radio_ver != 0x2055)
unsupported = 1;
break;
default:
B43_WARN_ON(1);
}
if (unsupported) {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add Broadcom 2055 radio register definitions
Add the register definitions for the Broadcom 2055 N-radio. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- For 2.6.25 Index: wireless-2.6/drivers/net/wireless/b43/nphy.h === --- wireless-2.6.orig/drivers/net/wireless/b43/nphy.h 2008-01-09 17:06:35.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/nphy.h2008-01-13 16:39:10.0 +0100 @@ -696,11 +696,221 @@ #define B43_NPHY_FINERX2_CGC_DECGC0x0008 /* Decode gated clocks */ #define B43_NPHY_TXPCTL_INIT B43_PHY_N(0x222) /* TX power controll init */ #define B43_NPHY_TXPCTL_INIT_PIDXI1 0x00FF /* Power index init 1 */ #define B43_NPHY_TXPCTL_INIT_PIDXI1_SHIFT 0 + +/* Broadcom 2055 radio registers */ + +#define B2055_GEN_SPARE0x00 /* GEN spare */ +#define B2055_SP_PINPD 0x02 /* SP PIN PD */ +#define B2055_C1_SP_RSSI 0x03 /* SP RSSI Core 1 */ +#define B2055_C1_SP_PDMISC 0x04 /* SP PD MISC Core 1 */ +#define B2055_C2_SP_RSSI 0x05 /* SP RSSI Core 2 */ +#define B2055_C2_SP_PDMISC 0x06 /* SP PD MISC Core 2 */ +#define B2055_C1_SP_RXGC1 0x07 /* SP RX GC1 Core 1 */ +#define B2055_C1_SP_RXGC2 0x08 /* SP RX GC2 Core 1 */ +#define B2055_C2_SP_RXGC1 0x09 /* SP RX GC1 Core 2 */ +#define B2055_C2_SP_RXGC2 0x0A /* SP RX GC2 Core 2 */ +#define B2055_C1_SP_LPFBWSEL 0x0B /* SP LPF BW select Core 1 */ +#define B2055_C2_SP_LPFBWSEL 0x0C /* SP LPF BW select Core 2 */ +#define B2055_C1_SP_TXGC1 0x0D /* SP TX GC1 Core 1 */ +#define B2055_C1_SP_TXGC2 0x0E /* SP TX GC2 Core 1 */ +#define B2055_C2_SP_TXGC1 0x0F /* SP TX GC1 Core 2 */ +#define B2055_C2_SP_TXGC2 0x10 /* SP TX GC2 Core 2 */ +#define B2055_MASTER1 0x11 /* Master control 1 */ +#define B2055_MASTER2 0x12 /* Master control 2 */ +#define B2055_PD_LGEN 0x13 /* PD LGEN */ +#define B2055_PD_PLLTS 0x14 /* PD PLL TS */ +#define B2055_C1_PD_LGBUF 0x15 /* PD Core 1 LGBUF */ +#define B2055_C1_PD_TX 0x16 /* PD Core 1 TX */ +#define B2055_C1_PD_RXTX 0x17 /* PD Core 1 RXTX */ +#define B2055_C1_PD_RSSIMISC 0x18 /* PD Core 1 RSSI MISC */ +#define B2055_C2_PD_LGBUF 0x19 /* PD Core 2 LGBUF */ +#define B2055_C2_PD_TX 0x1A /* PD Core 2 TX */ +#define B2055_C2_PD_RXTX 0x1B /* PD Core 2 RXTX */ +#define B2055_C2_PD_RSSIMISC 0x1C /* PD Core 2 RSSI MISC */ +#define B2055_PWRDET_LGEN 0x1D /* PWRDET LGEN */ +#define B2055_C1_PWRDET_LGBUF 0x1E /* PWRDET LGBUF Core 1 */ +#define B2055_C1_PWRDET_RXTX 0x1F /* PWRDET RXTX Core 1 */ +#define B2055_C2_PWRDET_LGBUF 0x20 /* PWRDET LGBUF Core 2 */ +#define B2055_C2_PWRDET_RXTX 0x21 /* PWRDET RXTX Core 2 */ +#define B2055_RRCCAL_CS0x22 /* RRCCAL Control spare */ +#define B2055_RRCCAL_NOPTSEL 0x23 /* RRCCAL N OPT SEL */ +#define B2055_CAL_MISC 0x24 /* CAL MISC */ +#define B2055_CAL_COUT 0x25 /* CAL Counter out */ +#define B2055_CAL_COUT20x26 /* CAL Counter out 2 */ +#define B2055_CAL_CVARCTL 0x27 /* CAL CVAR Control */ +#define B2055_CAL_RVARCTL 0x28 /* CAL RVAR Control */ +#define B2055_CAL_LPOCTL 0x29 /* CAL LPO Control */ +#define B2055_CAL_TS 0x2A /* CAL TS */ +#define B2055_CAL_RCCALRTS 0x2B /* CAL RCCAL READ TS */ +#define B2055_CAL_RCALRTS 0x2C /* CAL RCAL READ TS */ +#define B2055_PADDRV 0x2D /* PAD driver */ +#define B2055_XOCTL1 0x2E /* XO Control 1 */ +#define B2055_XOCTL2 0x2F /* XO Control 2 */ +#define B2055_XOREGUL 0x30 /* XO Regulator */ +#define B2055_XOMISC 0x31 /* XO misc */ +#define B2055_PLL_LFC1 0x32 /* PLL LF C1 */ +#define B2055_PLL_CALVTH 0x33 /* PLL CAL VTH */ +#define B2055_PLL_LFC2 0x34 /* PLL LF C2 */ +#define B2055_PLL_REF 0x35 /* PLL reference */ +#define B2055_PLL_LFR1 0x36 /* PLL LF R1 */ +#define B2055_PLL_PFDCP0x37 /* PLL PFD CP */ +#define B2055_PLL_IDAC_CPOPAMP 0x38 /* PLL IDAC CPOPAMP */ +#define B2055_PLL_CPREG0x39 /* PLL CP Regulator */ +#define B2055_PLL_RCAL 0x3A /* PLL RCAL */ +#define B2055_RF_PLLMOD0 0x3B /* RF PLL MOD0 */ +#define B2055_RF_PLLMOD1 0x3C /* RF PLL MOD1 */ +#define B2055_RF_MMDIDAC1 0x3D /* RF MMD IDAC 1 */ +#define B2055_RF_MMDIDAC0 0x3E /* RF MMD IDAC 0 */ +#define B2055_RF_MMDSP 0x3F /* RF MMD
Re: b43_suspend problem
On Sunday 13 January 2008 18:08:57 Alan Stern wrote: On Sun, 13 Jan 2008, Rafael J. Wysocki wrote: On Sunday, 13 of January 2008, Michael Buesch wrote: On Sunday 13 January 2008 00:08:29 Rafael J. Wysocki wrote: There is a problem with b43_suspend() that it (indirectly) causes b43_leds_exit() to be called, which attempts to unregister the leds device objects, which is forbidden (ie. you can't unregister and/or register devices during a suspend or resume). Why? Well, the unregistering itself is not really harmful, provided that the device is not registered back during the subsequent resume. The PM core uses a list of active devices that are added to the list in device_add(). The ordering of this list is important, because it is expected to reflect the order in which the devices are to be suspended. This list is manipulated during suspend/resume and devices are moved from it and back to it, so unregistering devices during a suspend and registering them during the subsequent resume generally changes its ordering and may lead to problems during the next suspend/resume cycle. This is also undesirable if we're going to stop using the freezer for suspend/resume at one point in the future. I'm sure Alan can add some more details. Indeed. A system suspend is a delicate operation, and the PM core needs to access all the devices in the system. To have devices being registered and unregistered at the same time would cause a lot of confusion. In self defense, the PM core starts out by acquiring all the device semaphores before calling the suspend routines. This means that if a suspend routine tries to unregister anything, it will deadlock at the point where the driver core tries to acquire the device semaphore prior to invoking the driver's remove method. Besides, if you're going to register the device right back again during the subsequent resume, then why go to the trouble of unregistering it during suspend? Why not just leave it registered the whole time and avoid all the complication (and excess meaningless uevents)? Well, because not doing it complicates code :) Currently suspend/resume calls the same code as init/exit. The b43 init/exit code is really complicated, compared to other drivers, due to dozens of hardware versions. So I just avoided having yet other codepaths for suspend/resume. But I will add a flag to the device structure that's used to avoid unregistering stuff. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: fix use-after-free rfkill bug
On Sunday 13 January 2008 18:30:14 Stefano Brivio wrote:
Fix rfkill code which caused a use-after-free bug.
Signed-off-by: Stefano Brivio [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c
+++ wireless-2.6/drivers/net/wireless/b43/rfkill.c
@@ -138,8 +138,11 @@ void b43_rfkill_init(struct b43_wldev *d
rfk-rfkill-user_claim_unsupported = 1;
rfk-poll_dev = input_allocate_polled_device();
- if (!rfk-poll_dev)
- goto err_free_rfk;
+ if (!rfk-poll_dev) {
+ rfkill_free(rfk-rfkill);
+ goto err_freed_rfk;
+ }
+
rfk-poll_dev-private = dev;
rfk-poll_dev-poll = b43_rfkill_poll;
rfk-poll_dev-poll_interval = 1000; /* msecs */
@@ -175,8 +178,7 @@ err_unreg_rfk:
err_free_polldev:
input_free_polled_device(rfk-poll_dev);
rfk-poll_dev = NULL;
-err_free_rfk:
- rfkill_free(rfk-rfkill);
+err_freed_rfk:
rfk-rfkill = NULL;
out_error:
rfk-registered = 0;
@@ -195,6 +197,5 @@ void b43_rfkill_exit(struct b43_wldev *d
rfkill_unregister(rfk-rfkill);
input_free_polled_device(rfk-poll_dev);
rfk-poll_dev = NULL;
- rfkill_free(rfk-rfkill);
rfk-rfkill = NULL;
}
Acked-by: Michael Buesch [EMAIL PROTECTED]
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Add boardflags_hi field to the sprom data structure
Add boardflags-high.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/ssb/pci.c
===
--- wireless-2.6.orig/drivers/ssb/pci.c 2008-01-09 16:59:33.0 +0100
+++ wireless-2.6/drivers/ssb/pci.c 2008-01-13 21:01:14.0 +0100
@@ -374,12 +374,14 @@ static void sprom_extract_r123(struct ss
SSB_SPROM1_MAXPWR_A_SHIFT);
SPEX(maxpwr_bg, SSB_SPROM1_MAXPWR, SSB_SPROM1_MAXPWR_BG, 0);
SPEX(itssi_a, SSB_SPROM1_ITSSI, SSB_SPROM1_ITSSI_A,
SSB_SPROM1_ITSSI_A_SHIFT);
SPEX(itssi_bg, SSB_SPROM1_ITSSI, SSB_SPROM1_ITSSI_BG, 0);
SPEX(boardflags_lo, SSB_SPROM1_BFLLO, 0x, 0);
+ if (out-revision = 2)
+ SPEX(boardflags_hi, SSB_SPROM2_BFLHI, 0x, 0);
/* Extract the antenna gain values. */
gain = r123_extract_antgain(out-revision, in,
SSB_SPROM1_AGAIN_BG,
SSB_SPROM1_AGAIN_BG_SHIFT);
out-antenna_gain.ghz24.a0 = gain;
@@ -415,12 +417,13 @@ static void sprom_extract_r4(struct ssb_
}
SPEX(et0phyaddr, SSB_SPROM4_ETHPHY, SSB_SPROM4_ETHPHY_ET0A, 0);
SPEX(et1phyaddr, SSB_SPROM4_ETHPHY, SSB_SPROM4_ETHPHY_ET1A,
SSB_SPROM4_ETHPHY_ET1A_SHIFT);
SPEX(country_code, SSB_SPROM4_CCODE, 0x, 0);
SPEX(boardflags_lo, SSB_SPROM4_BFLLO, 0x, 0);
+ SPEX(boardflags_hi, SSB_SPROM4_BFLHI, 0x, 0);
SPEX(ant_available_a, SSB_SPROM4_ANTAVAIL, SSB_SPROM4_ANTAVAIL_A,
SSB_SPROM4_ANTAVAIL_A_SHIFT);
SPEX(ant_available_bg, SSB_SPROM4_ANTAVAIL, SSB_SPROM4_ANTAVAIL_BG,
SSB_SPROM4_ANTAVAIL_BG_SHIFT);
SPEX(maxpwr_bg, SSB_SPROM4_MAXP_BG, SSB_SPROM4_MAXP_BG_MASK, 0);
SPEX(itssi_bg, SSB_SPROM4_MAXP_BG, SSB_SPROM4_ITSSI_BG,
Index: wireless-2.6/include/linux/ssb/ssb.h
===
--- wireless-2.6.orig/include/linux/ssb/ssb.h 2008-01-09 16:59:33.0
+0100
+++ wireless-2.6/include/linux/ssb/ssb.h2008-01-13 21:00:39.0
+0100
@@ -40,12 +40,13 @@ struct ssb_sprom {
u8 gpio3; /* GPIO pin 3 */
u16 maxpwr_a; /* A-PHY Amplifier Max Power (in dBm Q5.2) */
u16 maxpwr_bg; /* B/G-PHY Amplifier Max Power (in dBm Q5.2) */
u8 itssi_a; /* Idle TSSI Target for A-PHY */
u8 itssi_bg;/* Idle TSSI Target for B/G-PHY */
u16 boardflags_lo; /* Boardflags (low 16 bits) */
+ u16 boardflags_hi; /* Boardflags (high 16 bits) */
/* Antenna gain values for up to 4 antennas
* on each band. Values in dBm/4 (Q5.2). Negative gain means the
* loss in the connectors is bigger than the gain. */
struct {
struct {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: rfkill use after free
On Sunday 13 January 2008 22:20:52 Eric Paris wrote: inside b43_rfkill_exit() we call rfkill_unregister() which puts the last reference and frees the rfkill struct. Then just 3 lines later the code explicitly calls rfkill_free() on the struct we already freed. This showed up as slub corruption (what should have been 6b was showing up as 6a) since the rfkill_free had dec'ed the are that should have been the use counter. stop using the already freed rfkill struct. = BUG kmalloc-1024 (Not tainted): Poison overwritten - INFO: 0xf40b89e8-0xf40b89e8. First byte 0x6a instead of 0x6b INFO: Allocated in rfkill_allocate+0x1b/0x8b [rfkill] age=231032011 cpu=0 pid=2403 INFO: Freed in rfkill_release+0xd/0x19 [rfkill] age=366 cpu=0 pid=2403 INFO: Slab 0xc1b62840 used=6 fp=0xf40b8860 flags=0x400040c3 INFO: Object 0xf40b8860 @offset=2144 fp=0x Signed-off-by: Eric Paris [EMAIL PROTECTED] --- drivers/net/wireless/b43/rfkill.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c index 98cf70c..a19be53 100644 --- a/drivers/net/wireless/b43/rfkill.c +++ b/drivers/net/wireless/b43/rfkill.c @@ -195,6 +195,5 @@ void b43_rfkill_exit(struct b43_wldev *dev) rfkill_unregister(rfk-rfkill); input_free_polled_device(rfk-poll_dev); rfk-poll_dev = NULL; - rfkill_free(rfk-rfkill); rfk-rfkill = NULL; } NACK. Better patch available from Stefano. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add support for new firmware
On Tuesday 15 January 2008 20:15:38 Stefano Brivio wrote: On Tue, 15 Jan 2008 13:27:42 -0500 Pavel Roskin [EMAIL PROTECTED] wrote: I have finally found some time and hardware to test it, but the tarball is overwhelming at its 186M. And the worst thing, the server disconnected after 30M and appears to be down right now. P.S. It's up, ETA is 48 minutes. There were two files there. I hope either is fine. I'm trying to download WRT150NV11_v1.51.3_ETSI.tgz Cannot we petition Linksys to put wl_ap.o outside the tarball? Or maybe Broadcom could do it? Good luck. ;) The only long-term lasting solution I see is to put more effort on an open firmware. The instruction set has been figured out, we just lack people and time there. We already have a better file on an openwrt server that will be the officially supported one soon. I just have to create a new fwcutter tarball and link from linuxwireless.org to it. I already added support for the file to fwcutter git. See Stefano's comment below. Do you know that the Subversion repository of fwcutter has no files at all? I mean svn://svn.berlios.de/bcm43xx/trunk Yes, I will try --unsupported, with version 009. fwcutter development now happens here: http://bu3sch.de/gitweb?p=b43-tools.git;a=summary Yep, the berlios stuff is dropped completely, except the download section for the fwcutter tarballs. But that may also change in future. We will announce that on linuxwireless.org. Maybe we should add this along with git URLs on linuxwireless.org. Please do it, if you feel so. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add support for new firmware
On Tuesday 15 January 2008 23:21:40 Michael Buesch wrote: Yep, the berlios stuff is dropped completely, except the download section for the fwcutter tarballs. But that may also change in future. We will announce that on linuxwireless.org. Actually, I think I will change that _now_. I'll simply put the stuff on my server. berlios is just too annoying. I'll put the new URLs on the b43 linuxwireless.org page. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add lots of N-PHY lookup tables
This adds lots of N-PHY related lookup tables.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/tables_nphy.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/tables_nphy.c2008-01-15
00:23:51.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/tables_nphy.c 2008-01-16
02:07:59.0 +0100
@@ -1331,6 +1331,1146 @@ b43_nphy_get_chantabent(struct b43_wldev
if (e-channel == channel)
return e;
}
return NULL;
}
+
+
+const u8 b43_ntab_adjustpower0[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01,
+ 0x02, 0x02, 0x02, 0x02, 0x03, 0x03, 0x03, 0x03,
+ 0x04, 0x04, 0x04, 0x04, 0x05, 0x05, 0x05, 0x05,
+ 0x06, 0x06, 0x06, 0x06, 0x07, 0x07, 0x07, 0x07,
+ 0x08, 0x08, 0x08, 0x08, 0x09, 0x09, 0x09, 0x09,
+ 0x0A, 0x0A, 0x0A, 0x0A, 0x0B, 0x0B, 0x0B, 0x0B,
+ 0x0C, 0x0C, 0x0C, 0x0C, 0x0D, 0x0D, 0x0D, 0x0D,
+ 0x0E, 0x0E, 0x0E, 0x0E, 0x0F, 0x0F, 0x0F, 0x0F,
+ 0x10, 0x10, 0x10, 0x10, 0x11, 0x11, 0x11, 0x11,
+ 0x12, 0x12, 0x12, 0x12, 0x13, 0x13, 0x13, 0x13,
+ 0x14, 0x14, 0x14, 0x14, 0x15, 0x15, 0x15, 0x15,
+ 0x16, 0x16, 0x16, 0x16, 0x17, 0x17, 0x17, 0x17,
+ 0x18, 0x18, 0x18, 0x18, 0x19, 0x19, 0x19, 0x19,
+ 0x1A, 0x1A, 0x1A, 0x1A, 0x1B, 0x1B, 0x1B, 0x1B,
+ 0x1C, 0x1C, 0x1C, 0x1C, 0x1D, 0x1D, 0x1D, 0x1D,
+ 0x1E, 0x1E, 0x1E, 0x1E, 0x1F, 0x1F, 0x1F, 0x1F,
+};
+
+const u8 b43_ntab_adjustpower1[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01,
+ 0x02, 0x02, 0x02, 0x02, 0x03, 0x03, 0x03, 0x03,
+ 0x04, 0x04, 0x04, 0x04, 0x05, 0x05, 0x05, 0x05,
+ 0x06, 0x06, 0x06, 0x06, 0x07, 0x07, 0x07, 0x07,
+ 0x08, 0x08, 0x08, 0x08, 0x09, 0x09, 0x09, 0x09,
+ 0x0A, 0x0A, 0x0A, 0x0A, 0x0B, 0x0B, 0x0B, 0x0B,
+ 0x0C, 0x0C, 0x0C, 0x0C, 0x0D, 0x0D, 0x0D, 0x0D,
+ 0x0E, 0x0E, 0x0E, 0x0E, 0x0F, 0x0F, 0x0F, 0x0F,
+ 0x10, 0x10, 0x10, 0x10, 0x11, 0x11, 0x11, 0x11,
+ 0x12, 0x12, 0x12, 0x12, 0x13, 0x13, 0x13, 0x13,
+ 0x14, 0x14, 0x14, 0x14, 0x15, 0x15, 0x15, 0x15,
+ 0x16, 0x16, 0x16, 0x16, 0x17, 0x17, 0x17, 0x17,
+ 0x18, 0x18, 0x18, 0x18, 0x19, 0x19, 0x19, 0x19,
+ 0x1A, 0x1A, 0x1A, 0x1A, 0x1B, 0x1B, 0x1B, 0x1B,
+ 0x1C, 0x1C, 0x1C, 0x1C, 0x1D, 0x1D, 0x1D, 0x1D,
+ 0x1E, 0x1E, 0x1E, 0x1E, 0x1F, 0x1F, 0x1F, 0x1F,
+};
+
+const u16 b43_ntab_bdi[] = {
+ 0x0070, 0x0126, 0x012C, 0x0246, 0x048D, 0x04D2,
+};
+
+const u32 b43_ntab_channelest[] = {
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+ 0x10101010, 0x10101010, 0x10101010, 0x10101010,
+};
+
+const u8 b43_ntab_estimatepowerlt0[] = {
+ 0x50, 0x4F, 0x4E, 0x4D, 0x4C, 0x4B, 0x4A, 0x49,
+ 0x48, 0x47, 0x46, 0x45, 0x44, 0x43, 0x42, 0x41,
+ 0x40, 0x3F, 0x3E, 0x3D, 0x3C, 0x3B, 0x3A, 0x39,
+ 0x38, 0x37, 0x36, 0x35, 0x34, 0x33, 0x32, 0x31,
+ 0x30, 0x2F, 0x2E, 0x2D, 0x2C, 0x2B, 0x2A, 0x29,
+ 0x28, 0x27, 0x26, 0x25, 0x24, 0x23, 0x22, 0x21,
+ 0x20, 0x1F, 0x1E, 0x1D, 0x1C, 0x1B, 0x1A, 0x19,
+ 0x18, 0x17, 0x16, 0x15, 0x14, 0x13, 0x12, 0x11,
+};
+
+const u8 b43_ntab_estimatepowerlt1[] = {
+ 0x50, 0x4F, 0x4E, 0x4D, 0x4C, 0x4B, 0x4A, 0x49,
+ 0x48, 0x47, 0x46, 0x45, 0x44, 0x43, 0x42, 0x41,
+ 0x40, 0x3F, 0x3E, 0x3D, 0x3C, 0x3B, 0x3A, 0x39,
+ 0x38, 0x37, 0x36, 0x35, 0x34, 0x33, 0x32, 0x31,
+ 0x30, 0x2F, 0x2E, 0x2D, 0x2C, 0x2B, 0x2A, 0x29,
+ 0x28, 0x27, 0x26, 0x25, 0x24, 0x23, 0x22, 0x21,
+ 0x20, 0x1F, 0x1E, 0x1D, 0x1C, 0x1B, 0x1A, 0x19,
+ 0x18, 0x17, 0x16, 0x15, 0x14, 0x13, 0x12, 0x11,
+};
+
+const u8 b43_ntab_framelookup
[PATCH 2.6.24] b43: Reject new firmware early
We must reject new incompatible firmware early to avoid
running into strange transmission failures.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this must _only_ be applied to 2.6.24.
2.6.25 does have actual support for the new firmware.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-16
11:33:55.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-16
11:44:06.0 +0100
@@ -1800,6 +1800,18 @@ static int b43_upload_microcode(struct b
err = -EOPNOTSUPP;
goto out;
}
+ if (fwrev 351) {
+ b43err(dev-wl, YOUR FIRMWARE IS TOO NEW. Please downgrade
your
+ firmware.\n);
+ b43err(dev-wl, Use this firmware tarball:
+
http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2\n;);
+ b43err(dev-wl, Use this b43-fwcutter tarball:
+
http://bu3sch.de/b43/fwcutter/b43-fwcutter-009.tar.bz2\n;);
+ b43err(dev-wl, Read, understand and _do_ what this message
says, please.\n);
+ b43_write32(dev, B43_MMIO_MACCTL, 0);
+ err = -EOPNOTSUPP;
+ goto out;
+ }
b43dbg(dev-wl, Loading firmware version %u.%u
(20%.2i-%.2i-%.2i %.2i:%.2i:%.2i)\n,
fwrev, fwpatch,
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: issues with bcm4306
On Wednesday 16 January 2008 17:58:26 Gavin McCullagh wrote: Hi, On Wed, 16 Jan 2008, Larry Finger wrote: Please check that modules rfkill and rfkill-input are configured and loaded on your system. In your dmesg output, you are missing lines that look like Registered led device: b43-phy0:tx Registered led device: b43-phy0:rx Registered led device: b43-phy0:radio I'll check this properly when I'm at the access point in question, though when I plug in the card here (different location), rfkill was already loaded (I have b43 in /etc/modules), rfkill-input loaded automatically and I got straight on. dmesg | grep led produces no output whatsoever. Can you please post the SPROM data? $ cat $(find /sys -name ssb_sprom) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: issues with bcm4306
On Wednesday 16 January 2008 23:00:09 Gavin McCullagh wrote: Hi, On Wed, 16 Jan 2008, Michael Buesch wrote: dmesg | grep led produces no output whatsoever. Can you please post the SPROM data? $ cat $(find /sys -name ssb_sprom) [EMAIL PROTECTED]:~# cat $(find /sys -name ssb_sprom) 01401170991720430080020002100018811011009250B8FD4730531594FA85FE4C003E00490A01FF10FF023A So there's no special LEDs information in your SPROM. That means you must get the messages Larry quoted. I'm pretty sure that you didn't enable LEDs support in your kernel. Make sure CONFIG_LEDS_CLASS and CONFIG_MAC80211_LEDS are enabled. While you are at it also make sure CONFIG_RFKILL, CONFIG_RFKILL_INPUT and CONFIG_INPUT_POLLDEV are enabled. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add more N-PHY init code
This also adds lots of TODOs. Oh well. Lots of work. :)
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/nphy.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/nphy.c 2008-01-17
00:27:48.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/nphy.c2008-01-18
00:56:34.0 +0100
@@ -23,12 +23,14 @@
*/
#include b43.h
#include nphy.h
#include tables_nphy.h
+#include linux/delay.h
+
void b43_nphy_set_rxantenna(struct b43_wldev *dev, int antenna)
{//TODO
}
void b43_nphy_xmitpower(struct b43_wldev *dev)
@@ -185,12 +187,300 @@ void b43_nphy_radio_turn_on(struct b43_w
void b43_nphy_radio_turn_off(struct b43_wldev *dev)
{
b43_phy_mask(dev, B43_NPHY_RFCTL_CMD,
~B43_NPHY_RFCTL_CMD_EN);
}
+#define ntab_upload(dev, offset, data) do { \
+ unsigned int i; \
+ for (i = 0; i (offset##_SIZE); i++) \
+ b43_ntab_write(dev, (offset) + i, (data)[i]); \
+ } while (0)
+
+/* Upload the N-PHY tables. */
+static void b43_nphy_tables_init(struct b43_wldev *dev)
+{
+ /* Static tables */
+ ntab_upload(dev, B43_NTAB_FRAMESTRUCT, b43_ntab_framestruct);
+ ntab_upload(dev, B43_NTAB_FRAMELT, b43_ntab_framelookup);
+ ntab_upload(dev, B43_NTAB_TMAP, b43_ntab_tmap);
+ ntab_upload(dev, B43_NTAB_TDTRN, b43_ntab_tdtrn);
+ ntab_upload(dev, B43_NTAB_INTLEVEL, b43_ntab_intlevel);
+ ntab_upload(dev, B43_NTAB_PILOT, b43_ntab_pilot);
+ ntab_upload(dev, B43_NTAB_PILOTLT, b43_ntab_pilotlt);
+ ntab_upload(dev, B43_NTAB_TDI20A0, b43_ntab_tdi20a0);
+ ntab_upload(dev, B43_NTAB_TDI20A1, b43_ntab_tdi20a1);
+ ntab_upload(dev, B43_NTAB_TDI40A0, b43_ntab_tdi40a0);
+ ntab_upload(dev, B43_NTAB_TDI40A1, b43_ntab_tdi40a1);
+ ntab_upload(dev, B43_NTAB_BDI, b43_ntab_bdi);
+ ntab_upload(dev, B43_NTAB_CHANEST, b43_ntab_channelest);
+ ntab_upload(dev, B43_NTAB_MCS, b43_ntab_mcs);
+
+ /* Volatile tables */
+ ntab_upload(dev, B43_NTAB_NOISEVAR10, b43_ntab_noisevar10);
+ ntab_upload(dev, B43_NTAB_NOISEVAR11, b43_ntab_noisevar11);
+ ntab_upload(dev, B43_NTAB_C0_ESTPLT, b43_ntab_estimatepowerlt0);
+ ntab_upload(dev, B43_NTAB_C1_ESTPLT, b43_ntab_estimatepowerlt1);
+ ntab_upload(dev, B43_NTAB_C0_ADJPLT, b43_ntab_adjustpower0);
+ ntab_upload(dev, B43_NTAB_C1_ADJPLT, b43_ntab_adjustpower1);
+ ntab_upload(dev, B43_NTAB_C0_GAINCTL, b43_ntab_gainctl0);
+ ntab_upload(dev, B43_NTAB_C1_GAINCTL, b43_ntab_gainctl1);
+ ntab_upload(dev, B43_NTAB_C0_IQLT, b43_ntab_iqlt0);
+ ntab_upload(dev, B43_NTAB_C1_IQLT, b43_ntab_iqlt1);
+ ntab_upload(dev, B43_NTAB_C0_LOFEEDTH, b43_ntab_loftlt0);
+ ntab_upload(dev, B43_NTAB_C1_LOFEEDTH, b43_ntab_loftlt1);
+}
+
+static void b43_nphy_workarounds(struct b43_wldev *dev)
+{
+ struct b43_phy *phy = dev-phy;
+ unsigned int i;
+
+ b43_phy_set(dev, B43_NPHY_IQFLIP,
+ B43_NPHY_IQFLIP_ADC1 | B43_NPHY_IQFLIP_ADC2);
+ //FIXME the following condition is different in the specs.
+ if (1 /* FIXME band is 2.4GHz */) {
+ b43_phy_set(dev, B43_NPHY_CLASSCTL,
+ B43_NPHY_CLASSCTL_CCKEN);
+ } else {
+ b43_phy_mask(dev, B43_NPHY_CLASSCTL,
+~B43_NPHY_CLASSCTL_CCKEN);
+ }
+ b43_radio_set(dev, B2055_C1_TX_RF_SPARE, 0x8);
+ b43_phy_write(dev, B43_NPHY_TXFRAMEDELAY, 8);
+
+ /* Fixup some tables */
+ b43_ntab_write(dev, B43_NTAB16(8, 0x00), 0xA);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x10), 0xA);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x02), 0xCDAA);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x12), 0xCDAA);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x08), 0);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x18), 0);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x07), 0x7AAB);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x17), 0x7AAB);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x06), 0x800);
+ b43_ntab_write(dev, B43_NTAB16(8, 0x16), 0x800);
+
+ b43_phy_write(dev, B43_NPHY_RFCTL_LUT_TRSW_LO1, 0x2D8);
+ b43_phy_write(dev, B43_NPHY_RFCTL_LUT_TRSW_UP1, 0x301);
+ b43_phy_write(dev, B43_NPHY_RFCTL_LUT_TRSW_LO2, 0x2D8);
+ b43_phy_write(dev, B43_NPHY_RFCTL_LUT_TRSW_UP2, 0x301);
+
+ //TODO set RF sequence
+
+ /* Set narrowband clip threshold */
+ b43_phy_write(dev, B43_NPHY_C1_NBCLIPTHRES, 66);
+ b43_phy_write(dev, B43_NPHY_C2_NBCLIPTHRES, 66);
+
+ /* Set wideband clip 2 threshold */
+ b43_phy_maskset(dev, B43_NPHY_C1_CLIPWBTHRES,
+ ~B43_NPHY_C1_CLIPWBTHRES_CLIP2,
+ 21 B43_NPHY_C1_CLIPWBTHRES_CLIP2_SHIFT);
+ b43_phy_maskset(dev
Re: b43_suspend problem
On Sunday 20 January 2008, Rafael J. Wysocki wrote: Nah, please don't obfuscate the code. Better add a flag to struct b43_wldev and check that in the few places that need different behaviour. I can do that, if you prefer, but that will look worse, IMHO. I'm pretty sure it won't. We had such a flag in the past for firmware. (Fixed that differently now). You simply have do do dev-suspending = 1; at the beginning of suspend/resume and dev-suspending = 0; at the end. The if() checks in the code remain the same. The only thing that this approach won't do it clutter the (already hard to understand) interface up/down API. And that is good. We already have enough special cases for this stuff due to device weirdness. Let's not make it worse. I had a hard time to make a sane API for this (look at bcm43xx to compare to the old crap that doesn't work on lots of devices. ;) ) Thanks for doing this patch. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43_suspend problem
On Monday 21 January 2008, Rafael J. Wysocki wrote:
I modified the patch to implement something like this. This still is one big
patch against everything what's necessary. [BTW, in the current version
of the code, b43_resume() may leave wl-mutex locked in the error paths,
which also is fixed by the patch.]
Whoopsy, thanks for catching this.
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/main.c
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
@@ -2470,10 +2470,10 @@ static int b43_rng_read(struct hwrng *rn
return (sizeof(u16));
}
-static void b43_rng_exit(struct b43_wl *wl)
+static void b43_rng_exit(struct b43_wl *wl, bool suspended)
{
if (wl-rng_initialized)
- hwrng_unregister(wl-rng);
+ __hwrng_unregister(wl-rng, suspended);
}
static int b43_rng_init(struct b43_wl *wl)
@@ -3298,8 +3298,10 @@ static void b43_wireless_core_exit(struc
return;
b43_set_status(dev, B43_STAT_UNINIT);
- b43_leds_exit(dev);
- b43_rng_exit(dev-wl);
+ if (!dev-suspend_in_progress) {
+ b43_leds_exit(dev);
+ b43_rng_exit(dev-wl, false);
+ }
b43_pio_free(dev);
b43_dma_free(dev);
b43_chip_exit(dev);
@@ -3420,11 +3422,13 @@ static int b43_wireless_core_init(struct
memset(wl-mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
- b43_rng_init(wl);
+ if (!dev-suspend_in_progress)
+ b43_rng_init(wl);
b43_set_status(dev, B43_STAT_INITIALIZED);
- b43_leds_init(dev);
+ if (!dev-suspend_in_progress)
+ b43_leds_init(dev);
out:
return err;
@@ -4024,6 +4028,7 @@ static int b43_suspend(struct ssb_device
b43dbg(wl, Suspending...\n);
mutex_lock(wl-mutex);
+ wldev-suspend_in_progress = true;
wldev-suspend_init_status = b43_status(wldev);
if (wldev-suspend_init_status = B43_STAT_STARTED)
b43_wireless_core_stop(wldev);
@@ -4055,15 +4060,17 @@ static int b43_resume(struct ssb_device
if (wldev-suspend_init_status = B43_STAT_STARTED) {
err = b43_wireless_core_start(wldev);
if (err) {
+ b43_leds_resume_exit(wldev);
+ b43_rng_exit(wldev-wl, true);
b43_wireless_core_exit(wldev);
b43err(wl, Resume failed at core start\n);
goto out;
}
}
- mutex_unlock(wl-mutex);
-
b43dbg(wl, Device resumed.\n);
- out:
+ out:
+ wldev-suspend_in_progress = false;
+ mutex_unlock(wl-mutex);
return err;
}
This part looks OK.
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.h
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/leds.h
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.h
@@ -43,8 +43,15 @@ enum b43_led_behaviour {
};
void b43_leds_init(struct b43_wldev *dev);
-void b43_leds_exit(struct b43_wldev *dev);
-
+void __b43_leds_exit(struct b43_wldev *dev, bool suspended);
+static inline void b43_leds_exit(struct b43_wldev *dev)
+{
+ __b43_leds_exit(dev, false);
+}
+static inline void b43_leds_resume_exit(struct b43_wldev *dev)
+{
+ __b43_leds_exit(dev, true);
+}
I still don't like this function wrapping.
I'm pretty sure the additional parameter to the function is not
needed. We can check dev-suspend_in_progress to find out
if we are in a up/down or in a suspend/resume cycle.
-static void b43_unregister_led(struct b43_led *led)
+static void b43_unregister_led(struct b43_led *led, bool suspended)
{
if (!led-dev)
return;
- led_classdev_unregister(led-led_dev);
+ if (suspended)
You can check led-dev-suspend_in_progress here.
+ led_classdev_unregister_suspended(led-led_dev);
+ else
+ led_classdev_unregister(led-led_dev);
b43_led_turn_off(led-dev, led-index, led-activelow);
led-dev = NULL;
}
@@ -230,10 +233,10 @@ void b43_leds_init(struct b43_wldev *dev
}
}
-void b43_leds_exit(struct b43_wldev *dev)
+void __b43_leds_exit(struct b43_wldev *dev, bool suspended)
{
- b43_unregister_led(dev-led_tx);
- b43_unregister_led(dev-led_rx);
- b43_unregister_led(dev-led_assoc);
- b43_unregister_led(dev-led_radio);
+ b43_unregister_led(dev-led_tx, suspended);
+ b43_unregister_led(dev-led_rx, suspended);
+ b43_unregister_led(dev-led_assoc, suspended);
+ b43_unregister_led(dev-led_radio, suspended);
}
Don't need this hunk. Check led-dev-suspend_in_progress in
b43_unregister_led.
#endif /* __KERNEL__ */
#endif /* LINUX_HWRANDOM_H_ */
Index:
[PATCH] b43: Fix firmware caching
We must also store the ID string (filename) for the cached firmware blobs
and verify that we really have the right firmware cached before using it.
If we don't have the right fw cached, we must free it and request the
correct blobs.
This fixes bandswitch on A/B/G multi-PHY devices.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as we don't support A-PHY operation, yet, we don't need to
apply this patch to 2.6.24. Please queue this patch for 2.6.25.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2008-01-16
23:26:30.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2008-01-21 18:38:33.0
+0100
@@ -663,22 +663,29 @@ struct b43_wl {
* This beacon stuff is protected by the irq_lock. */
struct sk_buff *current_beacon;
bool beacon0_uploaded;
bool beacon1_uploaded;
};
+/* In-memory representation of a cached microcode file. */
+struct b43_firmware_file {
+ const char *filename;
+ const struct firmware *data;
+};
+
/* Pointers to the firmware data and meta information about it. */
struct b43_firmware {
/* Microcode */
- const struct firmware *ucode;
+ struct b43_firmware_file ucode;
/* PCM code */
- const struct firmware *pcm;
+ struct b43_firmware_file pcm;
/* Initial MMIO values for the firmware */
- const struct firmware *initvals;
+ struct b43_firmware_file initvals;
/* Initial MMIO values for the firmware, band-specific */
- const struct firmware *initvals_band;
+ struct b43_firmware_file initvals_band;
+
/* Firmware revision */
u16 rev;
/* Firmware patchlevel */
u16 patch;
};
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-21
18:28:36.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-21
19:42:15.0 +0100
@@ -1554,22 +1554,25 @@ static irqreturn_t b43_interrupt_handler
mmiowb();
spin_unlock(dev-wl-irq_lock);
return ret;
}
+static void do_release_fw(struct b43_firmware_file *fw)
+{
+ release_firmware(fw-data);
+ fw-data = NULL;
+ fw-filename = NULL;
+}
+
static void b43_release_firmware(struct b43_wldev *dev)
{
- release_firmware(dev-fw.ucode);
- dev-fw.ucode = NULL;
- release_firmware(dev-fw.pcm);
- dev-fw.pcm = NULL;
- release_firmware(dev-fw.initvals);
- dev-fw.initvals = NULL;
- release_firmware(dev-fw.initvals_band);
- dev-fw.initvals_band = NULL;
+ do_release_fw(dev-fw.ucode);
+ do_release_fw(dev-fw.pcm);
+ do_release_fw(dev-fw.initvals);
+ do_release_fw(dev-fw.initvals_band);
}
static void b43_print_fw_helptext(struct b43_wl *wl, bool error)
{
const char *text;
@@ -1581,155 +1584,169 @@ static void b43_print_fw_helptext(struct
else
b43warn(wl, text);
}
static int do_request_fw(struct b43_wldev *dev,
const char *name,
-const struct firmware **fw)
+struct b43_firmware_file *fw)
{
char path[sizeof(modparam_fwpostfix) + 32];
+ const struct firmware *blob;
struct b43_fw_header *hdr;
u32 size;
int err;
- if (!name)
+ if (!name) {
+ /* Don't fetch anything. Free possibly cached firmware. */
+ do_release_fw(fw);
return 0;
+ }
+ if (fw-filename) {
+ if (strcmp(fw-filename, name) == 0)
+ return 0; /* Already have this fw. */
+ /* Free the cached firmware first. */
+ do_release_fw(fw);
+ }
snprintf(path, ARRAY_SIZE(path),
b43%s/%s.fw,
modparam_fwpostfix, name);
- err = request_firmware(fw, path, dev-dev-dev);
+ err = request_firmware(blob, path, dev-dev-dev);
if (err) {
b43err(dev-wl, Firmware file \%s\ not found
or load failed.\n, path);
return err;
}
- if ((*fw)-size sizeof(struct b43_fw_header))
+ if (blob-size sizeof(struct b43_fw_header))
goto err_format;
- hdr = (struct b43_fw_header *)((*fw)-data);
+ hdr = (struct b43_fw_header *)(blob-data);
switch (hdr-type) {
case B43_FW_TYPE_UCODE:
case B43_FW_TYPE_PCM:
size = be32_to_cpu(hdr-size);
- if (size != (*fw)-size - sizeof(struct b43_fw_header))
+ if (size != blob-size - sizeof(struct b43_fw_header))
goto err_format;
/* fallthrough */
case B43_FW_TYPE_IV
Re: b43_suspend problem
On Tuesday 22 January 2008 00:36:45 Rafael J. Wysocki wrote: I still don't like this function wrapping. I'm pretty sure the additional parameter to the function is not needed. We can check dev-suspend_in_progress to find out if we are in a up/down or in a suspend/resume cycle. You're right, I overlooked that. [snip] The patch looks good. Did you try it on b43 hardware? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix MAC control and microcode init
This zeros out all microcode related memory before loading
the microcode.
This also fixes initialization of the MAC control register.
The _only_ place where we overwrite the contents of the MAC control
register is at the beginning of b43_chip_init().
All other places must do read() - mask/set - write() to not
overwrite existing bits.
This also adds a longer delay for waiting for the microcode
to initialize itself. It seems that the current timeout is sufficient
on all available devices, but there's no real reason why we shouldn't
wait for up to one second. Slow embedded devices might exist.
Better safe than sorry.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this bugfix should go into 2.6.24.
Stefano, this must be ported to b43legacy.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-22
19:23:50.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-22
20:00:00.0 +0100
@@ -1775,15 +1775,26 @@ error:
static int b43_upload_microcode(struct b43_wldev *dev)
{
const size_t hdr_len = sizeof(struct b43_fw_header);
const __be32 *data;
unsigned int i, len;
u16 fwrev, fwpatch, fwdate, fwtime;
- u32 tmp;
+ u32 tmp, macctl;
int err = 0;
+ /* Jump the microcode PSM to offset 0 */
+ macctl = b43_read32(dev, B43_MMIO_MACCTL);
+ B43_WARN_ON(macctl B43_MACCTL_PSM_RUN);
+ macctl |= B43_MACCTL_PSM_JMP0;
+ b43_write32(dev, B43_MMIO_MACCTL, macctl);
+ /* Zero out all microcode PSM registers and shared memory. */
+ for (i = 0; i 64; i++)
+ b43_shm_write16(dev, B43_SHM_SCRATCH, i, 0);
+ for (i = 0; i 4096; i += 2)
+ b43_shm_write16(dev, B43_SHM_SHARED, i, 0);
+
/* Upload Microcode. */
data = (__be32 *) (dev-fw.ucode.data-data + hdr_len);
len = (dev-fw.ucode.data-size - hdr_len) / sizeof(__be32);
b43_shm_control_word(dev, B43_SHM_UCODE | B43_SHM_AUTOINC_W, 0x);
for (i = 0; i len; i++) {
b43_write32(dev, B43_MMIO_SHM_DATA, be32_to_cpu(data[i]));
@@ -1802,30 +1813,37 @@ static int b43_upload_microcode(struct b
b43_write32(dev, B43_MMIO_SHM_DATA,
be32_to_cpu(data[i]));
udelay(10);
}
}
b43_write32(dev, B43_MMIO_GEN_IRQ_REASON, B43_IRQ_ALL);
- b43_write32(dev, B43_MMIO_MACCTL,
- B43_MACCTL_PSM_RUN |
- B43_MACCTL_IHR_ENABLED | B43_MACCTL_INFRA);
+
+ /* Start the microcode PSM */
+ macctl = b43_read32(dev, B43_MMIO_MACCTL);
+ macctl = ~B43_MACCTL_PSM_JMP0;
+ macctl |= B43_MACCTL_PSM_RUN;
+ b43_write32(dev, B43_MMIO_MACCTL, macctl);
/* Wait for the microcode to load and respond */
i = 0;
while (1) {
tmp = b43_read32(dev, B43_MMIO_GEN_IRQ_REASON);
if (tmp == B43_IRQ_MAC_SUSPENDED)
break;
i++;
- if (i = 50) {
+ if (i = 20) {
b43err(dev-wl, Microcode not responding\n);
b43_print_fw_helptext(dev-wl, 1);
err = -ENODEV;
- goto out;
+ goto error;
+ }
+ msleep_interruptible(50);
+ if (signal_pending(current)) {
+ err = -EINTR;
+ goto error;
}
- udelay(10);
}
b43_read32(dev, B43_MMIO_GEN_IRQ_REASON); /* dummy read */
/* Get and check the revisions. */
fwrev = b43_shm_read16(dev, B43_SHM_SHARED, B43_SHM_SH_UCODEREV);
fwpatch = b43_shm_read16(dev, B43_SHM_SHARED, B43_SHM_SH_UCODEPATCH);
@@ -1834,15 +1852,14 @@ static int b43_upload_microcode(struct b
if (fwrev = 0x128) {
b43err(dev-wl, YOUR FIRMWARE IS TOO OLD. Firmware from
binary drivers older than version 4.x is unsupported.
You must upgrade your firmware files.\n);
b43_print_fw_helptext(dev-wl, 1);
- b43_write32(dev, B43_MMIO_MACCTL, 0);
err = -EOPNOTSUPP;
- goto out;
+ goto error;
}
b43dbg(dev-wl, Loading firmware version %u.%u
(20%.2i-%.2i-%.2i %.2i:%.2i:%.2i)\n,
fwrev, fwpatch,
(fwdate 12) 0xF, (fwdate 8) 0xF, fwdate 0xFF,
(fwtime 11) 0x1F, (fwtime 5) 0x3F, fwtime 0x1F);
@@ -1853,13 +1870,20 @@ static int b43_upload_microcode(struct b
if (b43_is_old_txhdr_format(dev)) {
b43warn(dev-wl, You are using an old firmware image.
Support for old firmware will be removed in July
2008.\n
[PATCH] b43: Fix rfkill allocation leakage in error paths
We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please try to push this for 2.6.24. Seems quite important,
as it leaks resources and might crash the kernel.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-23
11:52:50.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-23
11:55:17.0 +0100
@@ -3626,38 +3626,45 @@ static void b43_op_remove_interface(stru
static int b43_op_start(struct ieee80211_hw *hw)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl-current_dev;
int did_init = 0;
int err = 0;
+ bool do_rfkill_exit = 0;
/* First register RFkill.
* LEDs that are registered later depend on it. */
b43_rfkill_init(dev);
mutex_lock(wl-mutex);
if (b43_status(dev) B43_STAT_INITIALIZED) {
err = b43_wireless_core_init(dev);
- if (err)
+ if (err) {
+ do_rfkill_exit = 1;
goto out_mutex_unlock;
+ }
did_init = 1;
}
if (b43_status(dev) B43_STAT_STARTED) {
err = b43_wireless_core_start(dev);
if (err) {
if (did_init)
b43_wireless_core_exit(dev);
+ do_rfkill_exit = 1;
goto out_mutex_unlock;
}
}
out_mutex_unlock:
mutex_unlock(wl-mutex);
+ if (do_rfkill_exit)
+ b43_rfkill_exit(dev);
+
return err;
}
static void b43_op_stop(struct ieee80211_hw *hw)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43legacy: Fix rfkill allocation leakage in error paths
We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please try to push this for 2.6.24. Seems quite important,
as it leaks resources and might crash the kernel.
Index: wireless-2.6/drivers/net/wireless/b43legacy/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43legacy/main.c 2008-01-16
23:28:50.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43legacy/main.c 2008-01-23
12:04:41.0 +0100
@@ -3218,38 +3218,45 @@ static void b43legacy_op_remove_interfac
static int b43legacy_op_start(struct ieee80211_hw *hw)
{
struct b43legacy_wl *wl = hw_to_b43legacy_wl(hw);
struct b43legacy_wldev *dev = wl-current_dev;
int did_init = 0;
int err = 0;
+ bool do_rfkill_exit = 0;
/* First register RFkill.
* LEDs that are registered later depend on it. */
b43legacy_rfkill_init(dev);
mutex_lock(wl-mutex);
if (b43legacy_status(dev) B43legacy_STAT_INITIALIZED) {
err = b43legacy_wireless_core_init(dev);
- if (err)
+ if (err) {
+ do_rfkill_exit = 1;
goto out_mutex_unlock;
+ }
did_init = 1;
}
if (b43legacy_status(dev) B43legacy_STAT_STARTED) {
err = b43legacy_wireless_core_start(dev);
if (err) {
if (did_init)
b43legacy_wireless_core_exit(dev);
+ do_rfkill_exit = 1;
goto out_mutex_unlock;
}
}
out_mutex_unlock:
mutex_unlock(wl-mutex);
+ if (do_rfkill_exit)
+ b43legacy_rfkill_exit(dev);
+
return err;
}
static void b43legacy_op_stop(struct ieee80211_hw *hw)
{
struct b43legacy_wl *wl = hw_to_b43legacy_wl(hw);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix suspend/resume
This fixes suspend/resume.
We must not overwrite the MAC addresses on resume. Otherwise
the card won't ACK any packets anymore.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix that makes suspend/resume working. Without this
people need to do an interface up/down cycle after each resume.
Please try to push it for 2.6.24.
Stefano, this might need porting to legacy.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-01-23
21:01:44.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-01-23
21:02:16.0 +0100
@@ -3528,14 +3528,12 @@ static int b43_wireless_core_init(struct
/* Set the pre-wakeup for synthetic PU (in microseconds). */
b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_SPUWKUP, 500);
b43_bluetooth_coext_enable(dev);
ssb_bus_powerup(bus, 1);/* Enable dynamic PCTL */
- memset(wl-bssid, 0, ETH_ALEN);
- memset(wl-mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
b43_rng_init(wl);
b43_set_status(dev, B43_STAT_INITIALIZED);
@@ -3628,12 +3626,20 @@ static int b43_op_start(struct ieee80211
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl-current_dev;
int did_init = 0;
int err = 0;
bool do_rfkill_exit = 0;
+ /* Kill all old instance specific information to make sure
+* the card won't use it in the short timeframe between start
+* and mac80211 reconfiguring it. */
+ memset(wl-bssid, 0, ETH_ALEN);
+ memset(wl-mac_addr, 0, ETH_ALEN);
+ wl-filter_flags = 0;
+ wl-radiotap_enabled = 0;
+
/* First register RFkill.
* LEDs that are registered later depend on it. */
b43_rfkill_init(dev);
mutex_lock(wl-mutex);
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/xmit.c 2008-01-23
21:01:44.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/xmit.c2008-01-23
21:02:16.0 +0100
@@ -234,26 +234,29 @@ void b43_generate_txhdr(struct b43_wldev
struct b43_key *key;
int wlhdr_len;
size_t iv_len;
B43_WARN_ON(key_idx = dev-max_nr_keys);
key = (dev-key[key_idx]);
- B43_WARN_ON(!key-keyconf);
- /* Hardware appends ICV. */
- plcp_fragment_len += txctl-icv_len;
+ if (likely(key-keyconf)) {
+ /* This key is valid. Use it for encryption. */
- key_idx = b43_kidx_to_fw(dev, key_idx);
- mac_ctl |= (key_idx B43_TXH_MAC_KEYIDX_SHIFT)
- B43_TXH_MAC_KEYIDX;
- mac_ctl |= (key-algorithm B43_TXH_MAC_KEYALG_SHIFT)
- B43_TXH_MAC_KEYALG;
- wlhdr_len = ieee80211_get_hdrlen(fctl);
- iv_len = min((size_t) txctl-iv_len,
-ARRAY_SIZE(txhdr-iv));
- memcpy(txhdr-iv, ((u8 *) wlhdr) + wlhdr_len, iv_len);
+ /* Hardware appends ICV. */
+ plcp_fragment_len += txctl-icv_len;
+
+ key_idx = b43_kidx_to_fw(dev, key_idx);
+ mac_ctl |= (key_idx B43_TXH_MAC_KEYIDX_SHIFT)
+ B43_TXH_MAC_KEYIDX;
+ mac_ctl |= (key-algorithm B43_TXH_MAC_KEYALG_SHIFT)
+ B43_TXH_MAC_KEYALG;
+ wlhdr_len = ieee80211_get_hdrlen(fctl);
+ iv_len = min((size_t) txctl-iv_len,
+ARRAY_SIZE(txhdr-iv));
+ memcpy(txhdr-iv, ((u8 *) wlhdr) + wlhdr_len, iv_len);
+ }
}
if (b43_is_old_txhdr_format(dev)) {
b43_generate_plcp_hdr((struct b43_plcp_hdr4
*)(txhdr-old_format.plcp),
plcp_fragment_len, rate);
} else {
b43_generate_plcp_hdr((struct b43_plcp_hdr4
*)(txhdr-new_format.plcp),
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Drop packets that we are not able to encrypt
We must not transmit packets we're not able to encrypt.
This fixes a bug where in a tiny timeframe after machine resume
packets can get sent unencrypted and might leak information.
This also fixes three small resource leakages I spotted while fixing
the security problem. Properly deallocate the DMA slots in any DMA
allocation error path.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is _not_ only a theoretical problem. I saw a few packets hitting
this race condition.
John, please try to push for 2.6.24, as this is a security fix.
Stefano, this might need porting to legacy.
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c2008-01-22
18:43:47.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/dma.c 2008-01-23 21:34:42.0
+0100
@@ -,38 +,49 @@ struct b43_dmaring *parse_cookie(struct
static int dma_tx_fragment(struct b43_dmaring *ring,
struct sk_buff *skb,
struct ieee80211_tx_control *ctl)
{
const struct b43_dma_ops *ops = ring-ops;
u8 *header;
- int slot;
+ int slot, old_top_slot, old_used_slots;
int err;
struct b43_dmadesc_generic *desc;
struct b43_dmadesc_meta *meta;
struct b43_dmadesc_meta *meta_hdr;
struct sk_buff *bounce_skb;
u16 cookie;
size_t hdrsize = b43_txhdr_size(ring-dev);
#define SLOTS_PER_PACKET 2
B43_WARN_ON(skb_shinfo(skb)-nr_frags);
+ old_top_slot = ring-current_slot;
+ old_used_slots = ring-used_slots;
+
/* Get a slot for the header. */
slot = request_slot(ring);
desc = ops-idx2desc(ring, slot, meta_hdr);
memset(meta_hdr, 0, sizeof(*meta_hdr));
header = (ring-txhdr_cache[slot * hdrsize]);
cookie = generate_cookie(ring, slot);
- b43_generate_txhdr(ring-dev, header,
- skb-data, skb-len, ctl, cookie);
+ err = b43_generate_txhdr(ring-dev, header,
+skb-data, skb-len, ctl, cookie);
+ if (unlikely(err)) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
+ return err;
+ }
meta_hdr-dmaaddr = map_descbuffer(ring, (unsigned char *)header,
hdrsize, 1);
- if (dma_mapping_error(meta_hdr-dmaaddr))
+ if (dma_mapping_error(meta_hdr-dmaaddr)) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
return -EIO;
+ }
ops-fill_descriptor(ring, desc, meta_hdr-dmaaddr,
hdrsize, 1, 0, 0);
/* Get a slot for the payload. */
slot = request_slot(ring);
desc = ops-idx2desc(ring, slot, meta);
@@ -1154,22 +1165,26 @@ static int dma_tx_fragment(struct b43_dm
meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
/* create a bounce buffer in zone_dma on mapping failure. */
if (dma_mapping_error(meta-dmaaddr)) {
bounce_skb = __dev_alloc_skb(skb-len, GFP_ATOMIC | GFP_DMA);
if (!bounce_skb) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
err = -ENOMEM;
goto out_unmap_hdr;
}
memcpy(skb_put(bounce_skb, skb-len), skb-data, skb-len);
dev_kfree_skb_any(skb);
skb = bounce_skb;
meta-skb = skb;
meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
if (dma_mapping_error(meta-dmaaddr)) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
err = -EIO;
goto out_free_bounce;
}
}
ops-fill_descriptor(ring, desc, meta-dmaaddr, skb-len, 0, 1, 1);
@@ -1249,12 +1264,19 @@ int b43_dma_tx(struct b43_wldev *dev,
/* Check if the queue was stopped in mac80211,
* but we got called nevertheless.
* That would be a mac80211 bug. */
B43_WARN_ON(ring-stopped);
err = dma_tx_fragment(ring, skb, ctl);
+ if (unlikely(err == -ENOKEY)) {
+ /* Drop this packet, as we don't have the encryption key
+* anymore and must not transmit it unencrypted. */
+ dev_kfree_skb_any(skb);
+ err = 0;
+ goto out_unlock;
+ }
if (unlikely(err)) {
b43err(dev-wl, DMA tx mapping failure\n);
goto out_unlock;
}
ring-nr_tx_packets++;
if ((free_slots(ring) SLOTS_PER_PACKET) ||
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
Re: [PATCH] b43: Fix MAC control and microcode init
On Thursday 24 January 2008 10:13:01 Johannes Berg wrote: This also adds a longer delay for waiting for the microcode to initialize itself. It seems that the current timeout is sufficient on all available devices, but there's no real reason why we shouldn't wait for up to one second. Slow embedded devices might exist. Your decision, but I very much doubt you can make the MAC any slower than on the old devices, in fact, on new chips it runs considerably faster I think. Ok, well. But the host machine does get faster. In theory we only gave the microcode 500 microseconds of time to initialize. I think that is is a pretty tiny timeframe. In practice the time was higher, because we had a loop that checked MMIO and delayed for 10usec. Of course this all has overhead. But as machines get faster and faster I think we can't assume to have more than 500 microseconds of time. So, increasing the delay to one second doesn't hurt anyone. In all common cases it will continue after a few milliseconds. That's fine. Even if there is something going wrong (wrong firmware) you can interrupt the one second delay by hitting ^C. I think the specs originally sayed to use a much longer delay than we were using. But we did use a shorter delay, because in some old bcm43xx code this ran unter spinlock as far as I remember. So we didn't want to spin several milliseconds and lockup the system, if something goes wrong in firmware. These times are gone and now we can sleep in this part of the code. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH -mm 5/5] b43: Avoid unregistering device objects during suspend
On Friday 25 January 2008 08:47:46 Pavel Machek wrote: On Fri 2008-01-25 01:37:33, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] Modify the b43 driver to avoid deadlocking suspend and resume, which happens as a result of attempting to unregister device objects locked by the PM core during suspend/resume cycles. Also, make it use a suspend-safe method of unregistering device object in the resume error path. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Michael Buesch [EMAIL PROTECTED] Maybe we should have global suspend_in_progress (or maybe system_state == suspending?) and automatically switch to schedule_removal() while it is set? That would be great, from my perspective :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH stable 3/3] b43: Fix dma-slot resource leakage
This fixes four resource leakages.
In any error path we must deallocate the DMA frame slots we
previously allocated by request_slot().
This is done by storing the ring pointers before doing any ring
allocation and restoring the old pointers in case of an error.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is upstream inside of the netdev tree.
Index: linux-2.6.24/drivers/net/wireless/b43/dma.c
===
--- linux-2.6.24.orig/drivers/net/wireless/b43/dma.c2008-01-25
11:48:31.0 +0100
+++ linux-2.6.24/drivers/net/wireless/b43/dma.c 2008-01-25 11:48:34.0
+0100
@@ -1106,7 +1106,7 @@ static int dma_tx_fragment(struct b43_dm
{
const struct b43_dma_ops *ops = ring-ops;
u8 *header;
- int slot;
+ int slot, old_top_slot, old_used_slots;
int err;
struct b43_dmadesc_generic *desc;
struct b43_dmadesc_meta *meta;
@@ -1116,6 +1116,9 @@ static int dma_tx_fragment(struct b43_dm
#define SLOTS_PER_PACKET 2
B43_WARN_ON(skb_shinfo(skb)-nr_frags);
+ old_top_slot = ring-current_slot;
+ old_used_slots = ring-used_slots;
+
/* Get a slot for the header. */
slot = request_slot(ring);
desc = ops-idx2desc(ring, slot, meta_hdr);
@@ -1125,13 +1128,19 @@ static int dma_tx_fragment(struct b43_dm
err = b43_generate_txhdr(ring-dev, header,
skb-data, skb-len, ctl,
generate_cookie(ring, slot));
- if (unlikely(err))
+ if (unlikely(err)) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
return err;
+ }
meta_hdr-dmaaddr = map_descbuffer(ring, (unsigned char *)header,
sizeof(struct b43_txhdr_fw4), 1);
- if (dma_mapping_error(meta_hdr-dmaaddr))
+ if (dma_mapping_error(meta_hdr-dmaaddr)) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
return -EIO;
+ }
ops-fill_descriptor(ring, desc, meta_hdr-dmaaddr,
sizeof(struct b43_txhdr_fw4), 1, 0, 0);
@@ -1149,6 +1158,8 @@ static int dma_tx_fragment(struct b43_dm
if (dma_mapping_error(meta-dmaaddr)) {
bounce_skb = __dev_alloc_skb(skb-len, GFP_ATOMIC | GFP_DMA);
if (!bounce_skb) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
err = -ENOMEM;
goto out_unmap_hdr;
}
@@ -1159,6 +1170,8 @@ static int dma_tx_fragment(struct b43_dm
meta-skb = skb;
meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
if (dma_mapping_error(meta-dmaaddr)) {
+ ring-current_slot = old_top_slot;
+ ring-used_slots = old_used_slots;
err = -EIO;
goto out_free_bounce;
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH stable 1/3] b43: Fix suspend/resume
This patch makes suspend/resume work with the b43 driver. We must not overwrite the MAC addresses in the init function, as this would also overwrite the MAC on resume. With an all-zero MAC the device firmware is not able to ACK any received packets anymore. Fix this by moving the initializion stuff that must be done on init but not on resume to the start function. Also zero out filter_flags to make sure we don't have some flags from a previous instance for a tiny timeframe until mac80211 reconfigures them. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- This patch is upstream inside of the netdev tree. Index: linux-2.6.24/drivers/net/wireless/b43/main.c === --- linux-2.6.24.orig/drivers/net/wireless/b43/main.c 2008-01-25 11:48:26.0 +0100 +++ linux-2.6.24/drivers/net/wireless/b43/main.c2008-01-25 11:48:28.0 +0100 @@ -3395,8 +3395,6 @@ static int b43_wireless_core_init(struct b43_bluetooth_coext_enable(dev); ssb_bus_powerup(bus, 1);/* Enable dynamic PCTL */ - memset(wl-bssid, 0, ETH_ALEN); - memset(wl-mac_addr, 0, ETH_ALEN); b43_upload_card_macaddress(dev); b43_security_init(dev); b43_rng_init(wl); @@ -3493,6 +3491,13 @@ static int b43_start(struct ieee80211_hw int did_init = 0; int err = 0; + /* Kill all old instance specific information to make sure +* the card won't use it in the short timeframe between start +* and mac80211 reconfiguring it. */ + memset(wl-bssid, 0, ETH_ALEN); + memset(wl-mac_addr, 0, ETH_ALEN); + wl-filter_flags = 0; + /* First register RFkill. * LEDs that are registered later depend on it. */ b43_rfkill_init(dev); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH stable 2/3] b43: Drop packets we are not able to encrypt
We must drop any packets we are not able to encrypt.
We must not send them unencrypted or with an all-zero-key (which
basically is the same as unencrypted, from a security point of view).
This might only trigger shortly after resume before mac80211 reassociated
and reconfigured the keys.
It is safe to drop these packets, as the association they belong to
is not guaranteed anymore anyway.
This is a security fix in the sense that it prevents information leakage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is upstream inside of the netdev tree.
Index: linux-2.6.24/drivers/net/wireless/b43/dma.c
===
--- linux-2.6.24.orig/drivers/net/wireless/b43/dma.c2008-01-25
11:48:25.0 +0100
+++ linux-2.6.24/drivers/net/wireless/b43/dma.c 2008-01-25 11:48:31.0
+0100
@@ -1122,9 +1122,11 @@ static int dma_tx_fragment(struct b43_dm
memset(meta_hdr, 0, sizeof(*meta_hdr));
header = (ring-txhdr_cache[slot * sizeof(struct b43_txhdr_fw4)]);
- b43_generate_txhdr(ring-dev, header,
+ err = b43_generate_txhdr(ring-dev, header,
skb-data, skb-len, ctl,
generate_cookie(ring, slot));
+ if (unlikely(err))
+ return err;
meta_hdr-dmaaddr = map_descbuffer(ring, (unsigned char *)header,
sizeof(struct b43_txhdr_fw4), 1);
@@ -1219,6 +1221,13 @@ int b43_dma_tx(struct b43_wldev *dev,
B43_WARN_ON(ring-stopped);
err = dma_tx_fragment(ring, skb, ctl);
+ if (unlikely(err == -ENOKEY)) {
+ /* Drop this packet, as we don't have the encryption key
+* anymore and must not transmit it unencrypted. */
+ dev_kfree_skb_any(skb);
+ err = 0;
+ goto out_unlock;
+ }
if (unlikely(err)) {
b43err(dev-wl, DMA tx mapping failure\n);
goto out_unlock;
Index: linux-2.6.24/drivers/net/wireless/b43/xmit.c
===
--- linux-2.6.24.orig/drivers/net/wireless/b43/xmit.c 2008-01-25
11:48:25.0 +0100
+++ linux-2.6.24/drivers/net/wireless/b43/xmit.c2008-01-25
11:48:31.0 +0100
@@ -177,7 +177,7 @@ static u8 b43_calc_fallback_rate(u8 bitr
return 0;
}
-static void generate_txhdr_fw4(struct b43_wldev *dev,
+static int generate_txhdr_fw4(struct b43_wldev *dev,
struct b43_txhdr_fw4 *txhdr,
const unsigned char *fragment_data,
unsigned int fragment_len,
@@ -235,7 +235,15 @@ static void generate_txhdr_fw4(struct b4
B43_WARN_ON(key_idx = dev-max_nr_keys);
key = (dev-key[key_idx]);
- B43_WARN_ON(!key-keyconf);
+
+ if (unlikely(!key-keyconf)) {
+ /* This key is invalid. This might only happen
+* in a short timeframe after machine resume before
+* we were able to reconfigure keys.
+* Drop this packet completely. Do not transmit it
+* unencrypted to avoid leaking information. */
+ return -ENOKEY;
+ }
/* Hardware appends ICV. */
plcp_fragment_len += txctl-icv_len;
@@ -352,16 +360,18 @@ static void generate_txhdr_fw4(struct b4
txhdr-mac_ctl = cpu_to_le32(mac_ctl);
txhdr-phy_ctl = cpu_to_le16(phy_ctl);
txhdr-extra_ft = extra_ft;
+
+ return 0;
}
-void b43_generate_txhdr(struct b43_wldev *dev,
+int b43_generate_txhdr(struct b43_wldev *dev,
u8 * txhdr,
const unsigned char *fragment_data,
unsigned int fragment_len,
const struct ieee80211_tx_control *txctl, u16 cookie)
{
- generate_txhdr_fw4(dev, (struct b43_txhdr_fw4 *)txhdr,
- fragment_data, fragment_len, txctl, cookie);
+ return generate_txhdr_fw4(dev, (struct b43_txhdr_fw4 *)txhdr,
+ fragment_data, fragment_len, txctl, cookie);
}
static s8 b43_rssi_postprocess(struct b43_wldev *dev,
Index: linux-2.6.24/drivers/net/wireless/b43/xmit.h
===
--- linux-2.6.24.orig/drivers/net/wireless/b43/xmit.h 2008-01-25
11:48:25.0 +0100
+++ linux-2.6.24/drivers/net/wireless/b43/xmit.h2008-01-25
11:48:31.0 +0100
@@ -82,7 +82,7 @@ struct b43_txhdr_fw4 {
#define B43_TX4_PHY_ANT1 0x0100 /* Use antenna 1 */
#define B43_TX4_PHY_ANTLAST 0x0300 /* Use last used antenna */
-void b43_generate_txhdr(struct b43_wldev *dev,
+int b43_generate_txhdr(struct b43_wldev *dev,
u8 * txhdr
Re: bcm4318 problem on HP nx6110
On Saturday 02 February 2008 04:52:59 [EMAIL PROTECTED] wrote: On the other hand, I'm going to go out on a limb and suggest that PERHAPS if you have ANY brainpower left, you include a full dmesg as well as an lsmod | grep b43 as well as an iwlist wlan0 scan ... or not. Ok, well. Seems like I'm not the most inhuman person on this list anymore. ;) Yayy!!! :D David, you are using the wrong firmware version (too new). Downgrade please. The human readable warning for this got lost in the 2.6.24 merge process. 2.6.24.1 will include a human readable warning for this. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Warning in DMA parse_cookie() - Solution here
If you get a warning in the DMA parse_cookie() function, it's because you are using too new firmware. Downgrade your firmware please. Please read this page _carefully_ an do _exactly_ what it says: http://www.linuxwireless.org/en/users/Drivers/b43#devicefirmware There is no human readable message, because the patch for this got lost in the 2.6.24 merge process. 2.6.24.1 will include a human readable error message instead of this implicit failure message. --- Hopefully this will help keeping the bugreports down, if one or two people do actually read the list archives. :P -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4318 problem on HP nx6110
On Saturday 02 February 2008 16:19:43 David Cohen wrote: Hi, On Feb 2, 2008 3:33 AM, Larry Finger [EMAIL PROTECTED] wrote: David Cohen wrote: Hi, I think this could be more clear now: $ sudo modprobe b43 $ no output dmesg: [ 3982.440406] b43-phy0: Broadcom 4318 WLAN found [ 3982.497218] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 [ 3982.497234] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 [ 3982.535653] phy0: Selected rate control algorithm 'simple' $ sudo ifconfig wlan0 up $ no output dmesg: [ 4325.614897] input: b43-phy2 as /class/input/input9 [ 4325.829189] b43-phy2 debug: Loading firmware version 410.2160 (2007-05-26 15:32:10) Congratulations You finally provided the necessary information. Your firmware is too new. This version (410.2160) needs the latest code from the wireless-2.6 git tree. To work with 2.6.24, you need firmware version 351. Thanks... it worked. But I'm using the latest code from wireless-2.6 (git-pulled few minutes ago) with firmware version 351. yeah that works too. Though, support is scheduled for removal. So if you are going to use wireless-2.6, you should use the latest fw. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4318 problem on HP nx6110
On Saturday 02 February 2008 16:47:40 David Cohen wrote: Hi, On Feb 2, 2008 11:31 AM, Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 02 February 2008 16:19:43 David Cohen wrote: Hi, On Feb 2, 2008 3:33 AM, Larry Finger [EMAIL PROTECTED] wrote: David Cohen wrote: Hi, I think this could be more clear now: $ sudo modprobe b43 $ no output dmesg: [ 3982.440406] b43-phy0: Broadcom 4318 WLAN found [ 3982.497218] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 [ 3982.497234] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 [ 3982.535653] phy0: Selected rate control algorithm 'simple' $ sudo ifconfig wlan0 up $ no output dmesg: [ 4325.614897] input: b43-phy2 as /class/input/input9 [ 4325.829189] b43-phy2 debug: Loading firmware version 410.2160 (2007-05-26 15:32:10) Congratulations You finally provided the necessary information. Your firmware is too new. This version (410.2160) needs the latest code from the wireless-2.6 git tree. To work with 2.6.24, you need firmware version 351. Thanks... it worked. But I'm using the latest code from wireless-2.6 (git-pulled few minutes ago) with firmware version 351. yeah that works too. Though, support is scheduled for removal. So if you are going to use wireless-2.6, you should use the latest fw. But the problem I described is wireless-2.6 with latest fw. Are you sure you are using branch #everything? Branch #master will include an older driver. #master is default. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43, 4306: DMA mode doesn't work
On Monday 04 February 2008 18:21:42 Matti Viljanen wrote: Michael Buesch kirjoitti: On Sunday 03 February 2008 22:15:57 David Cohen wrote: b43-phy0 ERROR: Fatal DMA error: 0x1000, 0x, 0x, 0x, 0x, 0x This is a Descriptor Protocol Error on the RX DMA engine. On which architecture are you running the card and how much RAM do you have? It seems that the descriptor ring is allocated in a memory region not accessible to the DMA engine (above 1G). Or the wrong DMA address is passed to the DMA engine, but I'd rule that out, as it works for everybody else. I am running 2.6.24-git13 i386 kernel on Athlon64 with 2GiB of RAM (Gentoo updates tend to kill HD's...) Try an x86_64 kernel. I bet it will work. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43, 4306: DMA mode doesn't work
On Monday 04 February 2008, Michael Buesch wrote:
On Monday 04 February 2008 18:21:42 Matti Viljanen wrote:
Michael Buesch kirjoitti:
On Sunday 03 February 2008 22:15:57 David Cohen wrote:
b43-phy0 ERROR: Fatal DMA error: 0x1000, 0x, 0x,
0x, 0x, 0x
This is a Descriptor Protocol Error on the RX DMA engine.
On which architecture are you running the card and how much RAM
do you have?
It seems that the descriptor ring is allocated in a memory region
not accessible to the DMA engine (above 1G).
Or the wrong DMA address is passed to the DMA engine, but I'd
rule that out, as it works for everybody else.
I am running 2.6.24-git13 i386 kernel on Athlon64 with 2GiB of RAM
(Gentoo updates tend to kill HD's...)
Try an x86_64 kernel. I bet it will work.
Can you also try the following patch on an i386 kernel?
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c2008-01-25
00:39:08.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/dma.c 2008-02-04 19:44:00.0
+0100
@@ -334,13 +334,13 @@ static inline int txring_to_priority(str
index = ring-index;
if (B43_WARN_ON(index = ARRAY_SIZE(idx_to_prio)))
index = 0;
return idx_to_prio[index];
}
-u16 b43_dmacontroller_base(int dma64bit, int controller_idx)
+static u16 b43_dmacontroller_base(enum b43_dmatype type, int controller_idx)
{
static const u16 map64[] = {
B43_MMIO_DMA64_BASE0,
B43_MMIO_DMA64_BASE1,
B43_MMIO_DMA64_BASE2,
B43_MMIO_DMA64_BASE3,
@@ -353,13 +353,13 @@ u16 b43_dmacontroller_base(int dma64bit,
B43_MMIO_DMA32_BASE2,
B43_MMIO_DMA32_BASE3,
B43_MMIO_DMA32_BASE4,
B43_MMIO_DMA32_BASE5,
};
- if (dma64bit) {
+ if (type == B43_DMA_64BIT) {
B43_WARN_ON(!(controller_idx = 0
controller_idx ARRAY_SIZE(map64)));
return map64[controller_idx];
}
B43_WARN_ON(!(controller_idx = 0
controller_idx ARRAY_SIZE(map32)));
@@ -434,13 +434,13 @@ static int alloc_ringmemory(struct b43_d
* does not cross an 8K boundary.
*
* For unknown reasons - possibly a hardware error - the BCM4311 rev
* 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
* which accounts for the GFP_DMA flag below.
*/
- if (ring-dma64)
+ if (ring-type == B43_DMA_64BIT)
flags |= GFP_DMA;
ring-descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
(ring-dmabase), flags);
if (!ring-descbase) {
b43err(ring-dev-wl, DMA ringmemory allocation failed\n);
return -ENOMEM;
@@ -456,26 +456,28 @@ static void free_ringmemory(struct b43_d
dma_free_coherent(dev, B43_DMA_RINGMEMSIZE,
ring-descbase, ring-dmabase);
}
/* Reset the RX DMA channel */
-int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
+static int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16 mmio_base,
+ enum b43_dmatype type)
{
int i;
u32 value;
u16 offset;
might_sleep();
- offset = dma64 ? B43_DMA64_RXCTL : B43_DMA32_RXCTL;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_RXCTL : B43_DMA32_RXCTL;
b43_write32(dev, mmio_base + offset, 0);
for (i = 0; i 10; i++) {
- offset = dma64 ? B43_DMA64_RXSTATUS : B43_DMA32_RXSTATUS;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_RXSTATUS :
+ B43_DMA32_RXSTATUS;
value = b43_read32(dev, mmio_base + offset);
- if (dma64) {
+ if (type == B43_DMA_64BIT) {
value = B43_DMA64_RXSTAT;
if (value == B43_DMA64_RXSTAT_DISABLED) {
i = -1;
break;
}
} else {
@@ -493,24 +495,26 @@ int b43_dmacontroller_rx_reset(struct b4
}
return 0;
}
/* Reset the TX DMA channel */
-int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
+static int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base,
+ enum b43_dmatype type)
{
int i;
u32 value;
u16 offset;
might_sleep();
for (i = 0; i 10; i++) {
- offset = dma64 ? B43_DMA64_TXSTATUS : B43_DMA32_TXSTATUS;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_TXSTATUS
Re: b43, 4306: DMA mode doesn't work
On Sunday 03 February 2008 22:15:57 David Cohen wrote: b43-phy0 ERROR: Fatal DMA error: 0x1000, 0x, 0x, 0x, 0x, 0x This is a Descriptor Protocol Error on the RX DMA engine. On which architecture are you running the card and how much RAM do you have? It seems that the descriptor ring is allocated in a memory region not accessible to the DMA engine (above 1G). Or the wrong DMA address is passed to the DMA engine, but I'd rule that out, as it works for everybody else. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43, 4306: DMA mode doesn't work
On Tuesday 05 February 2008 08:14:33 Matti Viljanen wrote: Try an x86_64 kernel. I bet it will work. Can you also try the following patch on an i386 kernel? I didn't think we would ever need to revisit this code; however, our use of the PIO fall through that hid DMA problems was too clever. Your implementation of an explicit DMA testing should be an improvement on the kernel's routine. I agree with the intent of the patch. Assuming that it fixes the problem found by Matti Viljanen, you have my ACK. BTW, b43legacy will also need a variation of the patch as the earlier BCM4306 models could have the same problem in case they get used with more than 1 GB RAM. Larry The patch works - no CPU-usage, no dmesg flooding. And 'iwlist scan' now gives proper results. I should get my WLAN AP today so I can finally test it. No b43 experience on 64-bit kernel, though... Great work. Thank you very much! Ok, one must say, however, that this patch is a tradeoff. It will reallocate all the data and move it around. Of course, that won't help your battery and stuff, as it wastes a certain amount of CPU cycles. :) But it's great that it works. Thanks for testing. Did you also test an x86_64 kernel _without_ this patch? I'd be very interested whether this works or not. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix DMA for 30/32-bit DMA engines
This checks if the DMA address is bigger than what the controller can manage.
It will reallocate the buffers in the GFP_DMA zone in that case.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a fix for 2.6.25.
Stefano, this has to be ported to b43legacy.
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c2008-01-25
00:39:08.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/dma.c 2008-02-05 12:43:42.0
+0100
@@ -334,13 +334,13 @@ static inline int txring_to_priority(str
index = ring-index;
if (B43_WARN_ON(index = ARRAY_SIZE(idx_to_prio)))
index = 0;
return idx_to_prio[index];
}
-u16 b43_dmacontroller_base(int dma64bit, int controller_idx)
+static u16 b43_dmacontroller_base(enum b43_dmatype type, int controller_idx)
{
static const u16 map64[] = {
B43_MMIO_DMA64_BASE0,
B43_MMIO_DMA64_BASE1,
B43_MMIO_DMA64_BASE2,
B43_MMIO_DMA64_BASE3,
@@ -353,13 +353,13 @@ u16 b43_dmacontroller_base(int dma64bit,
B43_MMIO_DMA32_BASE2,
B43_MMIO_DMA32_BASE3,
B43_MMIO_DMA32_BASE4,
B43_MMIO_DMA32_BASE5,
};
- if (dma64bit) {
+ if (type == B43_DMA_64BIT) {
B43_WARN_ON(!(controller_idx = 0
controller_idx ARRAY_SIZE(map64)));
return map64[controller_idx];
}
B43_WARN_ON(!(controller_idx = 0
controller_idx ARRAY_SIZE(map32)));
@@ -434,13 +434,13 @@ static int alloc_ringmemory(struct b43_d
* does not cross an 8K boundary.
*
* For unknown reasons - possibly a hardware error - the BCM4311 rev
* 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
* which accounts for the GFP_DMA flag below.
*/
- if (ring-dma64)
+ if (ring-type == B43_DMA_64BIT)
flags |= GFP_DMA;
ring-descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
(ring-dmabase), flags);
if (!ring-descbase) {
b43err(ring-dev-wl, DMA ringmemory allocation failed\n);
return -ENOMEM;
@@ -456,26 +456,28 @@ static void free_ringmemory(struct b43_d
dma_free_coherent(dev, B43_DMA_RINGMEMSIZE,
ring-descbase, ring-dmabase);
}
/* Reset the RX DMA channel */
-int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
+static int b43_dmacontroller_rx_reset(struct b43_wldev *dev, u16 mmio_base,
+ enum b43_dmatype type)
{
int i;
u32 value;
u16 offset;
might_sleep();
- offset = dma64 ? B43_DMA64_RXCTL : B43_DMA32_RXCTL;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_RXCTL : B43_DMA32_RXCTL;
b43_write32(dev, mmio_base + offset, 0);
for (i = 0; i 10; i++) {
- offset = dma64 ? B43_DMA64_RXSTATUS : B43_DMA32_RXSTATUS;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_RXSTATUS :
+ B43_DMA32_RXSTATUS;
value = b43_read32(dev, mmio_base + offset);
- if (dma64) {
+ if (type == B43_DMA_64BIT) {
value = B43_DMA64_RXSTAT;
if (value == B43_DMA64_RXSTAT_DISABLED) {
i = -1;
break;
}
} else {
@@ -493,24 +495,26 @@ int b43_dmacontroller_rx_reset(struct b4
}
return 0;
}
/* Reset the TX DMA channel */
-int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int dma64)
+static int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base,
+ enum b43_dmatype type)
{
int i;
u32 value;
u16 offset;
might_sleep();
for (i = 0; i 10; i++) {
- offset = dma64 ? B43_DMA64_TXSTATUS : B43_DMA32_TXSTATUS;
+ offset = (type == B43_DMA_64BIT) ? B43_DMA64_TXSTATUS :
+ B43_DMA32_TXSTATUS;
value = b43_read32(dev, mmio_base + offset);
- if (dma64) {
+ if (type == B43_DMA_64BIT) {
value = B43_DMA64_TXSTAT;
if (value == B43_DMA64_TXSTAT_DISABLED ||
value == B43_DMA64_TXSTAT_IDLEWAIT ||
value == B43_DMA64_TXSTAT_STOPPED)
break;
} else {
@@ -519,18 +523,19 @@ int b43_dmacontroller_tx_reset(struct b4
value == B43_DMA32_TXSTAT_IDLEWAIT
Re: [stable] [PATCH stable 1/3] b43: Fix suspend/resume
On Thursday 07 February 2008 00:14:31 Greg KH wrote: On Fri, Jan 25, 2008 at 12:11:45PM +0100, Michael Buesch wrote: This patch makes suspend/resume work with the b43 driver. We must not overwrite the MAC addresses in the init function, as this would also overwrite the MAC on resume. With an all-zero MAC the device firmware is not able to ACK any received packets anymore. Fix this by moving the initializion stuff that must be done on init but not on resume to the start function. Also zero out filter_flags to make sure we don't have some flags from a previous instance for a tiny timeframe until mac80211 reconfigures them. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- This patch is upstream inside of the netdev tree. Was this series, and the other one, for .24-stable, or .23-stable? This was for .24 stable. .23 stable didn't have the driver, yet. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix initcall ordering
On Thursday 07 February 2008 01:34:10 Aurelien Jarno wrote: Michael Buesch wrote: ssb must init after PCI but before the ssb drivers. Signed-off-by: Michael Buesch mb at bu3sch.de Cc: Christian Casteyde casteyde.christan at free.fr Fixes-bug: #9219 Unfortunately this has broken SSB_DRIVER_PCICORE. As SSB is initialized after the PCI bus, when the PCI core is initialized, it doesn't see any device. I'm not sure I understand. What's the actual problem? The PCICORE driver registers a new PCI bus, if it detects one. This is only done on MIPS. On all other architectures the PCI core is just a passive core used by the other SSB devices. The PCIcore is initialized after the PCI subsystem, but before any SSB devices. So I don't see the problem. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix initcall ordering
On Thursday 07 February 2008 10:58:23 Aurelien Jarno wrote: Michael Buesch a écrit : On Thursday 07 February 2008 01:34:10 Aurelien Jarno wrote: Michael Buesch wrote: ssb must init after PCI but before the ssb drivers. Signed-off-by: Michael Buesch mb at bu3sch.de Cc: Christian Casteyde casteyde.christan at free.fr Fixes-bug: #9219 Unfortunately this has broken SSB_DRIVER_PCICORE. As SSB is initialized after the PCI bus, when the PCI core is initialized, it doesn't see any device. I'm not sure I understand. What's the actual problem? The PCICORE driver registers a new PCI bus, if it detects one. This is only done on MIPS. On all other architectures the PCI core is just a passive core used by the other SSB devices. The PCIcore is initialized after the PCI subsystem, but before any SSB devices. So I don't see the problem. The symptom is very simple: when this commit is applied, none of the PCI devices are detected. That includes the USB 2.0 controller, which is used to plug an USB flash drive used as the root partition. So the machine fails to boot. these devices are on the PCI core? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix initcall ordering
On Thursday 07 February 2008 11:41:05 Aurelien Jarno wrote: On Thu, Feb 07, 2008 at 11:12:13AM +0100, Michael Buesch wrote: On Thursday 07 February 2008 10:58:23 Aurelien Jarno wrote: Michael Buesch a écrit : On Thursday 07 February 2008 01:34:10 Aurelien Jarno wrote: Michael Buesch wrote: ssb must init after PCI but before the ssb drivers. Signed-off-by: Michael Buesch mb at bu3sch.de Cc: Christian Casteyde casteyde.christan at free.fr Fixes-bug: #9219 Unfortunately this has broken SSB_DRIVER_PCICORE. As SSB is initialized after the PCI bus, when the PCI core is initialized, it doesn't see any device. I'm not sure I understand. What's the actual problem? The PCICORE driver registers a new PCI bus, if it detects one. This is only done on MIPS. On all other architectures the PCI core is just a passive core used by the other SSB devices. The PCIcore is initialized after the PCI subsystem, but before any SSB devices. So I don't see the problem. The symptom is very simple: when this commit is applied, none of the PCI devices are detected. That includes the USB 2.0 controller, which is used to plug an USB flash drive used as the root partition. So the machine fails to boot. these devices are on the PCI core? Yes they are. This is the output of lspci on the machine: 00:00.0 Host bridge: Broadcom Corporation BCM5365P Sentry5 Host Bridge 00:01.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) 00:02.0 USB Controller: NEC Corporation USB (rev 43) 00:02.1 USB Controller: NEC Corporation USB (rev 43) 00:02.2 USB Controller: NEC Corporation USB 2.0 (rev 04) The first one is the SSB PCI core, the others are the PCI devices. We can't easily fix this within SSB. The problem is that the MIPS PCI subsystem doesn't seem to allow registering a new bus after its initcal was run. So the bug should probably get fixed there. If you change the ssb initcall back to subsys_initcall(), it will only work by accident anyway, as PCI is subsys_initcall(), too. Reverting this patch would trade one bug for another. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 problems on ubuntu gutsy. Using 2.6.24
On Friday 08 February 2008 07:45:37 Brian Lavender wrote: I downloaded the 2.6.24 kernel onto ubuntu gutsy, compiled it, installed the firmware, but I can't seem to make a connection. The bmc43xx driver seems to work, but disconnects for some reason. I noticed that while trying to set the WEP encryption key, I kept noticing it change on me. I don't know if it was something in my Ubuntu setup that was doing it. I am trying to access a 802-11b access point and I noticed the iwconfig keeps saying 802-11g. Not sure what the problem is. Here is dmesg and iwconfig output. You are using the wrong firmware version. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with BCM4306
On Friday 08 February 2008 17:17:10 Guillaume wrote: Stefano Brivio a écrit : Sure. You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the correct firmware (version 4). Does this ring a bell? OK ; it's done and it work :-P I have made a mistake because the two diods of my card are no longer lighted... Enable LED trigger support in the kernel. If you have b43 builtin, LED triggers must also be builtin. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add driver load messages
This adds printk messages with basic information about the driver being loaded.
This information includes a summary of the compiled-in features, which
simplifies bug-reporting and debugging a lot.
Also a firmware ID is printed. This is a unique identifier blob for a specific
version of the firmware. This ID is attached to a specific version of the
firmware
blob in b43-fwcutter (see fwcutter git).
This helps users to select the right firmware for their device.
This also makes it possible to use automated scripts to fetch and extract the
right
firmware for the driver. (the script will grep the .ko for the Firmware-ID:
xxx string.
While the driver might still support other versions of the firmware for backward
compatibility, this will always print out the officially supported version,
which
people _should_ use.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this has a negative chance of introducing regressions, I'd like
to have it in 2.6.25, even if it's not strictly a bugfix.
Stefano, we should port this to legacy. See fwcutter git for the ID I assigned
to the legacy firmware blob.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2008-02-08
23:28:23.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2008-02-09 00:05:57.0
+0100
@@ -11,12 +11,18 @@
#include debugfs.h
#include leds.h
#include rfkill.h
#include lo.h
#include phy.h
+
+/* The unique identifier of the firmware that's officially supported by
+ * this driver version. */
+#define B43_SUPPORTED_FIRMWARE_ID FW13
+
+
#ifdef CONFIG_B43_DEBUG
# define B43_DEBUG 1
#else
# define B43_DEBUG 0
#endif
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-02-08
23:28:23.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-02-09
00:17:12.0 +0100
@@ -4190,23 +4190,51 @@ static struct ssb_driver b43_ssb_driver
.probe = b43_probe,
.remove = b43_remove,
.suspend= b43_suspend,
.resume = b43_resume,
};
+static void b43_print_driverinfo(void)
+{
+ const char *feat_pci = , *feat_pcmcia = , *feat_nphy = ,
+ *feat_leds = , *feat_rfkill = ;
+
+#ifdef CONFIG_B43_PCI_AUTOSELECT
+ feat_pci = P;
+#endif
+#ifdef CONFIG_B43_PCMCIA
+ feat_pcmcia = M;
+#endif
+#ifdef CONFIG_B43_NPHY
+ feat_nphy = N;
+#endif
+#ifdef CONFIG_B43_LEDS
+ feat_leds = L;
+#endif
+#ifdef CONFIG_B43_RFKILL
+ feat_rfkill = R;
+#endif
+ printk(KERN_INFO Broadcom 43xx driver loaded
+ [ Features: %s%s%s%s%s, Firmware-ID:
+ B43_SUPPORTED_FIRMWARE_ID ]\n,
+ feat_pci, feat_pcmcia, feat_nphy,
+ feat_leds, feat_rfkill);
+}
+
static int __init b43_init(void)
{
int err;
b43_debugfs_init();
err = b43_pcmcia_init();
if (err)
goto err_dfs_exit;
err = ssb_driver_register(b43_ssb_driver);
if (err)
goto err_pcmcia_exit;
+ b43_print_driverinfo();
return err;
err_pcmcia_exit:
b43_pcmcia_exit();
err_dfs_exit:
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Add driver load messages
On Saturday 09 February 2008 08:09:43 Hendrik Sattler wrote: This has the disadvantage that you have to load the driver to see that it fails, then unload it, boot a working kernel (if WLAN is the only connection method), download the right firmware, reboot the wanted kernel. This is no disadvantage. This does _NOT_ replace reading the documentation. Not at all. Basically, this is just for me when debugging. So that I immediatly see which driver version people are using. So I don't have to waste time over and over again to ask which version they use and blah blah, we know that. This would be shorter if this information can be presented in the output of 'modinfo /lib/modules/2.6.??/kernel/drivers/net/wireless/b43/b43.ko' Yes, it can _additionally_ be put into modinfo. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add firmware information to modinfo
This adds the firmware ID to modinfo. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- John, I'd also like to have this in 2.6.25, although it's not strictly a bugfix. The chance to create regressions is less than zero and it will help people to get the stuff working. Stefano poor-patch-porter Brivio, needs porting :) Index: wireless-2.6/drivers/net/wireless/b43/main.c === --- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-02-09 00:17:12.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/main.c2008-02-09 10:17:21.0 +0100 @@ -54,12 +54,14 @@ MODULE_DESCRIPTION(Broadcom B43 wireless driver); MODULE_AUTHOR(Martin Langer); MODULE_AUTHOR(Stefano Brivio); MODULE_AUTHOR(Michael Buesch); MODULE_LICENSE(GPL); +MODULE_FIRMWARE(B43_SUPPORTED_FIRMWARE_ID); + static int modparam_bad_frames_preempt; module_param_named(bad_frames_preempt, modparam_bad_frames_preempt, int, 0444); MODULE_PARM_DESC(bad_frames_preempt, enable(1) / disable(0) Bad Frames Preemption); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix bandswitch
This fixes bandswitching for the new mac80211 band API.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, for 2.6.26
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2008-02-09
00:05:57.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2008-02-09 12:04:41.0
+0100
@@ -455,20 +455,17 @@ struct b43_iv {
__be16 d16;
__be32 d32;
} data __attribute__((__packed__));
} __attribute__((__packed__));
-#define B43_PHYMODE(phytype) (1 (phytype))
-#define B43_PHYMODE_A B43_PHYMODE(B43_PHYTYPE_A)
-#define B43_PHYMODE_B B43_PHYMODE(B43_PHYTYPE_B)
-#define B43_PHYMODE_G B43_PHYMODE(B43_PHYTYPE_G)
-
struct b43_phy {
- /* Possible PHYMODEs on this PHY */
- u8 possible_phymodes;
+ /* Band support flags. */
+ bool supports_2ghz;
+ bool supports_5ghz;
+
/* GMODE bit enabled? */
bool gmode;
/* Analog Type */
u8 analog;
/* B43_PHYTYPE_ */
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-02-09
10:17:21.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-02-09
12:03:20.0 +0100
@@ -124,64 +124,149 @@ static struct ieee80211_rate __b43_ratet
#define b43_a_ratetable_size 8
#define b43_b_ratetable(__b43_ratetable + 0)
#define b43_b_ratetable_size 4
#define b43_g_ratetable(__b43_ratetable + 0)
#define b43_g_ratetable_size 12
-#define CHANTAB_ENT(_chanid, _freq) \
- { \
- .center_freq= (_freq), \
- .hw_value = (_chanid),\
- }
+#define CHAN4G(_channel, _freq, _flags) { \
+ .band = IEEE80211_BAND_2GHZ, \
+ .center_freq= (_freq), \
+ .hw_value = (_channel), \
+ .flags = (_flags), \
+ .max_antenna_gain = 0,\
+ .max_power = 30, \
+}
static struct ieee80211_channel b43_2ghz_chantable[] = {
- CHANTAB_ENT(1, 2412),
- CHANTAB_ENT(2, 2417),
- CHANTAB_ENT(3, 2422),
- CHANTAB_ENT(4, 2427),
- CHANTAB_ENT(5, 2432),
- CHANTAB_ENT(6, 2437),
- CHANTAB_ENT(7, 2442),
- CHANTAB_ENT(8, 2447),
- CHANTAB_ENT(9, 2452),
- CHANTAB_ENT(10, 2457),
- CHANTAB_ENT(11, 2462),
- CHANTAB_ENT(12, 2467),
- CHANTAB_ENT(13, 2472),
- CHANTAB_ENT(14, 2484),
+ CHAN4G(1, 2412, 0),
+ CHAN4G(2, 2417, 0),
+ CHAN4G(3, 2422, 0),
+ CHAN4G(4, 2427, 0),
+ CHAN4G(5, 2432, 0),
+ CHAN4G(6, 2437, 0),
+ CHAN4G(7, 2442, 0),
+ CHAN4G(8, 2447, 0),
+ CHAN4G(9, 2452, 0),
+ CHAN4G(10, 2457, 0),
+ CHAN4G(11, 2462, 0),
+ CHAN4G(12, 2467, 0),
+ CHAN4G(13, 2472, 0),
+ CHAN4G(14, 2484, 0),
};
+#undef CHAN4G
-#ifdef NOTYET
-static struct ieee80211_channel b43_5ghz_chantable[] = {
- CHANTAB_ENT(36, 5180),
- CHANTAB_ENT(40, 5200),
- CHANTAB_ENT(44, 5220),
- CHANTAB_ENT(48, 5240),
- CHANTAB_ENT(52, 5260),
- CHANTAB_ENT(56, 5280),
- CHANTAB_ENT(60, 5300),
- CHANTAB_ENT(64, 5320),
- CHANTAB_ENT(149, 5745),
- CHANTAB_ENT(153, 5765),
- CHANTAB_ENT(157, 5785),
- CHANTAB_ENT(161, 5805),
- CHANTAB_ENT(165, 5825),
+#define CHAN5G(_channel, _flags) { \
+ .band = IEEE80211_BAND_5GHZ, \
+ .center_freq= 5000 + (5 * (_channel)), \
+ .hw_value = (_channel), \
+ .flags = (_flags), \
+ .max_antenna_gain = 0,\
+ .max_power = 30, \
+}
+static struct ieee80211_channel b43_5ghz_nphy_chantable[] = {
+ CHAN5G(32, 0), CHAN5G(34, 0),
+ CHAN5G(36, 0), CHAN5G(38, 0),
+ CHAN5G(40, 0), CHAN5G(42, 0),
+ CHAN5G(44, 0), CHAN5G(46, 0),
+ CHAN5G(48, 0), CHAN5G(50, 0),
+ CHAN5G(52, 0), CHAN5G(54, 0),
+ CHAN5G(56, 0), CHAN5G(58, 0),
+ CHAN5G(60, 0), CHAN5G(62, 0),
+ CHAN5G(64, 0), CHAN5G(66, 0),
+ CHAN5G(68, 0), CHAN5G(70, 0),
+ CHAN5G(72, 0), CHAN5G(74, 0),
+ CHAN5G(76, 0), CHAN5G(78, 0),
+ CHAN5G(80, 0), CHAN5G(82
Re: Problem with b43 on kernel 2.6.24 (dma.c parse_cookie() generating B43_WARN_ON())
On Saturday 09 February 2008 13:13:11 Bruno Ribeiro wrote: Hello, ... You are using the wrong firmware version. Grep the list archives, please. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 problems on ubuntu gutsy. Using 2.6.24
On Saturday 09 February 2008 17:08:00 Larry Finger wrote: (3) Your udev renaming rules are F**CKED UP. The clue is that iwconfig shows wlan0-rename. In addition, as Michael said you have the wrong firmware. If Ubuntu would get their heads out of their backsides and enable debugging messages, the firmware version would be plainly visible. oh, ok. So we only print this with debugging enabled? I will submit a patch. The firmware version has really become a critical point, so it makes sense to always show the version number. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM94311MCG Rev 2 connects then drops on HP DV6605/ AMD64 X2
On Saturday 09 February 2008 15:40:15 glenn greenfield wrote: I have built and installed the compat-wireless-2.6 The installation went fine, the card comes up and even obtains an i.p. but that's where it ends. dmesg tells me that I have an old firmware version and to get the latest which I have attempted to do but I cannot extract the firmware broadcom-wl-4.150.10.5 b43-fwcutter driver/wl_apsta_mimo.o Sorry, the input file is either wrong or not supported by b43-fwcutter. This file has an unknown MD5sum cb8d70972b885b1f8883b943c0261a3c. I have attempted to extract the firmware at least 12 times on 2 different systems (both Debian) with the same results each time. I used wget to download the firmware as well as Firefox. Am I doing it incorrectly? Is it possible to download the extracted firmware someplace? fwcutter too old. People, please switch brains on before posting questions... This is really trivial to see why it fails. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 problems on ubuntu gutsy. Using 2.6.24
On Saturday 09 February 2008 17:12:02 Michael Buesch wrote: On Saturday 09 February 2008 17:08:00 Larry Finger wrote: (3) Your udev renaming rules are F**CKED UP. The clue is that iwconfig shows wlan0-rename. In addition, as Michael said you have the wrong firmware. If Ubuntu would get their heads out of their backsides and enable debugging messages, the firmware version would be plainly visible. oh, ok. So we only print this with debugging enabled? I will submit a patch. The firmware version has really become a critical point, so it makes sense to always show the version number. And, I do actually disagree that distributions should switch debugging on. We should make sure that the driver prints enough error messages in the error case, so users can see what's going wrong without enabling debugging. At least as far as external parameters like the firmware are concerned. That's actually the reason I submitted the patch to add a some driver-load message, which basically prints out the basic kconfig and required firmware for the driver. So if someone complains rfkill doesn't work and this line does not include the R, we can easily point him to a to-be-written FAQ explaining that he needs to enable it in the kernel config. I'm trying to get user noise down on this list, as it raised since we switched to b43. Mainly for firmware confusion reasons. But also because Ubuntu udev is still broken. They should really fix that. It's not only b43 which is broken because of this. So if somebody has some other idea to reduce the FAQ-noise on this list, please shout out loud. ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 problems on ubuntu gutsy. Using 2.6.24
On Saturday 09 February 2008 17:21:54 Michael Buesch wrote: does not include the R, we can easily point him to a to-be-written FAQ explaining that he needs to enable it in the kernel config. I started a FAQ. http://linuxwireless.org/en/users/Drivers/b43/faq Everybody please add things there that are frequently asked. So if somebody askes such a question here on the list, we simply answer him with a link. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix firmware load message level
The firmware version information should always get printed. Not only
on a debug build.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2008-02-09
12:03:20.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2008-02-09
17:23:11.0 +0100
@@ -1956,17 +1956,17 @@ static int b43_upload_microcode(struct b
binary drivers older than version 4.x is unsupported.
You must upgrade your firmware files.\n);
b43_print_fw_helptext(dev-wl, 1);
err = -EOPNOTSUPP;
goto error;
}
- b43dbg(dev-wl, Loading firmware version %u.%u
- (20%.2i-%.2i-%.2i %.2i:%.2i:%.2i)\n,
- fwrev, fwpatch,
- (fwdate 12) 0xF, (fwdate 8) 0xF, fwdate 0xFF,
- (fwtime 11) 0x1F, (fwtime 5) 0x3F, fwtime 0x1F);
+ b43info(dev-wl, Loading firmware version %u.%u
+ (20%.2i-%.2i-%.2i %.2i:%.2i:%.2i)\n,
+ fwrev, fwpatch,
+ (fwdate 12) 0xF, (fwdate 8) 0xF, fwdate 0xFF,
+ (fwtime 11) 0x1F, (fwtime 5) 0x3F, fwtime 0x1F);
dev-fw.rev = fwrev;
dev-fw.patch = fwpatch;
if (b43_is_old_txhdr_format(dev)) {
b43warn(dev-wl, You are using an old firmware image.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Non-functioning BCM94311MCG card on Compaq Presario V5214ea
On Sunday 10 February 2008 01:28:32 Max Eaves wrote: Dear team, Wrong firmware version. Read the list archives, please. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems with BCM4318 (Wireless LAN PCI Adapter WL-138G V2 )
On Sunday 10 February 2008 04:22:06 Pedro P wrote: Hi, My name is Javier and I'm a new in Linux. I have a problem with my wireless card Broadcom (WL-138G V2). The firmware is installed but I can't connect card. Also NetworkManager doesn't detect wireless card. Can You help me? Regards, Javier Specifications of my system: (lsmod and dmesg) - [EMAIL PROTECTED]:~ lsmod Module Size Used by nls_iso8859_1 8192 1 nls_cp437 9856 1 vfat 16128 1 fat52380 1 vfat iptable_filter 6912 0 ip_tables 16324 1 iptable_filter ip6table_filter 6784 0 ip6_tables 17476 1 ip6table_filter x_tables 18308 2 ip_tables,ip6_tables arc46016 2 ipv6 268152 20 ecb 7552 2 blkcipher 10116 1 ecb ieee80211_crypt_wep 9088 1 af_packet 29064 4 cpufreq_conservative11272 0 snd_pcm_oss50432 0 snd_mixer_oss 20096 1 snd_pcm_oss cpufreq_userspace 8704 0 snd_seq54452 0 snd_seq_device 12172 1 snd_seq cpufreq_powersave 5888 0 acpi_cpufreq 13192 0 speedstep_lib 9220 0 microcode 15372 0 apparmor 40736 0 loop 21636 0 dm_mod 56880 0 iTCO_wdt 14372 0 intel_agp 27156 0 i2c_i801 12560 0 iTCO_vendor_support 7812 1 iTCO_wdt usb_storage80780 1 parport_pc 40764 0 agpgart35764 1 intel_agp parport37832 1 parport_pc cdc_ether 9984 0 bcm43xx 419548 0 firmware_class 13568 2 microcode,bcm43xx i2c_core 27520 1 i2c_i801 rtc_cmos 12064 0 snd_hda_intel 272796 1 snd_pcm82564 2 snd_pcm_oss,snd_hda_intel snd_timer 26756 2 snd_seq,snd_pcm snd58164 9 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_pcm,snd_timer soundcore 11460 1 snd snd_page_alloc 13960 2 snd_hda_intel,snd_pcm usbnet 21768 1 cdc_ether rtc_core 23048 1 rtc_cmos sr_mod 19492 0 rtc_lib 7040 1 rtc_core cdrom 37020 1 sr_mod ieee80211softmac 34432 1 bcm43xx button 12432 0 ieee80211 35400 2 bcm43xx,ieee80211softmac ieee80211_crypt 9728 2 ieee80211_crypt_wep,ieee80211 ide_core 122948 1 usb_storage atl1 35980 0 mii 9344 2 usbnet,atl1 sg 37036 0 sd_mod 31104 5 ehci_hcd 34956 0 uhci_hcd 27024 0 usbcore 123372 6 usb_storage,cdc_ether,usbnet,ehci_hcd,uhci_hcd edd12996 0 ext3 131848 1 mbcache12292 1 ext3 jbd68148 1 ext3 fan 9220 0 ata_piix 21380 2 libata136776 1 ata_piix scsi_mod 140376 5 usb_storage,sr_mod,sg,sd_mod,libata thermal19848 0 processor 40744 2 acpi_cpufreq,thermal [EMAIL PROTECTED]:~ dmesg bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243 bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243 bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243 bcm43xx: PHY connected eth1: register 'cdc_ether' at usb-:00:1d.1-1, CDC Ethernet Device, 00:11:e3:b3:50:7a usbcore: registered new interface driver cdc_ether bcm43xx: Detected PHY: Analog: 3, Type 2, Revision 7 bcm43xx: Detected Radio: ID: 8205017f (Manuf: 17f Ver: 2050 Rev: 8) bcm43xx: Radio turned off bcm43xx: Radio turned off Linux agpgart interface v0.102 (c) Dave Jones parport_pc 00:06: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] Initializing USB Mass Storage driver... scsi4 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 4 usb-storage: waiting for device to settle before scanning iTCO_vendor_support: vendor-support=0 scsi5 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usb-storage USB Mass Storage support registered. ACPI: PCI Interrupt :00:1f.3[B] - GSI 19 (level, low) - IRQ 19 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007)
Re: Not working now. Debugging enabled
On Sunday 10 February 2008 04:31:37 Brian Lavender wrote: Booted kernel with latest firmware and then the older firmware. Debugging enabled, but not working now! See messages output. You installed the wrong firmware. (Man, I should write an answer script for this. ;) ) Second run http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 This is the right one. Install it. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Better log files . Trying to figure out b43
On Sunday 10 February 2008 21:43:48 Fernando Toledo wrote: El Dom 10 Feb 2008, Michael Buesch escribió: On Sunday 10 February 2008 09:02:27 Brian Lavender wrote: On Sat, Feb 09, 2008 at 09:07:52PM -0800, Brian Lavender wrote: At one point I had the version 3 firmware working, but now it doesn't seem to be working. I checked the log files and debugging is enabled with firmware version listed. When I was using firware version 3, I unplugged and replugged the card. Seems to be working fine now with the firmware 3. DMA seems to be ok too. You are not using a v3 firmware: [ 37.171422] b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) This is some v4 firmware. can help that the log say v3 or v4 like: vv b43-phy1 debug: Loading firmware version 351.126 [v3](2006-07-29 05:54:02) The v3 and v4 stuff is not enough to identify the right firmware, so it's worthless. I just sent patches to introduce a new unique ID for firmwares a few days ago. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Enabling CONFIG_DEBUG_SLAB breakes b43 module
On Monday 11 February 2008 13:22:14 Jörg Sommer wrote: Hi, I'm using the b43 driver to connect to a WPA2 encrypted WLAN. When I enable the kernel option CONFIG_DEBUG_SLAB my connection breaks. wpa_supplicant can establish the connection and I can make pings or DNS queries, but downloading a file kills the connection. So ehm. Disable DEBUG_SLAB? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Possible problem on b43 driver's init
On Monday 11 February 2008 03:14:57 David Cohen wrote:
On Feb 10, 2008 9:40 PM, Pavel Roskin [EMAIL PROTECTED] wrote:
On Sun, 2008-02-10 at 17:28 -0400, David Cohen wrote:
Hi all,
I'm here again reporting another possible problem with my wireless
card and b43 driver. Please don't bite me this time, I promise I'm
sending all useful inputs :D
Well, the problem is:
- After boot my laptop, the wireless card is not connected to my wifi
network. But if I just type sudo iwlist scan, then it connects.
- The same problem does not occur if I use ndiswrapper or another
laptops.
I believe it's a feature of mac80211. It only scans for APs under some
circumstances. Setting ESSID triggers scanning. I suggest that you do
it in this order:
bring the interface up
set the WEP key
set the ESSID
Hi,
I tried this, but it didn't work also.
By the way, your AP is set for shared key authentication. It delays
authentication because mac80211 tries open system first and fails.
I can wait for 5 minutes and it still doesn't authenticate.
The weird point is it does not occur with ndiswrapper or with other
linux laptop.
Even without that step, shared key authentication needs 4 packets to be
sent, rather than 2 for open system authentication. It's believed that
shared key is even less secure than open system. See e.g.
http://www.networkworld.com/research/2002/0909wepprimer.html
It's just a home network :) . But thanks anyway, it's useful to know.
Regards,
David Cohen
Can you try this patch?
Index: wireless-2.6/net/mac80211/ieee80211.c
===
--- wireless-2.6.orig/net/mac80211/ieee80211.c 2008-02-08 22:54:22.0
+0100
+++ wireless-2.6/net/mac80211/ieee80211.c 2008-02-10 14:07:23.0
+0100
@@ -172,12 +172,13 @@ static inline int identical_mac_addr_all
static int ieee80211_open(struct net_device *dev)
{
struct ieee80211_sub_if_data *sdata, *nsdata;
struct ieee80211_local *local = wdev_priv(dev-ieee80211_ptr);
struct ieee80211_if_init_conf conf;
int res;
+ bool need_hw_reconfig = 0;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
/* we hold the RTNL here so can safely walk the list */
list_for_each_entry(nsdata, local-interfaces, list) {
struct net_device *ndev = nsdata-dev;
@@ -225,13 +226,13 @@ static int ieee80211_open(struct net_dev
if (local-open_count == 0) {
res = 0;
if (local-ops-start)
res = local-ops-start(local_to_hw(local));
if (res)
return res;
- ieee80211_hw_config(local);
+ need_hw_reconfig = 1;
ieee80211_led_radio(local, local-hw.conf.radio_enabled);
}
switch (sdata-vif.type) {
case IEEE80211_IF_TYPE_VLAN:
list_add(sdata-u.vlan.list, sdata-u.vlan.ap-u.ap.vlans);
@@ -302,12 +303,14 @@ static int ieee80211_open(struct net_dev
atomic_inc(local-iff_allmultis);
if (sdata-flags IEEE80211_SDATA_PROMISC)
atomic_inc(local-iff_promiscs);
local-open_count++;
+ if (need_hw_reconfig)
+ ieee80211_hw_config(local);
netif_start_queue(dev);
return 0;
}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Help with bcm4328 revision 5
On Tuesday 12 February 2008 20:01:59 Gene Heskett wrote: On Tuesday 12 February 2008, Michael Buesch wrote: On Tuesday 12 February 2008 18:48:30 Pavel Roskin wrote: On Tue, 2008-02-12 at 14:38 -0200, Alan Carvalho de Assis wrote: Hi, I am testing kernel 2.6.25-rc1 to get my Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03) working. The device won't work. No matter what you try. If its any consolation Michael, 2.6.25-rc1 also broke the nvidia-169.09 driver too. Well, we're not talking about something being broken here. It's simply not implemented, yet. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT/RFC] b43: Add QOS support
On Tuesday 12 February 2008 22:05:42 Michael Buesch wrote: This patch adds QOS support for b43. Please comment on this and test this. This patch depends on Johannes' burst time - txop patch being _not_ applied. One can trivially fix that, though. Hm, it seems there are two other variables in SHM we should probably write: 0x000E EDCF Status Offset 0x0030 TXF Current Index The status offset is the offset of the status field in the QOS data structure for a queue? What is the TXF Current Index? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT/RFC] b43: Add QOS support
On Tuesday 12 February 2008 22:05:42 Michael Buesch wrote:
This patch adds QOS support for b43.
Please comment on this and test this.
This patch depends on Johannes' burst time - txop patch being _not_
applied.
One can trivially fix that, though.
+ for (i = 0; i ARRAY_SIZE(wl-qos_params); i++) {
+ params = (wl-qos_params[i]);
+ if (params-need_hw_update) {
+ b43_qos_params_upload(dev, (params-p),
+ qos_shm_offsets[i]);
+ params-need_hw_update = 1;
Whoopsy, needs to be:
params-need_hw_update = 0;
+ }
+ }
+
+ spin_unlock_irqrestore(wl-irq_lock, flags);
+ b43_mac_enable(dev);
+}
+/* Initialize the core's QOS capabilities */
+static void b43_qos_init(struct b43_wldev *dev)
+{
+ /* Upload the current QOS parameters. */
And here we need a loop setting all need_hw_update to 1.
+ b43_qos_update(dev);
+ /* Enable QOS support. */
+ b43_hf_write(dev, b43_hf_read(dev) | B43_HF_EDCF);
+ b43_write16(dev, B43_MMIO_IFSCTL,
+ b43_read16(dev, B43_MMIO_IFSCTL)
+ | B43_MMIO_IFSCTL_USE_EDCF);
+}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Help with bcm4328 revision 5
On Tuesday 12 February 2008 19:47:47 Alan Carvalho de Assis wrote: Why this device don't work? because support for draft-N devices is not yet implemented. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Help with bcm4328 revision 5
On Tuesday 12 February 2008 18:48:30 Pavel Roskin wrote: On Tue, 2008-02-12 at 14:38 -0200, Alan Carvalho de Assis wrote: Hi, I am testing kernel 2.6.25-rc1 to get my Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03) working. The device won't work. No matter what you try. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Enabling CONFIG_DEBUG_SLAB breakes b43 module
On Tuesday 12 February 2008 12:33:36 Jörg Sommer wrote: So ehm. Disable DEBUG_SLAB? Yes, but I thought this points to an error. Something like usage after free. No? I thought those DEBUG options are to find bugs. Well, you said it breaks down on huge throughput only, right? I'm not so surprised that it does that. We use a lot of GFP_ATOMIC and stuff in networking and wireless. So if you enable heavy slab debugging I'm not that surprised that it doesn't work as well as without it. Besides this, what should I do? :) If I had a fix, I'd submit it. If you think there's a bug nevertheless, please debug it. I can't do anything about this. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT/RFC] b43: Add QOS support
On Wednesday 13 February 2008 13:07:53 Johannes Berg wrote:
+ if (queue = ARRAY_SIZE(wl-qos_params)) {
+ /* Queue not available or don't support setting
+* params on this queue. Return success to not
+* confuse mac80211. */
+ return 0;
+ }
Is that really necessary? If so, I'll probably remove it when doing the
QoS rework, it shouldn't be, imho you should return an error if mac80211
tries to configure a queue = hw.queues.
Yep, mac80211 walks the whole queue array without looking at hw-queues.
I think this needs fixing in mac80211.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add HostFlags HI support
This adds support for the high 16 bits of the hostflags.
No functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.26.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2008-02-13
14:28:06.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2008-02-13 14:28:51.0
+0100
@@ -141,13 +141,14 @@ enum {
#define B43_SHM_SH_PCTLWDPOS 0x0008
#define B43_SHM_SH_RXPADOFF0x0034 /* RX Padding data offset (PIO
only) */
#define B43_SHM_SH_PHYVER 0x0050 /* PHY version */
#define B43_SHM_SH_PHYTYPE 0x0052 /* PHY type */
#define B43_SHM_SH_ANTSWAP 0x005C /* Antenna swap threshold */
#define B43_SHM_SH_HOSTFLO 0x005E /* Hostflags for ucode options
(low) */
-#define B43_SHM_SH_HOSTFHI 0x0060 /* Hostflags for ucode options
(high) */
+#define B43_SHM_SH_HOSTFMI 0x0060 /* Hostflags for ucode options
(middle) */
+#define B43_SHM_SH_HOSTFHI 0x0062 /* Hostflags for ucode options
(high) */
#define B43_SHM_SH_RFATT 0x0064 /* Current radio attenuation
value */
#define B43_SHM_SH_RADAR 0x0066 /* Radar register */
#define B43_SHM_SH_PHYTXNOI0x006E /* PHY noise directly after TX
(lower 8bit only) */
#define B43_SHM_SH_RFRXSP1 0x0072 /* RF RX SP Register 1 */
#define B43_SHM_SH_CHAN0x00A0 /* Current channel (low
8bit only) */
#define B43_SHM_SH_CHAN_5GHZ 0x0100 /* Bit set, if 5Ghz channel */
@@ -229,37 +230,47 @@ enum {
/* Hardware Radio Enable masks */
#define B43_MMIO_RADIO_HWENABLED_HI_MASK (1 16)
#define B43_MMIO_RADIO_HWENABLED_LO_MASK (1 4)
/* HostFlags. See b43_hf_read/write() */
-#define B43_HF_ANTDIVHELP 0x0001 /* ucode antenna div
helper */
-#define B43_HF_SYMW0x0002 /* G-PHY SYM workaround
*/
-#define B43_HF_RXPULLW 0x0004 /* RX pullup workaround
*/
-#define B43_HF_CCKBOOST0x0008 /* 4dB CCK
power boost (exclusive with OFDM boost) */
-#define B43_HF_BTCOEX 0x0010 /* Bluetooth
coexistance */
-#define B43_HF_GDCW0x0020 /* G-PHY DV canceller
filter bw workaround */
-#define B43_HF_OFDMPABOOST 0x0040 /* Enable PA gain boost
for OFDM */
-#define B43_HF_ACPR0x0080 /* Disable for Japan,
channel 14 */
-#define B43_HF_EDCF0x0100 /* on if WME and MAC
suspended */
-#define B43_HF_TSSIRPSMW 0x0200 /* TSSI reset PSM ucode
workaround */
-#define B43_HF_DSCRQ 0x0400 /* Disable slow clock
request in ucode */
-#define B43_HF_ACIW0x0800 /* ACI workaround:
shift bits by 2 on PHY CRS */
-#define B43_HF_2060W 0x1000 /* 2060 radio
workaround */
-#define B43_HF_RADARW 0x2000 /* Radar workaround */
-#define B43_HF_USEDEFKEYS 0x4000 /* Enable use of
default keys */
-#define B43_HF_BT4PRIOCOEX 0x0001 /* Bluetooth 2-priority
coexistance */
-#define B43_HF_FWKUP 0x0002 /* Fast wake-up ucode */
-#define B43_HF_VCORECALC 0x0004 /* Force VCO
recalculation when powering up synthpu */
-#define B43_HF_PCISCW 0x0008 /* PCI slow clock
workaround */
-#define B43_HF_4318TSSI0x0020 /* 4318 TSSI */
-#define B43_HF_FBCMCFIFO 0x0040 /* Flush bcast/mcast
FIFO immediately */
-#define B43_HF_HWPCTL 0x0080 /* Enable hardwarre
power control */
-#define B43_HF_BTCOEXALT 0x0100 /* Bluetooth
coexistance in alternate pins */
-#define B43_HF_TXBTCHECK 0x0200 /* Bluetooth check
during transmission */
-#define B43_HF_SKCFPUP 0x0400 /* Skip CFP update */
+#define B43_HF_ANTDIVHELP 0x0001ULL /* ucode antenna div helper */
+#define B43_HF_SYMW0x0002ULL /* G-PHY SYM workaround */
+#define B43_HF_RXPULLW 0x0004ULL /* RX pullup workaround */
+#define B43_HF_CCKBOOST0x0008ULL /* 4dB CCK power
boost (exclusive with OFDM boost) */
+#define B43_HF_BTCOEX 0x0010ULL /* Bluetooth coexistance */
+#define B43_HF_GDCW0x0020ULL /* G-PHY DC canceller filter
bw workaround */
+#define B43_HF_OFDMPABOOST 0x0040ULL /* Enable PA gain boost for
OFDM */
+#define B43_HF_ACPR0x0080ULL /* Disable for Japan, channel
14 */
+#define B43_HF_EDCF0x0100ULL /* on if WME and MAC
Re: Pb with make when trying to built b43-fwcutter-011
On Thursday 14 February 2008 16:45:31 bou.gui wrote: Hi everyone. I'm on Ubuntu hardy, with 2.6.24.7 kernel. I have a trouble when using the make command, as said in this tuto : http://linuxwireless.org/en/users/Drivers/b43 The make command return a lot of error messages. Can someone help me, please ? no, my crystal ball is broken. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Pb with make when trying to built b43-fwcutter-011
On Thursday 14 February 2008 17:11:26 bou.gui wrote: Here are some of the error message : I need all of the messages. Not just the last messages. Do this: make 2err.log and send me the err.log file. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Pb with make when trying to built b43-fwcutter-011
On Thursday 14 February 2008 17:26:52 bou.gui wrote: there it is ! fwcutter.c:33:20: error: stdlib.h: No such file or directory fwcutter.c:34:19: error: ctype.h: No such file or directory fwcutter.c:35:20: error: string.h: No such file or directory fwcutter.c:36:19: error: stdio.h: No such file or directory fwcutter.c:37:19: error: errno.h: No such file or directory fwcutter.c:38:22: error: sys/stat.h: No such file or directory fwcutter.c:39:23: error: sys/types.h: No such file or directory fwcutter.c:44:22: error: byteswap.h: No such file or directory Read a basic tutorial on how to compile things. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Wi-Fi interface intermittently missing on HP laptop
On Thursday 14 February 2008 17:37:10 Larry Finger wrote: The BCM94311 interface on my HP dv2125nr is intermittent. Twice (so far) it has gone missing and will not show up when the PCI subsystem is interrogated using lspci. It is hardware because Windows doesn't find it either. I remember seeing reports of this problem on mailing lists. If your computer has suffered from this error, please let me know what it took to fix it. I suspect a motherboard problem, and would like to know other's experiences when I try to get mine fixed under warranty. some broadcom chips have problems with some PCI signals. I also saw stuff like that. Usually pulling and putting back the card helps. I have a b44 card which doesn't work in a PCI extender, because of some signal sensing being too low. The additional 10cm of wire added by the extender will make it fail then. This also depends on the motherboard's signal strength. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
