[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
[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: 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
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 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
[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
[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
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] 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 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 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
[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
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 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
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
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
[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
[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: 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] 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: Remove PIO support
Remove b43 PIO support.
DMA works well on all supported devices. There's no reason to use PIO.
Additionally, new devices don't support PIO in hardware anymore.
b43 PIO support is dead and unused code.
After applying this patch please do
git rm drivers/net/wireless/b43/pio.h
git rm drivers/net/wireless/b43/pio.c
to remove the main PIO support code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===
--- wireless-2.6.orig/drivers/net/wireless/b43/Kconfig 2007-12-26
14:31:03.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/Kconfig 2007-12-26
14:32:49.0 +0100
@@ -83,51 +83,3 @@ config B43_DEBUG
Say Y, if you want to find out why the driver does not
work for you.
-
-config B43_DMA
- bool
- depends on B43
-config B43_PIO
- bool
- depends on B43
-
-choice
- prompt Broadcom 43xx data transfer mode
- depends on B43
- default B43_DMA_AND_PIO_MODE
-
-config B43_DMA_AND_PIO_MODE
- bool DMA + PIO
- select B43_DMA
- select B43_PIO
- ---help---
- Include both, Direct Memory Access (DMA) and Programmed I/O (PIO)
- data transfer modes.
- The actually used mode is selectable through the module
- parameter pio. If the module parameter is pio=0, DMA is used.
- Otherwise PIO is used. DMA is default.
-
- If unsure, choose this option.
-
-config B43_DMA_MODE
- bool DMA (Direct Memory Access) only
- select B43_DMA
- ---help---
- Only include Direct Memory Access (DMA).
- This reduces the size of the driver module, by omitting the PIO code.
-
-config B43_PIO_MODE
- bool PIO (Programmed I/O) only
- select B43_PIO
- ---help---
- Only include Programmed I/O (PIO).
- This reduces the size of the driver module, by omitting the DMA code.
- Please note that PIO transfers are slow (compared to DMA).
-
- Also note that not all devices of the 43xx series support PIO.
- The 4306 (Apple Airport Extreme and others) supports PIO, while
- the 4318 is known to _not_ support PIO.
-
- Only use PIO, if DMA does not work for you.
-
-endchoice
Index: wireless-2.6/drivers/net/wireless/b43/Makefile
===
--- wireless-2.6.orig/drivers/net/wireless/b43/Makefile 2007-12-26
14:31:03.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/Makefile 2007-12-26
14:33:36.0 +0100
@@ -1,4 +1,3 @@
-# b43 core
b43-y += main.o
b43-y += tables.o
b43-y += phy.o
@@ -6,16 +5,10 @@ b43-y += sysfs.o
b43-y += xmit.o
b43-y += lo.o
b43-y += wa.o
-# b43 RFKILL button support
+b43-y += dma.o
b43-$(CONFIG_B43_RFKILL) += rfkill.o
-# b43 LED support
b43-$(CONFIG_B43_LEDS) += leds.o
-# b43 PCMCIA support
b43-$(CONFIG_B43_PCMCIA) += pcmcia.o
-# b43 debugging
b43-$(CONFIG_B43_DEBUG)+= debugfs.o
-# b43 DMA and PIO
-b43-$(CONFIG_B43_DMA) += dma.o
-b43-$(CONFIG_B43_PIO) += pio.o
obj-$(CONFIG_B43) += b43.o
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2007-12-26
14:31:03.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2007-12-26 14:32:49.0
+0100
@@ -68,11 +68,6 @@
#define B43_MMIO_DMA64_BASE3 0x2C0
#define B43_MMIO_DMA64_BASE4 0x300
#define B43_MMIO_DMA64_BASE5 0x340
-/* PIO */
-#define B43_MMIO_PIO1_BASE 0x300
-#define B43_MMIO_PIO2_BASE 0x310
-#define B43_MMIO_PIO3_BASE 0x320
-#define B43_MMIO_PIO4_BASE 0x330
#define B43_MMIO_PHY_VER 0x3E0
#define B43_MMIO_PHY_RADIO 0x3E2
@@ -577,14 +572,6 @@ struct b43_dma {
struct b43_dmaring *rx_ring3; /* only available on core.rev 5 */
};
-/* Data structures for PIO transmission, per 80211 core. */
-struct b43_pio {
- struct b43_pioqueue *queue0;
- struct b43_pioqueue *queue1;
- struct b43_pioqueue *queue2;
- struct b43_pioqueue *queue3;
-};
-
/* Context information for a noise calculation (Link Quality). */
struct b43_noise_calculation {
u8 channel_at_start;
@@ -700,7 +687,6 @@ struct b43_wldev {
/* Saved init status for handling suspend. */
int suspend_init_status;
- bool __using_pio; /* Internal, use b43_using_pio(). */
bool bad_frames_preempt;/* Use Bad Frames Preemption (default
off) */
bool reg124_set_0x4;/* Some variable to keep track of IRQ
[PATCH, RFT] b43: Fix wakeup times
Fix writing of some wakeup times. The MMIO write does not change in functionality. But I think the SHM writes are wrong. I think they are the old v3 firmware API. It seems that this stuff moved in the v4 firmware API. I guess that the old 0x416 offset is the PRETBTT offset in the new API. That would make most sense to me. (We first write the PRETBTT MMIO register and then a SHM location with the same value. So it would make sense so me if this was the PRETBTT location). The use of the new SH_SPUWKUP is also only a guess by me. It is SH_PRETBTT-2. But this seems to make some sense to me. Johannes, Joseph: Does this patch make sense? Can you probably check what a recent vendor driver does? Everybody, please test this patch for regressions. NOT-signed-off-yet Index: wireless-2.6/drivers/net/wireless/b43/b43.h === --- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2007-12-26 14:32:49.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/b43.h 2007-12-26 15:24:53.0 +0100 @@ -88,6 +88,7 @@ #define B43_MMIO_GPIO_MASK 0x49E #define B43_MMIO_TSF_CFP_START_LOW 0x604 #define B43_MMIO_TSF_CFP_START_HIGH0x606 +#define B43_MMIO_TSF_CFP_PRETBTT 0x612 #define B43_MMIO_TSF_0 0x632 /* core rev 3 only */ #define B43_MMIO_TSF_1 0x634 /* core rev 3 only */ #define B43_MMIO_TSF_2 0x636 /* core rev 3 only */ Index: wireless-2.6/drivers/net/wireless/b43/main.c === --- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-26 14:32:49.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-26 15:33:22.0 +0100 @@ -3376,12 +3376,11 @@ static int b43_wireless_core_init(struct goto err_chip_exit; b43_qos_init(dev); -//FIXME -#if 1 - b43_write16(dev, 0x0612, 0x0050); - b43_shm_write16(dev, B43_SHM_SHARED, 0x0416, 0x0050); - b43_shm_write16(dev, B43_SHM_SHARED, 0x0414, 0x01F4); -#endif + /* Set the TSF CFP pre-TargetBeaconTransmissionTime (in microseconds). */ + b43_write16(dev, B43_MMIO_TSF_CFP_PRETBTT, 80); + b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_PRETBTT, 80); + /* 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); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Add definitions for MAC Control register
This adds some definitions for the MAC Control register
and uses them.
This basically is no functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this can probably be applied for 2.6.25. I don't care much.
This is some pre-work to get to get AP and IBSS working better, which
won't happen earlier than 2.6.25 anyway.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2007-12-26
15:24:53.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2007-12-26 16:04:13.0
+0100
@@ -35,8 +35,8 @@
#define B43_MMIO_DMA4_IRQ_MASK 0x44
#define B43_MMIO_DMA5_REASON 0x48
#define B43_MMIO_DMA5_IRQ_MASK 0x4C
-#define B43_MMIO_MACCTL0x120
-#define B43_MMIO_STATUS2_BITFIELD 0x124
+#define B43_MMIO_MACCTL0x120 /* MAC control */
+#define B43_MMIO_MACCMD0x124 /* MAC command */
#define B43_MMIO_GEN_IRQ_REASON0x128
#define B43_MMIO_GEN_IRQ_MASK 0x12C
#define B43_MMIO_RAM_CONTROL 0x130
@@ -320,6 +320,13 @@ enum {
#define B43_MACCTL_DISCPMQ 0x4000 /* Discard Power
Management Queue */
#define B43_MACCTL_GMODE 0x8000 /* G Mode */
+/* MAC Command bitfield */
+#define B43_MACCMD_BEACON0_VALID 0x0001 /* Beacon 0 in template
RAM is busy/valid */
+#define B43_MACCMD_BEACON1_VALID 0x0002 /* Beacon 1 in template
RAM is busy/valid */
+#define B43_MACCMD_DFQ_VALID 0x0004 /* Directed frame queue
valid (IBSS PS mode, ATIM) */
+#define B43_MACCMD_CCA 0x0008 /* Clear channel
assessment */
+#define B43_MACCMD_BGNOISE 0x0010 /* Background noise */
+
/* 802.11 core specific TM State Low flags */
#define B43_TMSLOW_GMODE 0x2000 /* G Mode Enable */
#define B43_TMSLOW_PLLREFSEL 0x0020 /* PLL Frequency
Reference Select */
@@ -689,6 +696,7 @@ struct b43_wldev {
int suspend_init_status;
bool bad_frames_preempt;/* Use Bad Frames Preemption (default
off) */
+ bool dfq_valid; /* Directed frame queue valid (IBSS PS mode,
ATIM) */
bool reg124_set_0x4;/* Some variable to keep track of IRQ stuff. */
bool short_preamble;/* TRUE, if short preamble is enabled. */
bool short_slot;/* TRUE, if short slot timing is enabled. */
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-26
15:33:22.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-26
16:09:05.0 +0100
@@ -993,9 +993,8 @@ static void b43_jssi_write(struct b43_wl
static void b43_generate_noise_sample(struct b43_wldev *dev)
{
b43_jssi_write(dev, 0x7F7F7F7F);
- b43_write32(dev, B43_MMIO_STATUS2_BITFIELD,
- b43_read32(dev, B43_MMIO_STATUS2_BITFIELD)
- | (1 4));
+ b43_write32(dev, B43_MMIO_MACCMD,
+ b43_read32(dev, B43_MMIO_MACCMD) | B43_MACCMD_BGNOISE);
B43_WARN_ON(dev-noisecalc.channel_at_start != dev-phy.channel);
}
@@ -1081,18 +1080,18 @@ static void handle_irq_tbtt_indication(s
if (1 /*FIXME: the last PSpoll frame was sent successfully */ )
b43_power_saving_ctl_bits(dev, 0);
}
- dev-reg124_set_0x4 = 0;
if (b43_is_mode(dev-wl, IEEE80211_IF_TYPE_IBSS))
- dev-reg124_set_0x4 = 1;
+ dev-dfq_valid = 1;
}
static void handle_irq_atim_end(struct b43_wldev *dev)
{
- if (!dev-reg124_set_0x4 /*FIXME rename this variable */ )
- return;
- b43_write32(dev, B43_MMIO_STATUS2_BITFIELD,
- b43_read32(dev, B43_MMIO_STATUS2_BITFIELD)
- | 0x4);
+ if (dev-dfq_valid) {
+ b43_write32(dev, B43_MMIO_MACCMD,
+ b43_read32(dev, B43_MMIO_MACCMD)
+ | B43_MACCMD_DFQ_VALID);
+ dev-dfq_valid = 0;
+ }
}
static void handle_irq_pmq(struct b43_wldev *dev)
@@ -1271,7 +1270,7 @@ static int b43_refresh_cached_beacon(str
static void b43_update_templates(struct b43_wldev *dev)
{
- u32 status;
+ u32 cmd;
B43_WARN_ON(!dev-cached_beacon);
@@ -1279,9 +1278,9 @@ static void b43_update_templates(struct
b43_write_beacon_template(dev, 0x468, 0x1A, B43_CCK_RATE_1MB);
b43_write_probe_resp_template(dev, 0x268, 0x4A, B43_CCK_RATE_11MB);
- status = b43_read32(dev, B43_MMIO_STATUS2_BITFIELD);
- status |= 0x03;
- b43_write32(dev, B43_MMIO_STATUS2_BITFIELD, status);
+ cmd = b43_read32(dev, B43_MMIO_MACCMD);
+ cmd
[PATCH v2] b43: Add definitions for MAC Control register
This adds some definitions for the MAC Control register
and uses them.
This basically is no functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is patch version 2.
Forgot to run a quilt refresh. Sorry.
John, this can probably be applied for 2.6.25. I don't care much.
This is some pre-work to get to get AP and IBSS working better, which
won't happen earlier than 2.6.25 anyway.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2007-12-26
15:24:53.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2007-12-26 16:12:38.0
+0100
@@ -35,8 +35,8 @@
#define B43_MMIO_DMA4_IRQ_MASK 0x44
#define B43_MMIO_DMA5_REASON 0x48
#define B43_MMIO_DMA5_IRQ_MASK 0x4C
-#define B43_MMIO_MACCTL0x120
-#define B43_MMIO_STATUS2_BITFIELD 0x124
+#define B43_MMIO_MACCTL0x120 /* MAC control */
+#define B43_MMIO_MACCMD0x124 /* MAC command */
#define B43_MMIO_GEN_IRQ_REASON0x128
#define B43_MMIO_GEN_IRQ_MASK 0x12C
#define B43_MMIO_RAM_CONTROL 0x130
@@ -320,6 +320,13 @@ enum {
#define B43_MACCTL_DISCPMQ 0x4000 /* Discard Power
Management Queue */
#define B43_MACCTL_GMODE 0x8000 /* G Mode */
+/* MAC Command bitfield */
+#define B43_MACCMD_BEACON0_VALID 0x0001 /* Beacon 0 in template
RAM is busy/valid */
+#define B43_MACCMD_BEACON1_VALID 0x0002 /* Beacon 1 in template
RAM is busy/valid */
+#define B43_MACCMD_DFQ_VALID 0x0004 /* Directed frame queue
valid (IBSS PS mode, ATIM) */
+#define B43_MACCMD_CCA 0x0008 /* Clear channel
assessment */
+#define B43_MACCMD_BGNOISE 0x0010 /* Background noise */
+
/* 802.11 core specific TM State Low flags */
#define B43_TMSLOW_GMODE 0x2000 /* G Mode Enable */
#define B43_TMSLOW_PLLREFSEL 0x0020 /* PLL Frequency
Reference Select */
@@ -689,7 +696,7 @@ struct b43_wldev {
int suspend_init_status;
bool bad_frames_preempt;/* Use Bad Frames Preemption (default
off) */
- bool reg124_set_0x4;/* Some variable to keep track of IRQ stuff. */
+ bool dfq_valid; /* Directed frame queue valid (IBSS PS mode,
ATIM) */
bool short_preamble;/* TRUE, if short preamble is enabled. */
bool short_slot;/* TRUE, if short slot timing is enabled. */
bool radio_hw_enable; /* saved state of radio hardware enabled state
*/
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-26
15:33:22.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-26
16:09:05.0 +0100
@@ -993,9 +993,8 @@ static void b43_jssi_write(struct b43_wl
static void b43_generate_noise_sample(struct b43_wldev *dev)
{
b43_jssi_write(dev, 0x7F7F7F7F);
- b43_write32(dev, B43_MMIO_STATUS2_BITFIELD,
- b43_read32(dev, B43_MMIO_STATUS2_BITFIELD)
- | (1 4));
+ b43_write32(dev, B43_MMIO_MACCMD,
+ b43_read32(dev, B43_MMIO_MACCMD) | B43_MACCMD_BGNOISE);
B43_WARN_ON(dev-noisecalc.channel_at_start != dev-phy.channel);
}
@@ -1081,18 +1080,18 @@ static void handle_irq_tbtt_indication(s
if (1 /*FIXME: the last PSpoll frame was sent successfully */ )
b43_power_saving_ctl_bits(dev, 0);
}
- dev-reg124_set_0x4 = 0;
if (b43_is_mode(dev-wl, IEEE80211_IF_TYPE_IBSS))
- dev-reg124_set_0x4 = 1;
+ dev-dfq_valid = 1;
}
static void handle_irq_atim_end(struct b43_wldev *dev)
{
- if (!dev-reg124_set_0x4 /*FIXME rename this variable */ )
- return;
- b43_write32(dev, B43_MMIO_STATUS2_BITFIELD,
- b43_read32(dev, B43_MMIO_STATUS2_BITFIELD)
- | 0x4);
+ if (dev-dfq_valid) {
+ b43_write32(dev, B43_MMIO_MACCMD,
+ b43_read32(dev, B43_MMIO_MACCMD)
+ | B43_MACCMD_DFQ_VALID);
+ dev-dfq_valid = 0;
+ }
}
static void handle_irq_pmq(struct b43_wldev *dev)
@@ -1271,7 +1270,7 @@ static int b43_refresh_cached_beacon(str
static void b43_update_templates(struct b43_wldev *dev)
{
- u32 status;
+ u32 cmd;
B43_WARN_ON(!dev-cached_beacon);
@@ -1279,9 +1278,9 @@ static void b43_update_templates(struct
b43_write_beacon_template(dev, 0x468, 0x1A, B43_CCK_RATE_1MB);
b43_write_probe_resp_template(dev, 0x268, 0x4A, B43_CCK_RATE_11MB);
- status = b43_read32(dev, B43_MMIO_STATUS2_BITFIELD
[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
Re: [PATCH] ssb: Fix extraction of values from SPROM
On Sunday 23 December 2007 13:36:31 Shourya Sarcar wrote: Michael Buesch wrote: This fixes extraction of some values from the SPROM. It mainly fixes extraction of antenna related values, which is needed for another b43 fix sent later. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-2.6/drivers/ssb/pci.c === --- wireless-2.6.orig/drivers/ssb/pci.c 2007-12-14 13:15:42.0 +0100 +++ wireless-2.6/drivers/ssb/pci.c 2007-12-20 18:58:49.0 +0100 Will these patches that you posted today work against the 2.6.24-rc5 kernel or do I need to have a separate branch (wireless-2.6 ?) to test these. I am not sure if I will add much value but I would be happy to test these on my machine. (Dell D620 with a BCM94311MCG) New on this list, so sorry if I am asking questions that are obvious or the info is published elsewhere. All patches I send are against the wireless-2.6 tree branch #everything. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Boot time module loading problem
On Sunday 23 December 2007 20:39:18 Larry Finger wrote: With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module, which should be loaded by the ssb module, fails with the following type of message: ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 b43: disagrees about version of symbol ssb_device_is_enabled b43: Unknown symbol ssb_device_is_enabled b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable b43: disagrees about version of symbol ssb_bus_may_powerdown b43: Unknown symbol ssb_bus_may_powerdown This is a module versioning warning. I think it's caused by a b43 compiled against a different kernel tree than the currently running ssb module. Different may mean that only a tiny little thing was changed, which might not affect the API at all. modversion will complain then. I don't use module versioning, so I can't help you how to fix this. I'd simply suggest turning off module versioning. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Fix extraction of values from SPROM
This fixes extraction of some values from the SPROM.
It mainly fixes extraction of antenna related values, which
is needed for another b43 fix sent later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/ssb/pci.c
===
--- wireless-2.6.orig/drivers/ssb/pci.c 2007-12-14 13:15:42.0 +0100
+++ wireless-2.6/drivers/ssb/pci.c 2007-12-20 18:58:49.0 +0100
@@ -247,7 +247,7 @@ static void sprom_do_read(struct ssb_bus
int i;
for (i = 0; i bus-sprom_size; i++)
- sprom[i] = readw(bus-mmio + SSB_SPROM_BASE + (i * 2));
+ sprom[i] = ioread16(bus-mmio + SSB_SPROM_BASE + (i * 2));
}
static int sprom_do_write(struct ssb_bus *bus, const u16 *sprom)
@@ -297,10 +297,32 @@ err_ctlreg:
return err;
}
+static s8 r123_extract_antgain(u8 sprom_revision, const u16 *in,
+ u16 mask, u16 shift)
+{
+ u16 v;
+ u8 gain;
+
+ v = in[SPOFF(SSB_SPROM1_AGAIN)];
+ gain = (v mask) shift;
+ if (gain == 0xFF)
+ gain = 2; /* If unset use 2dBm */
+ if (sprom_revision == 1) {
+ /* Convert to Q5.2 */
+ gain = 2;
+ } else {
+ /* Q5.2 Fractional part is stored in 0xC0 */
+ gain = ((gain 0xC0) 6) | ((gain 0x3F) 2);
+ }
+
+ return (s8)gain;
+}
+
static void sprom_extract_r123(struct ssb_sprom *out, const u16 *in)
{
int i;
u16 v;
+ s8 gain;
u16 loc[3];
if (out-revision == 3) { /* rev 3 moved MAC */
@@ -327,8 +349,15 @@ static void sprom_extract_r123(struct ss
SPEX(et0phyaddr, SSB_SPROM1_ETHPHY, SSB_SPROM1_ETHPHY_ET0A, 0);
SPEX(et1phyaddr, SSB_SPROM1_ETHPHY, SSB_SPROM1_ETHPHY_ET1A,
SSB_SPROM1_ETHPHY_ET1A_SHIFT);
+ SPEX(et0mdcport, SSB_SPROM1_ETHPHY, SSB_SPROM1_ETHPHY_ET0M, 14);
+ SPEX(et1mdcport, SSB_SPROM1_ETHPHY, SSB_SPROM1_ETHPHY_ET1M, 15);
+ SPEX(board_rev, SSB_SPROM1_BINF, SSB_SPROM1_BINF_BREV, 0);
SPEX(country_code, SSB_SPROM1_BINF, SSB_SPROM1_BINF_CCODE,
SSB_SPROM1_BINF_CCODE_SHIFT);
+ SPEX(ant_available_a, SSB_SPROM1_BINF, SSB_SPROM1_BINF_ANTA,
+SSB_SPROM1_BINF_ANTA_SHIFT);
+ SPEX(ant_available_bg, SSB_SPROM1_BINF, SSB_SPROM1_BINF_ANTBG,
+SSB_SPROM1_BINF_ANTBG_SHIFT);
SPEX(pa0b0, SSB_SPROM1_PA0B0, 0x, 0);
SPEX(pa0b1, SSB_SPROM1_PA0B1, 0x, 0);
SPEX(pa0b2, SSB_SPROM1_PA0B2, 0x, 0);
@@ -348,9 +377,22 @@ static void sprom_extract_r123(struct ss
SSB_SPROM1_ITSSI_A_SHIFT);
SPEX(itssi_bg, SSB_SPROM1_ITSSI, SSB_SPROM1_ITSSI_BG, 0);
SPEX(boardflags_lo, SSB_SPROM1_BFLLO, 0x, 0);
- SPEX(antenna_gain_a, SSB_SPROM1_AGAIN, SSB_SPROM1_AGAIN_A, 0);
- SPEX(antenna_gain_bg, SSB_SPROM1_AGAIN, SSB_SPROM1_AGAIN_BG,
-SSB_SPROM1_AGAIN_BG_SHIFT);
+
+ /* 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;
+ out-antenna_gain.ghz24.a1 = gain;
+ out-antenna_gain.ghz24.a2 = gain;
+ out-antenna_gain.ghz24.a3 = gain;
+ gain = r123_extract_antgain(out-revision, in,
+ SSB_SPROM1_AGAIN_A,
+ SSB_SPROM1_AGAIN_A_SHIFT);
+ out-antenna_gain.ghz5.a0 = gain;
+ out-antenna_gain.ghz5.a1 = gain;
+ out-antenna_gain.ghz5.a2 = gain;
+ out-antenna_gain.ghz5.a3 = gain;
}
static void sprom_extract_r4(struct ssb_sprom *out, const u16 *in)
@@ -376,9 +418,10 @@ static void sprom_extract_r4(struct ssb_
SSB_SPROM4_ETHPHY_ET1A_SHIFT);
SPEX(country_code, SSB_SPROM4_CCODE, 0x, 0);
SPEX(boardflags_lo, SSB_SPROM4_BFLLO, 0x, 0);
- SPEX(antenna_gain_a, SSB_SPROM4_AGAIN, SSB_SPROM4_AGAIN_0, 0);
- SPEX(antenna_gain_bg, SSB_SPROM4_AGAIN, SSB_SPROM4_AGAIN_1,
-SSB_SPROM4_AGAIN_1_SHIFT);
+ 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,
SSB_SPROM4_ITSSI_BG_SHIFT);
@@ -391,6 +434,19 @@ static void sprom_extract_r4(struct ssb_
SPEX(gpio2, SSB_SPROM4_GPIOB, SSB_SPROM4_GPIOB_P2, 0);
SPEX(gpio3, SSB_SPROM4_GPIOB, SSB_SPROM4_GPIOB_P3,
SSB_SPROM4_GPIOB_P3_SHIFT);
+
+ /* Extract the antenna gain values. */
+ SPEX(antenna_gain.ghz24.a0, SSB_SPROM4_AGAIN01,
+SSB_SPROM4_AGAIN0
[PATCH] b43: Fix chip access validation for new devices
This fixes chip access validation for newer devices
(4318 and up, I think)
This patch fixes probing of a PCMCIA based 4318 device.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43.h2007-12-12
19:54:27.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2007-12-12 19:55:57.0
+0100
@@ -50,6 +50,9 @@
#define B43_MMIO_XMITSTAT_10x174
#define B43_MMIO_REV3PLUS_TSF_LOW 0x180 /* core rev = 3 only */
#define B43_MMIO_REV3PLUS_TSF_HIGH 0x184 /* core rev = 3 only */
+#define B43_MMIO_TSF_CFP_REP 0x188
+#define B43_MMIO_TSF_CFP_START 0x18C
+#define B43_MMIO_TSF_CFP_MAXDUR0x190
/* 32-bit DMA */
#define B43_MMIO_DMA32_BASE0 0x200
@@ -88,6 +91,8 @@
#define B43_MMIO_RADIO_HWENABLED_LO0x49A
#define B43_MMIO_GPIO_CONTROL 0x49C
#define B43_MMIO_GPIO_MASK 0x49E
+#define B43_MMIO_TSF_CFP_START_LOW 0x604
+#define B43_MMIO_TSF_CFP_START_HIGH0x606
#define B43_MMIO_TSF_0 0x632 /* core rev 3 only */
#define B43_MMIO_TSF_1 0x634 /* core rev 3 only */
#define B43_MMIO_TSF_2 0x636 /* core rev 3 only */
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-12
19:55:53.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-12
19:55:57.0 +0100
@@ -2408,32 +2408,42 @@ static void b43_periodic_tasks_setup(str
queue_delayed_work(dev-wl-hw-workqueue, work, 0);
}
-/* Validate access to the chip (SHM) */
+/* Check if communication with the device works correctly. */
static int b43_validate_chipaccess(struct b43_wldev *dev)
{
- u32 value;
- u32 shm_backup;
+ u32 v, backup;
- shm_backup = b43_shm_read32(dev, B43_SHM_SHARED, 0);
- b43_shm_write32(dev, B43_SHM_SHARED, 0, 0xAAAA);
- if (b43_shm_read32(dev, B43_SHM_SHARED, 0) != 0xAAAA)
- goto error;
+ backup = b43_shm_read32(dev, B43_SHM_SHARED, 0);
+
+ /* Check for read/write and endianness problems. */
b43_shm_write32(dev, B43_SHM_SHARED, 0, 0x5555);
if (b43_shm_read32(dev, B43_SHM_SHARED, 0) != 0x5555)
goto error;
- b43_shm_write32(dev, B43_SHM_SHARED, 0, shm_backup);
-
- value = b43_read32(dev, B43_MMIO_MACCTL);
- if ((value | B43_MACCTL_GMODE) !=
- (B43_MACCTL_GMODE | B43_MACCTL_IHR_ENABLED))
+ b43_shm_write32(dev, B43_SHM_SHARED, 0, 0xAAAA);
+ if (b43_shm_read32(dev, B43_SHM_SHARED, 0) != 0xAAAA)
goto error;
- value = b43_read32(dev, B43_MMIO_GEN_IRQ_REASON);
- if (value)
+ b43_shm_write32(dev, B43_SHM_SHARED, 0, backup);
+
+ if ((dev-dev-id.revision = 3) (dev-dev-id.revision = 10)) {
+ /* The 32bit register shadows the two 16bit registers
+* with update sideeffects. Validate this. */
+ b43_write16(dev, B43_MMIO_TSF_CFP_START, 0x);
+ b43_write32(dev, B43_MMIO_TSF_CFP_START, 0x);
+ if (b43_read16(dev, B43_MMIO_TSF_CFP_START_LOW) != 0x)
+ goto error;
+ if (b43_read16(dev, B43_MMIO_TSF_CFP_START_HIGH) != 0x)
+ goto error;
+ }
+ b43_write32(dev, B43_MMIO_TSF_CFP_START, 0);
+
+ v = b43_read32(dev, B43_MMIO_MACCTL);
+ v |= B43_MACCTL_GMODE;
+ if (v != (B43_MACCTL_GMODE | B43_MACCTL_IHR_ENABLED))
goto error;
return 0;
- error:
+error:
b43err(dev-wl, Failed to validate the chipaccess\n);
return -ENODEV;
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Fix PCMCIA lowlevel register access
This fixes lowlevel register access for PCMCIA based devices.
The patch also adds a temporary workaround for the device mac address.
It simply adds generation of a random address. The real SPROM extraction
will follow in another patch.
The temporary workaround will be removed then, but for now it's OK.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/ssb/pcmcia.c
===
--- wireless-2.6.orig/drivers/ssb/pcmcia.c 2007-12-09 21:33:20.0
+0100
+++ wireless-2.6/drivers/ssb/pcmcia.c 2007-12-09 22:16:59.0 +0100
@@ -94,7 +94,6 @@ int ssb_pcmcia_switch_core(struct ssb_bu
struct ssb_device *dev)
{
int err;
- unsigned long flags;
#if SSB_VERBOSE_PCMCIACORESWITCH_DEBUG
ssb_printk(KERN_INFO PFX
@@ -103,11 +102,9 @@ int ssb_pcmcia_switch_core(struct ssb_bu
dev-core_index);
#endif
- spin_lock_irqsave(bus-bar_lock, flags);
err = ssb_pcmcia_switch_coreidx(bus, dev-core_index);
if (!err)
bus-mapped_device = dev;
- spin_unlock_irqrestore(bus-bar_lock, flags);
return err;
}
@@ -115,14 +112,12 @@ int ssb_pcmcia_switch_core(struct ssb_bu
int ssb_pcmcia_switch_segment(struct ssb_bus *bus, u8 seg)
{
int attempts = 0;
- unsigned long flags;
conf_reg_t reg;
- int res, err = 0;
+ int res;
SSB_WARN_ON((seg != 0) (seg != 1));
reg.Offset = 0x34;
reg.Function = 0;
- spin_lock_irqsave(bus-bar_lock, flags);
while (1) {
reg.Action = CS_WRITE;
reg.Value = seg;
@@ -143,13 +138,11 @@ int ssb_pcmcia_switch_segment(struct ssb
udelay(10);
}
bus-mapped_pcmcia_seg = seg;
-out_unlock:
- spin_unlock_irqrestore(bus-bar_lock, flags);
- return err;
+
+ return 0;
error:
ssb_printk(KERN_ERR PFX Failed to switch pcmcia segment\n);
- err = -ENODEV;
- goto out_unlock;
+ return -ENODEV;
}
static int select_core_and_segment(struct ssb_device *dev,
@@ -182,22 +175,33 @@ static int select_core_and_segment(struc
static u16 ssb_pcmcia_read16(struct ssb_device *dev, u16 offset)
{
struct ssb_bus *bus = dev-bus;
+ unsigned long flags;
+ int err;
+ u16 value = 0x;
- if (unlikely(select_core_and_segment(dev, offset)))
- return 0x;
+ spin_lock_irqsave(bus-bar_lock, flags);
+ err = select_core_and_segment(dev, offset);
+ if (likely(!err))
+ value = readw(bus-mmio + offset);
+ spin_unlock_irqrestore(bus-bar_lock, flags);
- return readw(bus-mmio + offset);
+ return value;
}
static u32 ssb_pcmcia_read32(struct ssb_device *dev, u16 offset)
{
struct ssb_bus *bus = dev-bus;
- u32 lo, hi;
+ unsigned long flags;
+ int err;
+ u32 lo = 0x, hi = 0x;
- if (unlikely(select_core_and_segment(dev, offset)))
- return 0x;
- lo = readw(bus-mmio + offset);
- hi = readw(bus-mmio + offset + 2);
+ spin_lock_irqsave(bus-bar_lock, flags);
+ err = select_core_and_segment(dev, offset);
+ if (likely(!err)) {
+ lo = readw(bus-mmio + offset);
+ hi = readw(bus-mmio + offset + 2);
+ }
+ spin_unlock_irqrestore(bus-bar_lock, flags);
return (lo | (hi 16));
}
@@ -205,22 +209,31 @@ static u32 ssb_pcmcia_read32(struct ssb_
static void ssb_pcmcia_write16(struct ssb_device *dev, u16 offset, u16 value)
{
struct ssb_bus *bus = dev-bus;
+ unsigned long flags;
+ int err;
- if (unlikely(select_core_and_segment(dev, offset)))
- return;
- writew(value, bus-mmio + offset);
+ spin_lock_irqsave(bus-bar_lock, flags);
+ err = select_core_and_segment(dev, offset);
+ if (likely(!err))
+ writew(value, bus-mmio + offset);
+ mmiowb();
+ spin_unlock_irqrestore(bus-bar_lock, flags);
}
static void ssb_pcmcia_write32(struct ssb_device *dev, u16 offset, u32 value)
{
struct ssb_bus *bus = dev-bus;
+ unsigned long flags;
+ int err;
- if (unlikely(select_core_and_segment(dev, offset)))
- return;
- writeb((value 0xFF00) 24, bus-mmio + offset + 3);
- writeb((value 0x00FF) 16, bus-mmio + offset + 2);
- writeb((value 0xFF00) 8, bus-mmio + offset + 1);
- writeb((value 0x00FF) 0, bus-mmio + offset + 0);
+ spin_lock_irqsave(bus-bar_lock, flags);
+ err = select_core_and_segment(dev, offset);
+ if (likely(!err)) {
+ writew((value 0x), bus-mmio + offset);
+ writew(((value 0x) 16), bus-mmio + offset + 2);
+ }
+ mmiowb();
+ spin_unlock_irqrestore(bus-bar_lock, flags
Re: [PATCH] b43: Only select allowed TX and RX antennas
On Saturday 22 December 2007 22:55:38 Larry Finger wrote:
Michael Buesch wrote:
This fixes antenna selection in b43. It adds a sanity check
for the antenna numbers we get from mac80211.
This patch depends on
[PATCH] ssb: Fix extraction of values from SPROM
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
After applying the 4 patches you sent earlier, the compilation fails with
CC [M] drivers/ssb/main.o
drivers/net/wireless/b43/main.c: In function ‘b43_ieee80211_antenna_sanitize’:
drivers/net/wireless/b43/main.c:2720: error: ‘struct ssb_sprom’ has no member
named ‘ant_available_bg’
drivers/net/wireless/b43/main.c:2722: error: ‘struct ssb_sprom’ has no member
named ‘ant_available_a’
These members of ssb_sprom are defined in the patch you sent to Felix Fietkau
on Dec. 10, but not in
this patch set.
This patch was included in the series I just sent.
[PATCH] ssb: Fix extraction of values from SPROM
Index: wireless-2.6/include/linux/ssb/ssb.h
===
--- wireless-2.6.orig/include/linux/ssb/ssb.h 2007-12-14
13:15:42.0 +0100 +++ wireless-2.6/include/linux/ssb/ssb.h
2007-12-20 18:58:49.0 +0100 @@ -22,7 +22,12 @@ struct ssb_sprom {
u8 et1mac[6]; /* MAC address for 802.11a */
u8 et0phyaddr; /* MII address for enet0 */
u8 et1phyaddr; /* MII address for enet1 */
+ u8 et0mdcport; /* MDIO for enet0 */
+ u8 et1mdcport; /* MDIO for enet1 */
+ u8 board_rev; /* Board revision number from SPROM. */
u8 country_code;/* Country Code */
+ u8 ant_available_a; /* A-PHY antenna available bits (up to 4)
+ u8 ant_available_bg;/* B/G-PHY antenna available bits (up to
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 06:42:56 Ehud Gavron wrote:
A little test code answered my own question. I don't know if this is
the best way to do it, but this patch fixes the problem.
Ehud
--- drivers/net/wireless/b43/rfkill.c.orig 2007-12-17
22:39:31.0 -0700
+++ drivers/net/wireless/b43/rfkill.c 2007-12-17 22:39:54.0 -0700
@@ -68,6 +68,7 @@ static void b43_rfkill_poll(struct input
/* send the radio switch event to the system - note both a key press
* and a release are required */
if (unlikely(report_change)) {
+ msleep(1); /* sleep 400usec to allow slow hardware
to enable the LED */
input_report_key(poll_dev-input, KEY_WLAN, 1);
input_report_key(poll_dev-input, KEY_WLAN, 0);
}
I'm sorry, I did not understand your previous mail.
What exactly does this fix? Can you explain in one or two sentences?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote: Ehud Gavron wrote: If I manually turn the LED on (with the keyboard sequence for KEY_WLAN), rfkill will turn the LED off when I turn the radio off consistently but without the wait will never turn the LED back on. That makes no sense; let me rephrase. I can turn the LED on manually. Then when I turn the radio switch off, rfkill turns the LED off every time. So the LED OFF by rfkill works fine. No matter what I do... without that delay, rfkill will not turn the LED back on, despite the event clearly being called by code. What happens if you completely remove the code that sends the two events? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 13:31:20 Ehud Gavron wrote: Michael Buesch wrote: On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote: Ehud Gavron wrote: If I manually turn the LED on (with the keyboard sequence for KEY_WLAN), rfkill will turn the LED off when I turn the radio off consistently but without the wait will never turn the LED back on. That makes no sense; let me rephrase. I can turn the LED on manually. Then when I turn the radio switch off, rfkill turns the LED off every time. So the LED OFF by rfkill works fine. No matter what I do... without that delay, rfkill will not turn the LED back on, despite the event clearly being called by code. What happens if you completely remove the code that sends the two events? The LED never comes on. I can make it come on/off with the key function, and if it's on and the radio is turned off the LED goes off. In other words I'm sure the hardware is turning the LED (and the BT LED) off. I'm also sure the hardware is not turning the LED back on. What other tests would you like me to do? I have no idea. But I don't understand why waiting a random time up to 1000ms fails and a random time up to 1000ms + 1ms succeeds. Where did you take that 400us wait in phy.c get from? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation wpa_driver_wext_set_countermeasures not supported
On Tuesday 18 December 2007 12:36:02 Robert Allerstorfer wrote: On Mon, 17 Dec 2007, 15:14 GMT+01 Michael Buesch wrote: Please test what I suggested. done. I have recompiled and replaced the original b43.ko from 'kernel-2.6.23.9-90.fc8.src.rpm', with the modified 'phy.c' [if (B43_DEBUG) changed to if (0) on line 741]. Using Fedora's build mechanism, I had to built the entire (baseonly) kernel which took over 2 hours. Of course, there is now no more Disabling TX power adjustment warning in dmesg, but I can't see any other different behavior. I still can't connect to the WPA2 access point. dmesg still says wlan0: RX ReassocResp from 00:11:22:33:44:55 (capab=0x431 status=0 aid=1) wlan0: associated wlan0: switched to short barker preamble (BSSID=00:11:22:33:44:55) wlan0: disassociate(reason=3) Uhm, that seems to be some mac80211 problem. The driver is obviously able to transmit and receive data properly. Otherwise it would not be able to associate. and the debug output of wpa_supplicant still contains wpa_driver_wext_set_countermeasures ioctl[SIOCSIWAUTH]: Operation not supported What can I do to get it working one day? rob. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 15:41:04 Ehud Gavron wrote: Michael Buesch wrote: On Tuesday 18 December 2007 13:31:20 Ehud Gavron wrote: Michael Buesch wrote: On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote: Ehud Gavron wrote: If I manually turn the LED on (with the keyboard sequence for KEY_WLAN), rfkill will turn the LED off when I turn the radio off consistently but without the wait will never turn the LED back on. That makes no sense; let me rephrase. I can turn the LED on manually. Then when I turn the radio switch off, rfkill turns the LED off every time. So the LED OFF by rfkill works fine. No matter what I do... without that delay, rfkill will not turn the LED back on, despite the event clearly being called by code. What happens if you completely remove the code that sends the two events? The LED never comes on. I can make it come on/off with the key function, and if it's on and the radio is turned off the LED goes off. In other words I'm sure the hardware is turning the LED (and the BT LED) off. I'm also sure the hardware is not turning the LED back on. What other tests would you like me to do? I have no idea. But I don't understand why waiting a random time up to 1000ms fails and a random time up to 1000ms + 1ms succeeds. You are right. Here are the tests I've done: 1. msleep(0) doesn't work. msleep(1) or higher does 2. remove msleep and set the poll interval to 3000ms, and I turn the radio on... and 2-3 seconds later b43 says ENABLED but the LED does not work. 3. the code in b43_rfkill_poll between the ENABLED message and where I'm putting the msleep() is one mutex unlock which was acquired ten lines previously so I can't see how that's relevant. Unless there's some weird race condition where releasing the mutex allows something else to happen which in its first 1msec prevents the keyboard event... I don't get it. Would there be any harm in moving the mutex to after the input_report_key sequence? It is possible that reading the hw radio enabled bit from hardware has some sideeffect that needs one msec to trigger. But I doubt this myself. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change)) {
b43info(wl,EHUD: sleeping\n);
msleep(1);
b43info(wl,EHUD: LED coming on\n);
input_report_key(poll_dev-input, KEY_WLAN, 1);
input_report_key(poll_dev-input, KEY_WLAN, 0);
}
So my question (other than why do I need two messages and one msleep to
get my LED lit) is... what happened to the EHUD: sleeping debug
message? It never showed up on the console. I did this several times.
The full dmesg is attached.
Ehud
This smells like a compiler bug.
Can you try an older compiler version?
(Most distros ship several versions)
Actually I do remember a gcc bug related to strict-aliasing.
What happens is that about two lines of source code are
skipped. So this might also apply here. We skip two lines.
But I don't remember the gcc bug #. :(
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 18:33:43 Michael Buesch wrote:
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change)) {
b43info(wl,EHUD: sleeping\n);
msleep(1);
b43info(wl,EHUD: LED coming on\n);
input_report_key(poll_dev-input, KEY_WLAN, 1);
input_report_key(poll_dev-input, KEY_WLAN, 0);
}
So my question (other than why do I need two messages and one msleep to
get my LED lit) is... what happened to the EHUD: sleeping debug
message? It never showed up on the console. I did this several times.
The full dmesg is attached.
Ehud
This smells like a compiler bug.
Can you try an older compiler version?
(Most distros ship several versions)
Actually I do remember a gcc bug related to strict-aliasing.
What happens is that about two lines of source code are
skipped. So this might also apply here. We skip two lines.
But I don't remember the gcc bug #. :(
I think this is the one I was talking about:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 19:39:15 Ehud Gavron wrote:
Michael Buesch wrote:
On Tuesday 18 December 2007 18:33:43 Michael Buesch wrote:
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change)) {
b43info(wl,EHUD: sleeping\n);
msleep(1);
b43info(wl,EHUD: LED coming on\n);
input_report_key(poll_dev-input, KEY_WLAN, 1);
input_report_key(poll_dev-input, KEY_WLAN, 0);
}
So my question (other than why do I need two messages and one msleep to
get my LED lit) is... what happened to the EHUD: sleeping debug
message? It never showed up on the console. I did this several times.
The full dmesg is attached.
Ehud
This smells like a compiler bug.
Can you try an older compiler version?
(Most distros ship several versions)
Actually I do remember a gcc bug related to strict-aliasing.
What happens is that about two lines of source code are
skipped. So this might also apply here. We skip two lines.
But I don't remember the gcc bug #. :(
I think this is the one I was talking about:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
From Bugzilla:
Known to Work: 4.1.2 4.3.0
gcc --version
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
Please check this anyway. This really looks like a compiler bug.
Why would it skip a printk otherwise?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24-rc5 the LED does not come on after a switch-off switch-on
On Tuesday 18 December 2007 22:09:24 Ehud Gavron wrote: I did just check and you are right! It is a compiler bug despite the version being supposedly safe. two msleep(0); 's got inlined out of the way and the KEY_WLAN code ran as it's supposed to. I can't find gcc 4.3 on gnu's site and Fedora RPMs says 4.1.2 is the latest. Any clues as to how best to proceed ? Use an older one, maybe? 4.0 or 3.4. 3.4 used to be pretty good, actually. Ehud PS Yes I realize this means it's not a b43 problem, but my problem with my compiler :) Cool. Can you please report this into the redhat bugzilla? Maybe also quote the gcc bug I quoted, as it might be possible that redhat backported this bug to their version (distributions often backport stuff from newer upstream versions). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote: On Dec 17, 2007 1:52 AM, Larry Finger [EMAIL PROTECTED] wrote: One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions. Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by issuing a 'sudo iwconfig eth1 rate 11M' command. I don't know what happened before, but after a reboot, I can't repeat the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I didn't move the laptop, or the ap, the only thing I can think of that might have changed is the noise level. FWIW, link quality is consistently the same or better with b43. Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and quickly scales to 11 Mb/s, but I tried setting it manually anyway and didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as 1 Mb/s and the download speed was the same with all three (around 30-40 kB/s). Are you working with wireless-2.6's #everything branch? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation wpa_driver_wext_set_countermeasures not supported
On Monday 17 December 2007 02:46:29 Robert Allerstorfer wrote:
On Thu, 13 Dec 2007, 00:20 GMT+01 Michael Buesch wrote:
On Wednesday 12 December 2007 23:48:10 Robert Allerstorfer wrote:
Before starting wpa_supplicant:
[EMAIL PROTECTED] ~]# dmesg | egrep 'b43|ssb|wlan0|wmaster0'
ssb: SPROM revision 1 detected.
ssb: Sonics Silicon Backplane found on PCI device 0001:10:12.0
b43-phy0: Broadcom 4306 WLAN found
b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02)
Registered led device: b43-phy0:tx
Registered led device: b43-phy0:rx
b43-phy0 debug: !WARNING! Idle-TSSI phy-cur_idle_tssi measuring failed.
(cur=42, tgt=62). Disabling TX power adjustment.
Hm, that's probably a false positive.
Please locate the function b43_phy_init_pctl() inside of
drivers/net/wireless/b43/phy.c
Locate these lines inside of the function:
if (B43_DEBUG) {
/* Current-Idle-TSSI sanity check. */
if (abs(phy-cur_idle_tssi - phy-tgt_idle_tssi) =
20) {
b43dbg(dev-wl,
!WARNING! Idle-TSSI
phy-cur_idle_tssi
measuring failed. (cur=%d, tgt=%d).
Disabling TX power
adjustment.\n, phy-cur_idle_tssi,
phy-tgt_idle_tssi);
phy-cur_idle_tssi = 0;
}
}
Please change the
if (B43_DEBUG) {
into
if (0) {
The strange thing is that the b43-phy0 debug: !WARNING!... line
disappeared from the dmesg output after I replaced ssb.ko by a
self-compiled version (and - of course - rebooted).
Which version of ssb were you using before and which one are you using now?
Can you make a diff -u?
All other kernel files have kept exactly the same (originating from
kernel-2.6.23.9-90.fc8.ppc.rpm grabbed from
http://koji.fedoraproject.org/). The original ssb.ko has been built
without defining CONFIG_SSB_DEBUG, while I turned CONFIG_SSB_DEBUG on.
Executing dmesg | egrep 'b43|ssb|wlan0|wmaster0' now begins with the
following 5 additional lines:
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243)
ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243)
ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243)
ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243)
According to http://linuxwireless.org/en/users/Drivers/b43 the full
MAC core version is printed in the kernel logs when SSB debugging is
enabled in KConfig and the driver finds a board. So, could someone
please explain which of the 5 SSB debug dmesg lines prints the full
MAC core version?
rev 5
I am curios about this to be sure if my system
needs the b43 or the b43legacy driver.
It will automatically load the right one.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation wpa_driver_wext_set_countermeasures not supported
On Monday 17 December 2007 13:49:00 Robert Allerstorfer wrote: On Mon, 17 Dec 2007, 11:00 GMT+01 Michael Buesch wrote: On Monday 17 December 2007 02:46:29 Robert Allerstorfer wrote: The strange thing is that the b43-phy0 debug: !WARNING!... line disappeared from the dmesg output after I replaced ssb.ko by a self-compiled version (and - of course - rebooted). Which version of ssb were you using before and which one are you using now? Can you make a diff -u? Both ssb.ko binaries have been built from the same source, so their versions must be the same. However, I have now found that replacing ssb.ko had nothing to do with the b43-phy0 debug warning. After rebooting several times, the output of dmesg | egrep 'b43|ssb|wlan0|wmaster0' sometimes contains such a warning line and sometimes it doesn't. Expected. So try the workaround I suggested earlier. If it is there, the number NN of the cur=NN part can differ. I have seen cur=42 or cur=38 so far: b43-phy0 debug: !WARNING! Idle-TSSI phy-cur_idle_tssi measuring failed. (cur=42, tgt=62). Disabling TX power adjustment. b43-phy0 debug: !WARNING! Idle-TSSI phy-cur_idle_tssi measuring failed. (cur=38, tgt=62). Disabling TX power adjustment. Why can this warning be different or ebven absent after each reboot? Because the cur value is a measured value which can have jitter. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation wpa_driver_wext_set_countermeasures not supported
On Monday 17 December 2007 14:43:37 Robert Allerstorfer wrote: On Mon, 17 Dec 2007, 13:53 GMT+01 Michael Buesch wrote: On Monday 17 December 2007 13:49:00 Robert Allerstorfer wrote: After rebooting several times, the output of dmesg | egrep 'b43|ssb|wlan0|wmaster0' sometimes contains such a warning line and sometimes it doesn't. Expected. So try the workaround I suggested earlier. But shouldn't setting/unsetting B43_DEBUG only affect the verbosity level of the kernel messages, but not change any functionality? No. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation wpa_driver_wext_set_countermeasures not supported
On Monday 17 December 2007 15:09:32 Robert Allerstorfer wrote: On Mon, 17 Dec 2007, 14:46 GMT+01 Michael Buesch wrote: On Monday 17 December 2007 14:43:37 Robert Allerstorfer wrote: But shouldn't setting/unsetting B43_DEBUG only affect the verbosity level of the kernel messages, but not change any functionality? No. Aha, reading the corresponding section of Kconfig (in the Fedora build system of my ppc machine residing in /usr/src/redhat/BUILD/kernel-2.6.23/linux-2.6.23.ppc/drivers/net/wireless/b43/) gave me the impression that it would: config B43_DEBUG bool Broadcom 43xx debugging depends on B43 ---help--- Broadcom 43xx debugging messages. Say Y, if you want to find out why the driver does not work for yo So that means enabling Broadcom 43xx debugging may disable functionality? Oh, come on... It will enable or disable the driver debugging features. If you don't like the word messages in the help text please submit a patch. Please test what I suggested. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote: On Dec 17, 2007 5:35 AM, [EMAIL PROTECTED] wrote: If this is a mac80211 related problem, then other systems connecting to the same ap and using mac80211 would also be affected? Like I said earlier, there are five machines connecting to this ap, and I just realized one of them has a ralink card that uses the rt2x00 driver, which I believe is mac80211. That system doesn't have this problem, which leads me to believe it may not be mac80211 after all, although I wouldn't rule it out. This also doesn't seem to be related to firmware version. I forced my device to use b43legacy, and the results were identical with the version 3 firmware. Ehm, excuse me. What are you doing exactly? In this thread you told me you have a device which requires b43: I don't know what happened before, but after a reboot, I can't repeat the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I didn't move the laptop, or the ap, the only thing I can think of that might have changed is the noise level. FWIW, link quality is consistently the same or better with b43. How the hell can you now force it to use b43legacy?? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote: On Dec 17, 2007 5:45 PM, Michael Buesch [EMAIL PROTECTED] wrote: Ehm, excuse me. What are you doing exactly? In this thread you told me you have a device which requires b43: Well, I'm not sure what you mean by requires b43, but I did say that the device uses the b43 driver. Requires means requires. Sorry, I should have been more specific. I figured since the device could use bcm43xx, it could also use b43legacy, so I copied the entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the b43legacy driver. I removed the b43 and ssb modules, and inserted the b43legacy module. Afterwards, I noticed b43 had still been autoloaded, so I removed it (I checked dmesg and only b43legacy had initialized anyway) , and proceeded to use the b43legacy driver with the version 3 firmware. And like I said, it works exactly like the b43 driver with the version 4 firmware. I'm not sure what you are trying to show with this hack. It's been said several times in this thread that the firmware has nothing to do with the device radio. So it won't affect the transmit rate or something like that. Note that the difference between b43 and b43legacy is NOT that the driver is legacy. It is called legacy because it does _only_ support legacy _devices_. So if you hack it to drive a new card it will only work by luck (luck as in there might be some code left over which is able to initialize the device somehow.). My point being, we removed code for new devices from b43legacy and are probably going to remove even more stuff in the future. So there is simply no point in testing any new device with b43legacy. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote: * John W. Linville [EMAIL PROTECTED] wrote: It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. as long as the version 4 firmware blob is present in the system, will testers have a fully fluid test- and work-flow when migrating across from bcm43xx to b43, without any other changes to an existing Linux installation? (i.e. no udev tweaks, no forced upgrades of components, etc.) Will it Just Work in bisection as well, when a tester's kernel flip/flops between bcm43xx and b43 - like it does for the other 3000+ drivers in the kernel? Note that we are _NOT_ interested in might or can scenarios. We are interested in preserving the _existing_ bcm43xx installed base and how much of a seemless migration the b43 transition will be. _THAT_ is what the no regressions upstream rule is about, not the ideal distro scenario you outline above. It is YOUR total obligation as a kernel maintainer to ensure that you dont break old installations. How hard is that to understand? This is not rocket science. I see no reason for b43 to break, if the firmware is properly installed. In fact, almost all installation related bugreports we receive are caused by missing or incorrectly installed firmware. I would really _like_ to make installing firmware easier or make the whole need for it vanish, but I simply can not at this point. But anyway, installing it is not rocket science, either. The only thing you have to know is where your distribution stores the firmware image files. If you know that it's a matter of invoking one b43-fwcutter command to install it. This process can be automated in the distribution's rpm or deb package scripts. b43lagacy/ssb is completely featured with module autoload support. So if you have firmware installed it will automatically load all required modules and create the network device(s) for it without any user interaction. If that doesn't work, then stupid distributions are shipping braindamaged udev scripts that pin a mac address to a specific driver name (see another mail in this thread). I can _not_ fix this from within the kernel and I will absolutely shift all responsibility and blame for this to the maintainers of the distribution's udev scripts. That's not a b43 specific problem then. Other drivers do break with these scripts, too. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? That's really a question, right? Well. linux-2.4 doesn't work with the linux-2.6 modutils. Windows Vista doesn't work with Windows 98 device drivers. That leads to this assumption: b43 doesn't work with version 3 firmware but needs version 4. Newer drivers supporting newer hardware need newer firmware. Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? version 4 is the new firmware released by broadcom. They obviously won't support and write any version 3 firmware anymore. So we are forced to switch to version 4 firmware to support the newest hardware (like N-PHY in the future). It's really as simple as that. The difference between v3 and v4 is basically the driver API. It changed a lot and it is nontrivial to support both v3 and v4 in one driver. So we decided to stay with v3 for legacy devices and take v4 for any newer devices. We have to live with that crap until someone comes up with an opensource firmware. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 01:55:50 Harvey Harrison wrote: On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote: Oh come on. b43 is more than a year old now. How long should we wait? Two or three? Forever? Any pointers to the advantages of b43? http://www.linuxwireless.org/en/users/Drivers/b43 -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? That's really a question, right? Well. linux-2.4 doesn't work with the linux-2.6 modutils. Windows Vista doesn't work with Windows 98 device drivers. That leads to this assumption: b43 doesn't work with version 3 firmware but needs version 4. Newer drivers supporting newer hardware need newer firmware. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 12:15:34 Ingo Molnar wrote: So you volunteer to maintain bcm43xx? Fine. Thanks a lot. it's sad that you are trying to force testers to upgrade to your new driver by threatening to unsupport the old driver. I dropped maintainance for bcm43xx over a year ago. So I am not going to catch it up again. b43 works fine. I don't see a reason to support bcm43xx anymore. Currently bcm43xx is orphaned, as Larry couldn't support it anymore due to other issues. The testers who did nothing but reported that the new driver did not work on their hardware. Which testers? Ray Lee didn't even install the firmware. So it can't work by definition. That is not my fault. You can write new drivers but you must not break existing users. That's true for every single piece of the kernel. It is _your_ responsibility to get that rule right - and if it does not work out of box (no matter whom to blame, udev or the driver) you dont get to remove the driver from the upstream kernel. Ok. So we have to live with an orphaned driver. I am fine with that, too. Yes, you can then unsupport it in spite and be a prick about it in general but that will only talk of your own personal qualities and will sharply reduce your credibility as a maintainer (and eventually hinder your ability to introduce new code) - users will still have the code available and will have a chance to fix the driver that happens to work. (and perhaps another, capable, but friendler maintainer arises.) And that old code will be a clot to drag around, hindering your 'new' wireless code all along. So new code is included in the Linux kernel based only on political considerations instead on technical? I'm not sure what's the matter. Show me _one_ person for whom bcm43xx works and b43/legacy does not. And I will immediately stop removal of that driver and fix b43. I really dont know why it's so hard to understand: new is totally useless if it does not work for old setups 100% of the time. And people _WANT_ to use your new code, so it's not like you have to pull their hairs to get your stuff tested. And YOU wrote the old code in large part: $ git-authors drivers/net/wireless/bcm43xx/ | tail -10 2 Sam Ravnborg 3 David Howells 3 David Woodhouse 3 Joe Perches 4 Jeff Garzik 5 Daniel Drake 6 Stefano Brivio 9 John W. Linville 48 Larry Finger 80 Michael Buesch so it's not like someone else messed it up and that you would be incapable of getting it all work nicely and make the migration of users smoother. And if udev is a hindrance to you, reduce your driver's dependence on udev breakages. I'm not sure what you are talking about. If udev renames the device to something stupid (like wlan0_rename) that is not my fault. That is the fault of a big Linux Distribution messing udev config up. Let's summarise it: I don't know a single user for whom bcm43xx works but b43 does not. In most cases b43 does work a _lot_ better than bcm43xx. If you show me one person for whom bcm43xx works but b43 does not I will stop removal of the driver. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH final] b43: Fix rfkill radio LED
From: Larry Finger [EMAIL PROTECTED]
This fixes Bug #9414
Since addition of the rfkill callback, the LED associated with the off
switch on the radio has not worked for several reasons:
(1) Essential data in the rfkill structure were missing.
(2) The rfkill structure was initialized after the LED initialization.
(3) There was a minor memory leak if the radio LED structure was inited.
Once the above problems were fixed, additional difficulties were noted:
(4) The radio LED was in the wrong state at startup.
(5) The radio switch had to be manipulated twice for each state change.
(6) A circular mutex locking situation existed.
(7) If rfkill-input is built as a module, it is not automatically loaded.
This patch fixes all of the above.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c 2007-12-14
13:47:36.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/rfkill.c 2007-12-14
13:50:37.0 +0100
@@ -25,6 +25,8 @@
#include rfkill.h
#include b43.h
+#include linux/kmod.h
+
/* Returns TRUE, if the radio is enabled in hardware. */
static bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
@@ -50,7 +52,10 @@ static void b43_rfkill_poll(struct input
bool report_change = 0;
mutex_lock(wl-mutex);
- B43_WARN_ON(b43_status(dev) B43_STAT_INITIALIZED);
+ if (unlikely(b43_status(dev) B43_STAT_INITIALIZED)) {
+ mutex_unlock(wl-mutex);
+ return;
+ }
enabled = b43_is_hw_radio_enabled(dev);
if (unlikely(enabled != dev-radio_hw_enable)) {
dev-radio_hw_enable = enabled;
@@ -60,8 +65,12 @@ static void b43_rfkill_poll(struct input
}
mutex_unlock(wl-mutex);
- if (unlikely(report_change))
- input_report_key(poll_dev-input, KEY_WLAN, enabled);
+ /* send the radio switch event to the system - note both a key press
+* and a release are required */
+ if (unlikely(report_change)) {
+ input_report_key(poll_dev-input, KEY_WLAN, 1);
+ input_report_key(poll_dev-input, KEY_WLAN, 0);
+ }
}
/* Called when the RFKILL toggled in software. */
@@ -69,13 +78,15 @@ static int b43_rfkill_soft_toggle(void *
{
struct b43_wldev *dev = data;
struct b43_wl *wl = dev-wl;
- int err = 0;
+ int err = -EBUSY;
if (!wl-rfkill.registered)
return 0;
mutex_lock(wl-mutex);
- B43_WARN_ON(b43_status(dev) B43_STAT_INITIALIZED);
+ if (b43_status(dev) B43_STAT_INITIALIZED)
+ goto out_unlock;
+ err = 0;
switch (state) {
case RFKILL_STATE_ON:
if (!dev-radio_hw_enable) {
@@ -133,9 +144,25 @@ void b43_rfkill_init(struct b43_wldev *d
rfk-poll_dev-poll = b43_rfkill_poll;
rfk-poll_dev-poll_interval = 1000; /* msecs */
+ rfk-poll_dev-input-name = rfk-name;
+ rfk-poll_dev-input-id.bustype = BUS_HOST;
+ rfk-poll_dev-input-id.vendor = dev-dev-bus-boardinfo.vendor;
+ rfk-poll_dev-input-evbit[0] = BIT(EV_KEY);
+ set_bit(KEY_WLAN, rfk-poll_dev-input-keybit);
+
err = rfkill_register(rfk-rfkill);
if (err)
goto err_free_polldev;
+
+#ifdef CONFIG_RFKILL_INPUT_MODULE
+ /* B43 RF-kill isn't useful without the rfkill-input subsystem.
+* Try to load the module. */
+ err = request_module(rfkill-input);
+ if (err)
+ b43warn(wl, Failed to load the rfkill-input module.
+ The built-in radio LED will not work.\n);
+#endif /* CONFIG_RFKILL_INPUT */
+
err = input_register_polled_device(rfk-poll_dev);
if (err)
goto err_unreg_rfk;
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-14
13:47:36.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-14
13:47:39.0 +0100
@@ -2165,7 +2165,6 @@ static void b43_mgmtframe_txantenna(stru
static void b43_chip_exit(struct b43_wldev *dev)
{
b43_radio_turn_off(dev, 1);
- b43_leds_exit(dev);
b43_gpio_cleanup(dev);
/* firmware is released later */
}
@@ -2193,11 +2192,10 @@ static int b43_chip_init(struct b43_wlde
err = b43_gpio_init(dev);
if (err)
goto out; /* firmware is released later */
- b43_leds_init(dev);
err = b43_upload_initvals(dev);
if (err)
- goto err_leds_exit;
+ goto err_gpio_clean;
b43_radio_turn_on(dev);
b43_write16(dev, 0x03E6, 0x);
@@ -2273,8 +2271,7 @@ out:
err_radio_off:
b43_radio_turn_off
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 13:16:17 Ingo Molnar wrote: * Michael Buesch [EMAIL PROTECTED] wrote: The testers who did nothing but reported that the new driver did not work on their hardware. Which testers? right in this thread Ray Lee is reporting: | | Digging a little farther into it, it looks like b43 is barfing | | partway through init as the firmware file it's looking for has | | changed names. Perhaps that's the issue. I'll take a longer look at | | this all tomorrow. you are really in denial of reality. Just re-read this thread. Upon re-reading this thread, try to imagine that you are in place of Ray Lee (might be hard), that you had a working bcm43xx driver and that now you try to get b43 to work. You are not a kernel hacker who knows this driver, just an advanced user who'd like to give you some more feedback about your shiny new code. This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); b43err(wl, You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the correct firmware (version 4).\n); I'm not sure how I can improve that even more. There is a full URL describing how to get the device workin in _full_ detail. Yes. I know people don't read messages and immediately report a regression. But that is not my fault. Not in this case. It's not rocket science to get b43 working. The way firmware is installed did not change at all. (b43-fwcutter is still used). So it's the very same procedure that user X already successfully did when installing bcm43xx. What should I do to improve the situation? Writing the message all in uppercase? Maybe. I can do a patch, if people finally start reading it then. Ray Lee didn't even install the firmware. So it can't work by definition. That is not my fault. which questions your basic skills of reading or of empathy. Why is a reasonable firmware blob not included in the kernel? Because it's closed source. If not, why doesnt the b43 driver warn in the dmesg (where Ray Lee did look) that no firmware was loaded? These are basic driver usability issues, and of course they are your fault too. This is a proven false statement. So new code is included in the Linux kernel based only on political considerations instead on technical? huh? This is nothing political. It's the basic rule of maintenance: try to be a good maintainer, involve people, forgive their newbie mistakes. It's like the driving principle of Intenret protocols: be conservative at what you xmit and be liberal at what you rx. That's not what my problem is here. The problem is that every now and then people come up and say that b43 is crap and doesn't work for them while bcm43xx does. In _every_ single case it was the user's fault. Mostly not reading the kernel message I quoted above. So I'm not sure what I have to do now? Defer removal of an obsolete and unstable piece of junk because some people don't read kernel logs in case something doesn't work? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 17:45:52 Ray Lee wrote: On Dec 14, 2007 8:27 AM, Ray Lee [EMAIL PROTECTED] wrote: On Dec 14, 2007 6:40 AM, [EMAIL PROTECTED] wrote: Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo suggests other ways to smooth out the transition. I haven't read proposals yet. This isn't rocket science guys. Put a file in somewhere in your tree called ReleaseAnnouncement or something, and ask Linus to adjust his kernel release process to include the contents of `cat $( find . -name ReleaseAnnouncement )` in the release message he sends out. Clear out the file after the release. Include things such as bcm43xx is scheduled for removal. build both b43 and b43legacy as a replacement. Be sure to download the latest firmware from $URL and follow the instructions there to extract the correct latest firmware necessary for your chip. There are known incompatibilities with old udev versions, please ensure blah blah blah. Or even better, keep the history, and show the diff of the old versus new in the release announcement, with an appropriate sed 's/+/ /' or somesuch. shrug I'm sure you all will figure something out. Regardless, my point is a higher level changelog that is human readable would be helpful. (There are thousands of per-commit changelog entries to read, it's beyond what I have the time to do when testing a new kernel). Also, it seems distributing the release announcement work would be as helpful as distributing the code development work. In my opinion this all is the work of the distributions and not the work of the kernel developers. Distributions have to make sure that everything works after a kernel update. Yes I know that this is difficult with b43, as the firmware is closed source. But this can be worked around by explicitely prompting the user when the kernel is updated. This is all distribution stuff. What if you want to compile your own kernel? Well, then you are on your own anyway. You have to track kernel changes anyway. And I am pretty sure that it really is simple to track kernel changes. Get your favourite kernel news site. It will tell you the changes without this magic ReleaseAnnouncement file stuff. I mean. There are news sites (even not specific ones for the kernel) that reported the bcm43xx-b43 change weeks ago. There must be some place where they get this information from without magic files. ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 17:06:39 Ray Lee wrote: Hi all. Perhaps I can inject some facts into this? On Dec 14, 2007 5:08 AM, Michael Buesch [EMAIL PROTECTED] wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); b43err(wl, You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the correct firmware (version 4).\n); I'm not sure how I can improve that even more. There is a full URL describing how to get the device workin in _full_ detail. Yes, but only if you load rfkill-input and rfkill by hand, prior. I'm not sure what you are doing there. Do you have module autoloading disabled? This all works perfectly well on all of my systems. And I never heared such a problem before. If you have a PCI device probing works as follows: The PCI table is in ssb. So as soon as your kernel detects the PCI device it will load ssb. ssb will register the PCI device. That will trigger an udev event for the contained 802.11 core to get probed. This will load b43. So, I'm not sure where's the issue with my code here. That I'm one of the first people to hit that makes me think that your testing base so far has been miniscule. The driver is shipped by Fedora since quite some time. || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in || dmesg other than lines related to the bcm43xx driver. || iwconfig/ifconfig do not see the interface either. See above. Without a modprobe of rfkill, rfkill-input that is the case. You can't do modprobe ssb b43 This will be interpreted as modprobe of ssb with the module parameter b43. At least by my modutils. If you do modprobe b43 it will automatically load _all_ required modules. It works perfectly well on my systems. Try it. Simply type modprobe b43. It will also work for you. Hello? I tried that. It failed. What *I'm* talking about here is that this everyone needs to be aware that this is *not* a drop in replacement for bcm43xx, and if I'm having problems (not a kernel hacker, but I make my living writing code), then sheesh, you're gonna have a flood of people needing hand-holding on this. All problems so far were not related to the b43 sourcecode at all. And I think I can not be held responsible for unrelated code or bugs in the operating system scripts. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 18:59:10 Ingo Molnar wrote: * Michael Buesch [EMAIL PROTECTED] wrote: In my opinion this all is the work of the distributions and not the work of the kernel developers. Distributions have to make sure that everything works after a kernel update. [...] actually, not. The the task of kernel developers is to KEEP OLD DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the old driver stays around until eternity, because the new one is just BROKEN. What exactly prevents an old distribution from using new b43 given that they fix their broken udev scripts first? (I cannot fix their broken scripts from within the kernel.) Take a look at CONFIG_COMPAT_VDSO for example - one single version of glibc was released in a distro that depended on a kernel vDSO bug. So we'll keep that aspect of the vDSO perhaps forever. Simple as that. Stuff must just work. Whatever it takes. Best is if you add in new stuff without the user noticing _ANYTHING_ but that the kernel version bumped. If the maintainers of the other 7 million lines of kernel code can get this right then the wireless code should be able to do it too. Ok? all this distributors will have to sort out the mess talk is nonsense, and i really hope you do not truly believe in that crap. If your attitude is prevalent in the wireless development community then it's in worse shape than i thought :-( Sorry if I didn't chose my wording correctly. But I was only talking about the development of drivers. It is correct that userspace ABI has to be preserved, but that is not an issue at all to drivers. I was talking about things like installing the right firmware for the new driver. It is the job of the distributors to install the new firmware when they introduce a new driver. It is the job of the distributors to test their userland scripts and configuration stuff with that driver and fix their stuff. It is _not_ my job to fix random distribution udev scripts or explaining over and over again to people how the firmware is installed. Either distributions have to install it automatically or people simply have to read one or two lines of documentation. That's just what I wanted to say. Of course it is _my_ job to preserve ABI. I did never want to question that. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 19:01:51 Ray Lee wrote:
No, I don't have module autoloading disabled. modprobe-ing b43
automatically loads ssb. Neither, however, will load rfkill or
rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
silent during load. Nothing to dmesg at all.
That is a bug in your distribution. I cannot fix this.
Maybe the module is blacklisted or whatever. This is _not_ a b43 bug.
This all works perfectly well on all of my systems. And I never heared
such a problem before.
WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
I'm going to blame this on you being tired or something, okay? But in
the meantime, could you *PLEASE* start giving me the benefit of the
doubt?
The message you quote describes a _completely_ unrelated bug.
Besides that the bug described in the message does _not_ prevent
the device from working. It does _just_ prevent some random LED from
blinking. I'd not call that a big issue.
To say it again: This message was about loading rfkill-input _after_
b43 was loaded successfully.
Please carefully read the messages before using them to prove me wrong.
If you have a PCI device probing works as follows:
The PCI table is in ssb. So as soon as your kernel detects the PCI device
it will load ssb. ssb will register the PCI device. That will trigger
an udev event for the contained 802.11 core to get probed. This will load
b43.
So, I'm not sure where's the issue with my code here.
There's a patch from Larry Finger to address this and other issues. It
hasn't made it's way fully upstream yet. Please read your message
here, in particular item number seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
1) I sent this patch out today for inclusion in the kernel
2) This is a _completely_ unrelated issue.
It is about rfkill-input being not loaded. NOT about
b43 or rfkill not being loaded.
If you do
modprobe b43
it will automatically load _all_ required modules.
It works perfectly well on my systems.
Try it. Simply type modprobe b43. It will also work for you.
As I've said multiple times earlier in this thread, I did try that and
it didn't work. Do you believe me now?
Ok, Please find out why it doesn't work.
Hello? I tried that. It failed. What *I'm* talking about here
is that this everyone needs to be aware that this is *not* a drop in
replacement for bcm43xx, and if I'm having problems (not a kernel
hacker, but I make my living writing code), then sheesh, you're gonna
have a flood of people needing hand-holding on this.
All problems so far were not related to the b43 sourcecode at all.
And I think I can not be held responsible for unrelated code or bugs
in the operating system scripts.
So, do you want a scorecard on this?
One problem related to b43 source code, patch exists, has yet to be
merged upstream.
Yeah. A problem preventing a LED from blinking.
That's a real regression Come on. Stop that bullshit.
One problem related to udev rules, that may or may not be fixed in the
latest udev. I have udev version 113, which is the latest shipped in
Ubuntu's nightly development snapshots (hardy heron). I see that
version 117 of udev is available on kernel.org, but mine is from the
end of June. One would think that wouldn't be so old as to be a
complete deal breaker. Especially as bcm43xx works fine with my udev.
How can I fix that?
With udev rules hand-edited to include the ATTRS{type}==1 Larry
pointed out (thanks Larry), b43 also seems to create an odd extra
device, wmaster0.
That's not b43 specific. And it is not a bug. Ignore wmaster.
It is not useful for anything from userspace.
Same MAC as eth1, my wireless. It's just an odd
thing that wasn't there before with bcm43xx. May be good, may be bad,
dunno.
Blame your distribution, please.
And yeah, in my opinion, making the kernel play well with up-to-date
userspace actually *is* part of your job, but then again, what do I
know.
How the hell do I workaround broken udev scripts from within the kernel?
Michael, you're a good guy, I believe that. You're doing unglamorous
and mostly thankless work, and I am thankful for it. I'm afraid the
only way I could make it glamorous is to offer to send you a fancy
feathered outfit to wear while coding :-). But try to meet us testers
halfway, okay? Please keep in mind that I'm really only trying to
help.
Yeah. So PLEASE point out real bugs in MY code and do not bother
me with other peoples bugs that I simply can not fix.
In the list above there was exactly one bug for which I am responsible.
And I already sent a fix for this one.
Now I'm going to go off, sit in the sun, sip some coffee, and think
happy thoughts of kittens playing with yarn for a while.
Have fun.
--
Greetings Michael.
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 19:45:02 Ray Lee wrote: One problem related to b43 source code, patch exists, has yet to be merged upstream. Yeah. A problem preventing a LED from blinking. That's a real regression Come on. Stop that bullshit. I'm going to say this one last time. If rfkill and rfkill-input aren't manually loaded before sb and b43, not one damn thing comes out in dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to find out that those modules had to be loaded by hand was to go read the bcm43xx-dev archives. Once those were loaded, messages came out in dmesg pointing me to the URL for updated firmware. I'm sorry. The patch that _you_ quoted fixes a blinking LED and nothing else. It does _not_ fix loading of rfkill or b43 in any way. It does, however, fix loading of rfkill-input. But the b43 module operation does _not_ depend in any way on the rfkill-input module, except the tiny LED that doesn't blink if it's not loaded. I hope you understood now that the thread on bcm43xx-dev was NOT about your requirement to load rfkill before b43. I have complete current userspace as of yesterday's Ubuntu Hardy Heron development archives. Ok. I will install a copy of Ubuntu Hardy Heron and check if I can reproduce this. However the fact that this does not happen on older Ubuntu platforms and does not happen on Fedora leads to the conclusion that it is a bug in Hardy Heron that I am not responsible for. And you also do realise that Hardy Heron is the current development version of Ubuntu? Development versions have bugs. One last thing. I've been nice to you. Please be nice to me. If you simply stop blaming bugs on me that I am not responsible for at all, that is a deal. What about filing a bug at the ubuntu bugzilla? PS: Note that Ubuntu is known to break the broadcom driver every now and then. But I can not change that. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 20:25:39 Ray Lee wrote:
I'm sorry. The patch that _you_ quoted fixes a blinking LED
and nothing else.
Well, you're wrong. Sorry, but that's just the way it is. See below.
It does _not_ fix loading of rfkill or b43 in any way.
It does, however, fix loading of rfkill-input. But the b43 module
operation does _not_ depend in any way on the rfkill-input module, except
the tiny LED that doesn't blink if it's not loaded.
I hope you understood now that the thread on bcm43xx-dev was NOT about
your requirement to load rfkill before b43.
*AGAIN*, please read your message here, in particular item number
seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!
Guy... .
I KNOW what the patch above does.
What do you think does the following line?
err = request_module(rfkill-input);
Does it load the rfkill-input or the rfkill module.
That's the million dollar question. You only have one try.
This patch is NOT about the rfkill module. I don't know how
often I have to say that. It is _obvious_.
Let's also quote Larry's sevenths point here, that you referred to
now for the second time:
(7) If rfkill-input is built as a module, it is not automatically loaded.
I am not sure how I can make this any more clear.
It does load the rfkill-input module from within b43.
It does NOT load rfkill
It does NOT load rfkill-input BEFORE b43 was loaded.
This patch does exactly ONE thing. It does make sure a LED does blink.
Nothing more.
I signed this patch off. So you can be 100% sure I know what it does.
I do NOT sign off patches for which I don't know what they do.
I have complete current userspace as of yesterday's Ubuntu Hardy Heron
development archives.
Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
reproduce this.
I'm not asking you to do that, this particular bug will be fixed by
Larry's patch, whether you believe that or not.
Did you try that?
How can b43 load get fixed by a patch that adds a request_module()
to the b43 module? That is a chicken and egg problem!
However the fact that this does not happen on older Ubuntu platforms
and does not happen on Fedora leads to the conclusion that it
is a bug in Hardy Heron that I am not responsible for.
The kernel does not exist in a vacuum. It's the kernel's job to make
sure it works with properly written userspace. Broken userspace, sure,
then we can talk about breaking it.
yes properly written userspace.
And you also do realise that Hardy Heron is the current development
version of Ubuntu? Development versions have bugs.
Oy vay. I'm not an idiot. Yes, it's the current develoment version.
But tracking the latest kernel.org kernel has in the past required the
latest develoment version of the distribution, so I upgrade it as
well.
I am running wireless-2.6 on feisty. So the kernel does _not_ require
an update of the distribution.
q.e.d.
I'm not blaming it on you. I'm merely reporting a fucking
incompatibility. Read my messages again from the top, and stop taking
this all so damn personally, will you?
You are telling me that I don't understand patches that I sign off
and I should not take this personally?
That is challenging.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 20:55:43 Ray Lee wrote: Oh. My. God. Michael. I have a degree in Physics. I placed sixth in the world finals of the ACM Collegiate programming contest in 1999, Cal Poly Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html , I'm the guy all the way to the right. ) I ported the 2.4 kernel to a custom ppc platform, including writing drivers for various hardware on it ( http://patinc.com ). I'm the guy who did all the software for a linux-based Voice over IP call center ( http://broncocommunications.com/ ). Nice. I am one of the main b43 developers and I wrote most of the code. I know most of the code from the top of my head. Besides that my weiner is bigger than yours. :P To answer your question, it requests the rfkill-input module. But under the version I'm trying, rfkill-input is not automatically loaded. It is not an issue. You can even rmmod rfkill-input in FULL operation. It will not disturb the operation, except that an LED stops working. Try it! (I _did_ try it). I've pointed to the mailing list URL that proves that. So, I loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't necessary, I don't know, and I don't care. But once I did that, *then and only then* did your damn b43 driver start printing out any messages to dmesg at all, which then let me download the latest firmware, and continue moving forward. The b43 does print _nothing_ on modprobe. That is _correct_ behaviour. b43 does print the firmware message after ifconfig up. Might it be possible that this was coincidence and you messed with modprobe rfkill and ifconfig up and finally saw the message? You are telling me that I don't understand patches that I sign off and I should not take this personally? That is challenging. I'm saying the patch you signed off on has a side-effect that will fix my issue. And even if I *were* saying that, the most you should take Ok. So please revert that patch and try to reproduce the breakage. Does that work? from it is that you are human and sometimes may make mistakes, just I am inhuman. We all know that. (That was a joke that you probably don't understand. But you can google for bcw vs. bcm43xx :) ) Ray, I _do_ want to understand what is going on in your machine. I _have_ to understand it. But I currently do not understand how the quoted patch could fix modprobe of b43 or rfkill. I'd simply call that impossible. Impossible because the patch does change a few function called _inside_ of the b43 module. How could that fix load of the b43 module? (Note that we are not changing some modprobe magic like the ID table). So could you please try to reproduce the breakage by reverting that patch again? Just to make really sure it is this patch fixing the issue and not just some coincidence. Thanks for your help. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix rfkill radio LED
On Thursday 13 December 2007 06:32:11 Larry Finger wrote: Michael, I finally found the problem. It turned out that b43_rfkill_soft_toggle() was returning -EBUSY even when there was no error. I also changed the Oh, damn. :) logic in the request_module(rfkill-input) section. Now, the code is Ehm, no. Wait. There was a #ifdef CONFIG_RFKILL_INPUT_MODULE That is only defined if rfkill-input is a module, right? only compiled if rfkill-input is not built-in. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 01:05:00 Ray Lee wrote: Okay, I had to modprobe rfkill-input and rfkill by hand, didn't realize that. Hopefully that'll be automatic soon. Regardless, upon doing so, and loading ssb and b43, it sees my card, but is still not fully functional. iwconfig sees: lono wireless extensions. eth0 no wireless extensions. tun0 no wireless extensions. eth1 no wireless extensions. wlan0_rename IEEE 802.11g ESSID: Mode:Managed Channel:0 Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2346 B Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.) `ifconfig` doesn't see eth1 or wlan0_rename. What else might I be doing wrong? I don't know. Try ifconfig -a Or tell udev to not crap up your device names. Regardless, perhaps scheduling bcm43xx for removal in 2.6.26 is a bit premature. Oh come on. b43 is more than a year old now. How long should we wait? Two or three? Forever? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: Fix for broken transmission
On Wednesday 12 December 2007 09:21:26 Pavel Roskin wrote: Quoting Larry Finger [EMAIL PROTECTED]: Michael Buesch wrote: Here's an updated version that should fix even more bugs: http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/005-b43-fix-init-rewrite-breakage.patch I had to omit the last part (for tables.c) - it's unrelated, cosmetic and doesn't apply to wireless-2.6/everything. This patch depends on [PATCH] b43: Fix ofdmtab write regression And that is not just cosmetic. This patch (and its predecessor) seem to make transmission at the OFDM rates a bit more reliable on my BCM4311/2 card. It's working fine on BCM4318 on PowerPC. I haven't done any specific comparisons, but it used to disconnect a lot (at least one an hour) with a small antenna, so I installed a bigger antenna, but then gave up and switched to using another wireless device (rtl8185). Right now, it's been working for over 2 hours with a small antenna (although it's a different antenna borrowed from rtl8185) and no disconnects. Scanning finds 5 APs, which is the most I have seen here. Cool, thanks. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 regression
On Wednesday 12 December 2007 04:16:22 Brennan Ashton wrote: On Dec 11, 2007 3:02 AM, Michael Buesch [EMAIL PROTECTED] wrote: On Tuesday 11 December 2007 02:14:05 Brennan Ashton wrote: https://bugzilla.redhat.com/show_bug.cgi?id=412861 I downloaded the source for 2.6.23.8-63.fc8.src.rpm the package that things started to stop working at, and could not find any part of this patch applied, so at least for that bug it is something else. Please find out which patch broke it then. Nobody but you can do this. What do you use to hammer the card with data to see if if fails? I You can use iperf or simply wget some file from a http server in the network. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH RFT] b43: Fix rfkill radio LED
I tried to fix the locking breakage and also cleaned up a few other things.
Please test this Larry. If that works, I will immediately send it to John.
Thanks.
Subject: b43: Fix rfkill radio LED
From: Larry Finger [EMAIL PROTECTED]
This fixes Bug #9414
Since addition of the rfkill callback, the LED associated with the off
switch on the radio has not worked for several reasons:
(1) Essential data in the rfkill structure were missing.
(2) The rfkill structure was initialized after the LED initialization.
(3) There was a minor memory leak if the radio LED structure was inited.
Once the above problems were fixed, additional difficulties were noted:
(4) The radio LED was in the wrong state at startup.
(5) The radio switch had to be manipulated twice for each state change.
(6) A circular mutex locking situation existed.
(7) If rfkill-input is built as a module, it is not automatically loaded.
This patch fixes all of the above.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c 2007-12-09
21:33:18.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/rfkill.c 2007-12-12
19:34:03.0 +0100
@@ -25,6 +25,8 @@
#include rfkill.h
#include b43.h
+#include linux/kmod.h
+
/* Returns TRUE, if the radio is enabled in hardware. */
static bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
@@ -50,7 +52,10 @@ static void b43_rfkill_poll(struct input
bool report_change = 0;
mutex_lock(wl-mutex);
- B43_WARN_ON(b43_status(dev) B43_STAT_INITIALIZED);
+ if (unlikely(b43_status(dev) B43_STAT_INITIALIZED)) {
+ mutex_unlock(wl-mutex);
+ return;
+ }
enabled = b43_is_hw_radio_enabled(dev);
if (unlikely(enabled != dev-radio_hw_enable)) {
dev-radio_hw_enable = enabled;
@@ -60,8 +65,12 @@ static void b43_rfkill_poll(struct input
}
mutex_unlock(wl-mutex);
- if (unlikely(report_change))
- input_report_key(poll_dev-input, KEY_WLAN, enabled);
+ /* send the radio switch event to the system - note both a key press
+* and a release are required */
+ if (unlikely(report_change)) {
+ input_report_key(poll_dev-input, KEY_WLAN, 1);
+ input_report_key(poll_dev-input, KEY_WLAN, 0);
+ }
}
/* Called when the RFKILL toggled in software. */
@@ -69,13 +78,14 @@ static int b43_rfkill_soft_toggle(void *
{
struct b43_wldev *dev = data;
struct b43_wl *wl = dev-wl;
- int err = 0;
+ int err = -EBUSY;
if (!wl-rfkill.registered)
return 0;
mutex_lock(wl-mutex);
- B43_WARN_ON(b43_status(dev) B43_STAT_INITIALIZED);
+ if (b43_status(dev) B43_STAT_INITIALIZED)
+ goto out_unlock;
switch (state) {
case RFKILL_STATE_ON:
if (!dev-radio_hw_enable) {
@@ -133,9 +143,26 @@ void b43_rfkill_init(struct b43_wldev *d
rfk-poll_dev-poll = b43_rfkill_poll;
rfk-poll_dev-poll_interval = 1000; /* msecs */
+ rfk-poll_dev-input-name = rfk-name;
+ rfk-poll_dev-input-id.bustype = BUS_HOST;
+ rfk-poll_dev-input-id.vendor = dev-dev-bus-boardinfo.vendor;
+ rfk-poll_dev-input-evbit[0] = BIT(EV_KEY);
+ set_bit(KEY_WLAN, rfk-poll_dev-input-keybit);
+
err = rfkill_register(rfk-rfkill);
if (err)
goto err_free_polldev;
+
+#ifdef CONFIG_RFKILL_INPUT_MODULE
+ /* B43 RF-kill isn't useful without the rfkill-input subsystem.
+* Try to load the module. */
+ err = request_module(rfkill-input);
+ if (err) {
+ b43warn(wl, Failed to load the rfkill-input module.
+ The built-in radio LED will not work.\n);
+ }
+#endif /* CONFIG_RFKILL_INPUT_MODULE */
+
err = input_register_polled_device(rfk-poll_dev);
if (err)
goto err_unreg_rfk;
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-12
18:29:34.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-12
19:39:20.0 +0100
@@ -2165,7 +2165,6 @@ static void b43_mgmtframe_txantenna(stru
static void b43_chip_exit(struct b43_wldev *dev)
{
b43_radio_turn_off(dev, 1);
- b43_leds_exit(dev);
b43_gpio_cleanup(dev);
/* firmware is released later */
}
@@ -2193,11 +2192,10 @@ static int b43_chip_init(struct b43_wlde
err = b43_gpio_init(dev);
if (err)
goto out; /* firmware is released later */
- b43_leds_init(dev);
err = b43_upload_initvals(dev);
if (err)
- goto
[PATCH] b43: Fix for broken transmission
This patch fixes the transmission problems introduced by
commit f04b3787bbce4567e28069a9ec97dcd804626ac7
I'm not sure if the dummy read is really required.
The old code does it. I think it can't hurt and can possibly
fix some write posting problems (hardware bugs or whatever. Who knows).
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/wa.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/wa.c 2007-12-11
01:08:40.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/wa.c 2007-12-11 13:35:26.0
+0100
@@ -123,10 +123,16 @@ static void b43_wa_rssi_lt(struct b43_wl
{
int i;
+#if 0
for (i = 0; i 8; i++)
b43_ofdmtab_write16(dev, B43_OFDMTAB_RSSI, i, i + 8);
for (i = 8; i 16; i++)
b43_ofdmtab_write16(dev, B43_OFDMTAB_RSSI, i, i - 8);
+#endif
+ /* FIXME: Current specs are wrong. The following loop matches the
+* old specs, which works great on my device. --mb */
+ for (i = 0; i 64; i++)
+ b43_ofdmtab_write16(dev, B43_OFDMTAB_RSSI, i, i);
}
static void b43_wa_analog(struct b43_wldev *dev)
@@ -306,16 +312,16 @@ static void b43_wa_crs_ed(struct b43_wld
struct b43_phy *phy = dev-phy;
if (phy-rev == 1) {
- b43_phy_write(dev, B43_PHY_CRSTHRES1, 0x4F19);
+ b43_phy_write(dev, B43_PHY_CRSTHRES1_R1, 0x4F19);
} else if (phy-rev == 2) {
- b43_phy_write(dev, B43_PHY_CRSTHRES1_R1, 0x1861);
- b43_phy_write(dev, B43_PHY_CRSTHRES2_R1, 0x1861);
+ b43_phy_write(dev, B43_PHY_CRSTHRES1, 0x1861);
+ b43_phy_write(dev, B43_PHY_CRSTHRES2, 0x0271);
b43_phy_write(dev, B43_PHY_ANTDWELL,
b43_phy_read(dev, B43_PHY_ANTDWELL)
| 0x0800);
} else {
- b43_phy_write(dev, B43_PHY_CRSTHRES1_R1, 0x0098);
- b43_phy_write(dev, B43_PHY_CRSTHRES2_R1, 0x0070);
+ b43_phy_write(dev, B43_PHY_CRSTHRES1, 0x0098);
+ b43_phy_write(dev, B43_PHY_CRSTHRES2, 0x0070);
b43_phy_write(dev, B43_PHY_OFDM(0xC9), 0x0080);
b43_phy_write(dev, B43_PHY_ANTDWELL,
b43_phy_read(dev, B43_PHY_ANTDWELL)
@@ -441,7 +447,7 @@ static void b43_wa_altagc(struct b43_wld
}
}
b43_phy_write(dev, B43_PHY_DIVSRCHIDX,
- (b43_phy_read(dev, B43_PHY_DIVSRCHIDX) 0x7F7F) | 0x7874);
+ (b43_phy_read(dev, B43_PHY_DIVSRCHIDX) 0x8080) | 0x7874);
b43_phy_write(dev, B43_PHY_OFDM(0x8E), 0x1C00);
if (phy-rev == 1) {
b43_phy_write(dev, B43_PHY_DIVP1P2GAIN,
@@ -466,6 +472,7 @@ static void b43_wa_altagc(struct b43_wld
b43_phy_write(dev, B43_PHY_OFDM(0x26),
b43_phy_read(dev, B43_PHY_OFDM(0x26)) ~0x1000);
}
+ b43_phy_read(dev, B43_PHY_VERSION_OFDM); /* Dummy read */
}
static void b43_wa_tr_ltov(struct b43_wldev *dev) /* TR Lookup Table Original
Values */
Index: wireless-2.6/drivers/net/wireless/b43/phy.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/phy.h2007-12-11
01:08:40.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/phy.h 2007-12-11 12:57:40.0
+0100
@@ -25,7 +25,7 @@ struct b43_phy;
#define B43_PHY_BBANDCFG_RXANT0x180 /* RX Antenna selection
*/
#define B43_PHY_BBANDCFG_RXANT_SHIFT 7
#define B43_PHY_PWRDOWNB43_PHY_OFDM(0x03) /*
Powerdown */
-#define B43_PHY_CRSTHRES1 B43_PHY_OFDM(0x06) /* CRS
Threshold 1 */
+#define B43_PHY_CRSTHRES1_R1 B43_PHY_OFDM(0x06) /* CRS
Threshold 1 (phy.rev 1 only) */
#define B43_PHY_LNAHPFCTL B43_PHY_OFDM(0x1C) /* LNA/HPF
control */
#define B43_PHY_LPFGAINCTL B43_PHY_OFDM(0x20) /* LPF Gain
control */
#define B43_PHY_ADIVRELATEDB43_PHY_OFDM(0x27) /* FIXME rename
*/
@@ -69,8 +69,8 @@ struct b43_phy;
#define B43_PHY_DIVP1P2GAINB43_PHY_OFDM(0xAB)
#define B43_PHY_DIVSRCHGAINBACKB43_PHY_OFDM(0xAD) /*
Divider search gain back */
#define B43_PHY_DIVSRCHGAINCHNGB43_PHY_OFDM(0xAE) /*
Divider search gain change */
-#define B43_PHY_CRSTHRES1_R1 B43_PHY_OFDM(0xC0) /* CRS
Threshold 1 (rev 1 only) */
-#define B43_PHY_CRSTHRES2_R1 B43_PHY_OFDM(0xC1) /* CRS
Threshold 2 (rev 1 only) */
+#define B43_PHY_CRSTHRES1 B43_PHY_OFDM(0xC0) /* CRS
Threshold 1 (phy.rev = 2 only) */
+#define B43_PHY_CRSTHRES2 B43_PHY_OFDM(0xC1) /* CRS
Threshold 2 (phy.rev = 2 only) */
#define B43_PHY_TSSIP_LTBASE B43_PHY_OFDM(0x380) /* TSSI power
lookup
