Re: [PATCH] b43: Fix for broken transmission
On Wednesday 12 December 2007 19:50:11 Michael Buesch wrote: 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] Ah, crap. This was the wrong one. Give me a second and I will send the correct one. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH #2] 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 16:18:44.0
+0100
@@ -123,17 +123,24 @@ static void b43_wa_rssi_lt(struct b43_wl
{
int i;
- 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);
+ if (0 /* FIXME: For APHY.rev=2 this might be needed */) {
+ 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);
+ } else {
+ for (i = 0; i 64; i++)
+ b43_ofdmtab_write16(dev, B43_OFDMTAB_RSSI, i, i);
+ }
}
static void b43_wa_analog(struct b43_wldev *dev)
{
struct b43_phy *phy = dev-phy;
+ u16 ofdmrev;
- if (phy-analog 2) {
+ ofdmrev = b43_phy_read(dev, B43_PHY_VERSION_OFDM) B43_PHYVER_VERSION;
+ if (ofdmrev 2) {
if (phy-type == B43_PHYTYPE_A)
b43_phy_write(dev, B43_PHY_PWRDOWN, 0x1808);
else
@@ -306,16 +313,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 +448,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 +473,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 14:07:59.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
Re: Operation wpa_driver_wext_set_countermeasures not supported
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) {
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:11:22:33:44:55
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:11:22:33:44:55
wlan0: authenticate with AP 00:11:22:33:44:55
wlan0: authenticate with AP 00:11:22:33:44:55
wlan0: authentication with AP 00:11:22:33:44:55 timed out
wlan0: no IPv6 routers present
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:11:22:33:44:55
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:11:22:33:44:55
wlan0: RX authentication from 00:11:22:33:44:55 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:11:22:33:44:55
wlan0: authentication frame received from 00:11:22:33:44:55, but not in
authenticate state - ignored
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)
What is reason 3 for disassociating?
WLAN_REASON_DEAUTH_LEAVING = 3,
But I don't know what LEAVING means in this case.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 regression
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. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH RFT] b43: Fix for broken transmission
This patch fixes the transmission problems introduced by
commit f04b3787bbce4567e28069a9ec97dcd804626ac7
It depends on
[PATCH] b43: Fix ofdmtab write regression
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).
Please test this.
NOT-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/ssb: sprom antenna fixes
Here are the antenna related fixes for the sprom.
--
Greetings Michael.
Index: wireless-2.6/drivers/ssb/pci.c
===
--- wireless-2.6.orig/drivers/ssb/pci.c 2007-12-09 21:35:20.0 +0100
+++ wireless-2.6/drivers/ssb/pci.c 2007-12-09 22:16:39.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, SSB_SPROM4_AGAIN0_SHIFT);
+ SPEX(antenna_gain.ghz24.a1, SSB_SPROM4_AGAIN01,
+ SSB_SPROM4_AGAIN1, SSB_SPROM4_AGAIN1_SHIFT);
+ SPEX(antenna_gain.ghz24.a2, SSB_SPROM4_AGAIN23,
+ SSB_SPROM4_AGAIN2, SSB_SPROM4_AGAIN2_SHIFT);
+ SPEX(antenna_gain.ghz24.a3, SSB_SPROM4_AGAIN23,
+ SSB_SPROM4_AGAIN3, SSB_SPROM4_AGAIN3_SHIFT);
+ memcpy(out-antenna_gain.ghz5, out-antenna_gain.ghz24,
+ sizeof(out-antenna_gain.ghz5));
+
/* TODO - get remaining rev 4 stuff needed */
}
@@ -400,7 +456,7 @@ static int sprom_extract(struct ssb_bus
memset(out, 0, sizeof(*out));
out-revision = in[size - 1] 0x00FF;
- ssb_printk(KERN_INFO PFX SPROM revision %d detected.\n, out-revision);
+ ssb_dprintk(KERN_DEBUG PFX SPROM revision %d detected.\n, out-revision);
if ((bus-chip_id
Re: rfkill-input is not automatically loaded
On Monday 10 December 2007 18:08:12 Larry Finger wrote: Ivo and Dmitry, I have finally figured out why the b43 rfkill LED handling routine works on some systems, and not on others. It works as long as rfkill-input is built-in, or if the module is loaded, but this module is not automatically loaded even though rfkill.ko has been loaded, and rfkill-toggle_radio points to a valid routine. Of course, that routine is never called. I'm sure there is a way to force loading of this module, but I have not figured it out. I would appreciate any pointers. I'd say the drivers (b43) should try to load and pin the module. Failure to do so should not interrupt loading the driver and registering the rfkill switch, though. See request_module(). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: rfkill-input is not automatically loaded
On Monday 10 December 2007 18:17:38 Michael Buesch wrote: On Monday 10 December 2007 18:08:12 Larry Finger wrote: Ivo and Dmitry, I have finally figured out why the b43 rfkill LED handling routine works on some systems, and not on others. It works as long as rfkill-input is built-in, or if the module is loaded, but this module is not automatically loaded even though rfkill.ko has been loaded, and rfkill-toggle_radio points to a valid routine. Of course, that routine is never called. I'm sure there is a way to force loading of this module, but I have not figured it out. I would appreciate any pointers. I'd say the drivers (b43) should try to load and pin the module. Ok, well. Probably not pin it. But load it. Failure to do so should not interrupt loading the driver and registering the rfkill switch, though. See request_module(). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T V2] b43: Fix rfkill radio LED
On Monday 10 December 2007 18:23:21 Larry Finger wrote: This version of the rfkill switch patch is pretty straight forward. Please comment on the dropping of wl-mutex before rfkill initialization. This is the only way I could avoid the circular locking without a much earlier rfkill initialization. I think that's not acceptable, as it introduces a nasty (although unlikely) race condition with the band switch. I will think about it and will fix it myself then. If there's no way to properly fix it, I think it may also be OK to live with this damn unlikely race. Please also add the call to request_module() into the rfkill init and test if it works properly. After that, please send the complete patch back to me and I will try to fix the locking issue. Anyway, this patch looks nice. Good work. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 continues to have issue with APs at times
On Sunday 09 December 2007 09:01:26 John H. wrote: no, i stopped using ndiswrapper a while back because I wanted to use b43, but I did not have this issue then. But ndiswrapper doesn't use mac80211, right? Do you see this issue with other _mac80211_ drivers? On Dec 8, 2007 2:35 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 08 December 2007 21:22:37 John H. wrote: I have this problem at two different locations with two different access points. 2.6.23.1 kernel, and sometimes until I actually power down the AP and restart it, wpa_supplicant and such just times out on the AP. Any ideas? I think that's rather a mac80211 or supplicant issue. I think roaming should handle this. Do you see this with other drivers, too? -- Greetings Michael. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: SPROM rev 4
On Sunday 09 December 2007 12:31:40 Michael Gerdau wrote: Can you send me the code you have? I am going to buy various N devices. So I want to avoid duplicating work. Yes, sure. I'll do a bit of cleaning up and mail it to you (either tonight or tomorrow). I also have a few areas where I feel I'm stuck (this being my very first kernel/driver project ever) and I obviously would highly appreciate comments. Last not least I am still not too fluent with using git, especially git in combination with quilt, so please bear with me here as well. Great. It would be great if you have some time to further continue development on the driver. We always need new developers who know what they do. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix ofdmtab write regression
commit f04b3787bbce4567e28069a9ec97dcd804626ac7 introduced
a regression for the ofdmtable writing.
It incorrectly removed the writing of the high 16bits for
a 32bit table write and initialized the direction identifier
too late.
This patch does also some cleanups to make the code much more
readable and adds a few comments, so non rocket scientists are
also able to understand what this address caching is all about.
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-09
20:50:43.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/b43.h 2007-12-09 20:56:55.0
+0100
@@ -545,12 +545,18 @@
u16 initval;//FIXME rename?
- /* OFDM address read/write caching for hardware auto-increment. */
- u16 ofdm_addr;
- u8 ofdm_valid; /* 0: invalid, 1: read, 2: write */
-
/* PHY TX errors counter. */
atomic_t txerr_cnt;
+
+ /* The device does address auto increment for the OFDM tables.
+* We cache the previously used address here and omit the address
+* write on the next table access, if possible. */
+ u16 ofdmtab_addr; /* The address currently set in hardware. */
+ enum { /* The last data flow direction. */
+ B43_OFDMTAB_DIRECTION_UNKNOWN = 0,
+ B43_OFDMTAB_DIRECTION_READ,
+ B43_OFDMTAB_DIRECTION_WRITE,
+ } ofdmtab_addr_direction;
};
/* Data structures for DMA transmission, per 80211 core. */
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-12-09
20:50:43.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-12-09
21:01:27.0 +0100
@@ -2266,12 +2266,6 @@
b43_write16(dev, B43_MMIO_POWERUP_DELAY,
dev-dev-bus-chipco.fast_pwrup_delay);
- /* OFDM address caching. */
- phy-ofdm_valid = 0;
-
- /* PHY TX errors counter. */
- atomic_set(phy-txerr_cnt, B43_PHY_TX_BADNESS_LIMIT);
-
err = 0;
b43dbg(dev-wl, Chip initialized\n);
out:
@@ -3198,6 +3192,12 @@
phy-channel = 0xFF;
phy-hardware_power_control = !!modparam_hwpctl;
+
+ /* PHY TX errors counter. */
+ atomic_set(phy-txerr_cnt, B43_PHY_TX_BADNESS_LIMIT);
+
+ /* OFDM-table address caching. */
+ phy-ofdmtab_addr_direction = B43_OFDMTAB_DIRECTION_UNKNOWN;
}
static void setup_struct_wldev_for_init(struct b43_wldev *dev)
Index: wireless-2.6/drivers/net/wireless/b43/tables.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/tables.c 2007-12-09
20:50:43.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/tables.c 2007-12-09
20:55:01.0 +0100
@@ -381,13 +381,17 @@
u16 addr;
addr = table + offset;
- if (addr - 1 != phy-ofdm_addr || phy-ofdm_valid != 1) {
+ if ((phy-ofdmtab_addr_direction != B43_OFDMTAB_DIRECTION_READ) ||
+ (addr - 1 != phy-ofdmtab_addr)) {
+ /* The hardware has a different address in memory. Update it. */
b43_phy_write(dev, B43_PHY_OTABLECTL, addr);
- phy-ofdm_valid = 1;
+ phy-ofdmtab_addr_direction = B43_OFDMTAB_DIRECTION_READ;
}
- phy-ofdm_addr = addr;
+ phy-ofdmtab_addr = addr;
return b43_phy_read(dev, B43_PHY_OTABLEI);
+
+ /* Some compiletime assertions... */
assert_sizes();
}
@@ -398,11 +402,13 @@
u16 addr;
addr = table + offset;
- if (addr - 1 != phy-ofdm_addr || phy-ofdm_valid != 2) {
+ if ((phy-ofdmtab_addr_direction != B43_OFDMTAB_DIRECTION_WRITE) ||
+ (addr -1 != phy-ofdmtab_addr)) {
+ /* The hardware has a different address in memory. Update it. */
b43_phy_write(dev, B43_PHY_OTABLECTL, addr);
- phy-ofdm_valid = 2;
+ phy-ofdmtab_addr_direction = B43_OFDMTAB_DIRECTION_WRITE;
}
- phy-ofdm_addr = addr;
+ phy-ofdmtab_addr = addr;
b43_phy_write(dev, B43_PHY_OTABLEI, value);
}
@@ -413,11 +419,13 @@
u16 addr;
addr = table + offset;
- if (addr - 1 != phy-ofdm_addr || phy-ofdm_valid != 1) {
+ if ((phy-ofdmtab_addr_direction != B43_OFDMTAB_DIRECTION_READ) ||
+ (addr - 1 != phy-ofdmtab_addr)) {
+ /* The hardware has a different address in memory. Update it. */
b43_phy_write(dev, B43_PHY_OTABLECTL, addr);
- phy-ofdm_valid = 1;
+ phy-ofdmtab_addr_direction = B43_OFDMTAB_DIRECTION_READ;
}
- phy-ofdm_addr = addr;
+ phy-ofdmtab_addr = addr;
ret = b43_phy_read(dev, B43_PHY_OTABLEQ);
ret = 16
Re: SPROM rev 4
On Sunday 09 December 2007 00:22:19 Larry Finger wrote: Michael Buesch wrote: Hi Larry, Do you have the data from a SPROM revision 4? I need a copy to fix some things. And do you know a device which includes a rev 4 SPROM? I'd like to buy one. The data from a program dump are as follows: SPROM r4 dump 0x: 0x2801 0x 0x0009 0x1028 0x 0x0DBE 0xFF00 0x2BC4 0x0010: 0x2A64 0x2964 0x2C64 0x3CE7 0x 0x 0x 0x 0x0020: 0x4328 0x8000 0x0002 0x 0x1001 0x1800 0x 0x 0x0030: 0x 0x 0x 0x 0x 0x 0x 0x 0x0040: 0x5372 0x004C 0x4A01 0x 0x0004 0x 0x0019 0x7DA5 0x0050: 0x1912 0x 0x0001 0x83FF 0x 0x 0x0303 0x0202 0x0060: 0x 0x3437 0x5B5B 0x1420 0x5B5B 0x0D0C 0x5B5B 0x1A1E 0x0070: 0x5B5B 0x3844 0x3838 0x 0x 0x 0x 0x 0x0080: 0x3E4E 0xFEC6 0x15D3 0xFB3D 0x 0x3E3C 0x3C3C 0xFE6C 0x0090: 0x1664 0xFA7B 0x 0xFE37 0x1401 0xFAE7 0x 0xFE5A 0x00A0: 0x147E 0xFAC7 0x 0x 0x 0x 0x 0x3E4E 0x00B0: 0xFEC1 0x15BC 0xFB2F 0x 0x3E3C 0x3C3C 0xFE69 0x1608 0x00C0: 0xFA81 0x 0xFE2A 0x1321 0xFB0B 0x 0xFE66 0x1595 0x00D0: 0xFA88 0x 0x 0x 0x 0x 0x 0x 0x00E0: 0x 0x 0x 0x 0x 0x 0x 0x 0x00F0: 0x 0x 0x 0x 0x 0x 0x 0x 0x0100: 0x 0x 0x 0x 0x 0x 0x 0x 0x0110: 0x 0x 0x 0x 0x 0x 0x 0x 0x0120: 0x 0x 0x 0x 0x 0x 0x 0x 0x0130: 0x 0x 0x 0x 0x 0x 0x 0x 0x0140: 0x 0x 0x 0x 0x 0x 0x 0x 0x0150: 0x 0x 0x 0x 0x 0x 0x 0x 0x0160: 0x 0x 0x 0x 0x 0x 0x 0x 0x0170: 0x 0x 0x 0x 0x 0x 0x 0x 0x0180: 0x 0x 0x 0x 0x 0x 0x 0x 0x0190: 0x 0x 0x 0x 0x 0x 0x 0x 0x01A0: 0x 0x 0x 0x 0x 0x 0x 0x 0x01B0: 0x 0x 0x 0x9404 The only device that I know has this SPROM is a BCM4328 mini PCIe card that is in a Dell XPS M1710 laptop owned by Michael Gerdau. The lspci -v output is 0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 01) Subsystem: Dell Unknown device 0009 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at ecffc000 (64-bit, non-prefetchable) [size=16K] Memory at e000 (64-bit, prefetchable) [size=1M] Capabilities: [40] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [d0] Express Endpoint IRQ 0 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [15c] Power Budgeting Gerdau has been working on implementation of some of the code defined in the 802.11n PHY section of the specs. I pointed him in the right direction, but have not seen his recent stuff so as not to taint the driver from RE info. Cool, Thanks. Michael: Can you send me the code you have? I am going to buy various N devices. So I want to avoid duplicating work. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Microcode reverse engineering
On Tuesday 04 December 2007 14:51:50 Holger Schurig wrote: It could also be the case that the opcodes on the website aren't opcodes to a real CPU, Broadcom calls this a Programmable State Machine. But what is this all about? Why do you care what type of CPU this is? Does this matter _at_ _all_? I mean, we know all opcodes of the device and we have a _complete_ disassembler and assembler. http://git.bu3sch.de/git/b43-tools.git What do you want more? The only thing we don't completely understand are the various device registers and device status codes (external jumps) used. But that has nothing to do with the type of the CPU used. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Microcode reverse engineering
On Tuesday 04 December 2007 18:13:01 Stefano Brivio wrote: If you could put your efforts on writing specs for firmware operation (i.e. not the instruction set, but what exactly does the firmware do) or writing an open firmware based upon the info I listed above (you can do that, there's an Italian 'fair use' law, so if you reverse engineer and code together for compatibility purposes only, it's perfectly legal), it would be just great. We are short on people here. I just can't do any reverse engineering because I would get tainted (me too I live in Italy, but I'm working with other people who are based elsewhere), same for Michael, and we couldn't go on with driver development then. I'm willing to help with a firmware rewrite (that wouldn't taint me, as long as I'm given clean specs), and your work on reverse engineering would be greatly appreciated then. That interoperability (or compatibility) clause also exists in Germany, but we decided to _not_ make use of it, as it's basically undefined what interoperability is. And I don't want to trigger the precedence case at court for this. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFT] [PATCH v4] b43: fix calc_nrssi_slope
On Thursday 29 November 2007 22:06:54 Stefano Brivio wrote: Fix calc_nrssi_slope() which caused PHY TX errors on devices containing a 802.11a PHY. The code is synced to v4 specs and relevant registers are renamed accordingly. Signed-off-by: Stefano Brivio [EMAIL PROTECTED] --- That patch looks good, though I did not test it, yet. John, please don't apply this, yet. It needs a lot more testing on several different devices. In the past we had this kind of rewrite patches already improve one device and completely break another. So, people, please try this and check if it causes any regressions. Thanks. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix radio LED problem
On Thursday 29 November 2007 00:48:40 Larry Finger wrote:
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
@@ -60,8 +60,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 */
Ok, nice. Didn't know that.
+ 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. */
@@ -133,6 +137,12 @@ 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;
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c
+++ wireless-2.6/drivers/net/wireless/b43/main.c
@@ -2156,7 +2156,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 */
}
@@ -2184,11 +2183,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);
@@ -2267,8 +2265,7 @@ out:
err_radio_off:
b43_radio_turn_off(dev, 1);
-err_leds_exit:
- b43_leds_exit(dev);
+err_gpio_clean:
b43_gpio_cleanup(dev);
return err;
}
@@ -2703,7 +2700,8 @@ static int b43_antenna_from_ieee80211(u8
static int b43_op_config(struct ieee80211_hw *hw, struct ieee80211_conf
*conf)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
- struct b43_wldev *dev;
+ struct b43_rfkill *rfk = (wl-rfkill);
+ struct b43_wldev *uninitialized_var(dev);
struct b43_phy *phy;
unsigned long flags;
unsigned int new_phymode = 0x;
@@ -2802,6 +2800,13 @@ static int b43_op_config(struct ieee8021
out_unlock_mutex:
mutex_unlock(wl-mutex);
+ /* if a LED is devoted to the radio and the switch is on, send
+ * KEY_WLAN press/release keystrokes */
+ if (!err dev-radio_hw_enable dev-led_radio) {
^^^
This condition is always true.
+ input_report_key(rfk-poll_dev-input, KEY_WLAN, 1);
+ input_report_key(rfk-poll_dev-input, KEY_WLAN, 0);
+ }
+
Anyway, sending a key event here seems pretty bogus. The comment
doesn't really say anything useful why this is needed.
return err;
}
@@ -3284,9 +3289,7 @@ static void b43_wireless_core_exit(struc
return;
b43_set_status(dev, B43_STAT_UNINIT);
- mutex_unlock(dev-wl-mutex);
- b43_rfkill_exit(dev);
- mutex_lock(dev-wl-mutex);
+ b43_leds_exit(dev);
b43_rng_exit(dev-wl);
b43_pio_free(dev);
@@ -3409,8 +3412,8 @@ static int b43_wireless_core_init(struct
memset(wl-mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
- b43_rfkill_init(dev);
b43_rng_init(wl);
+ b43_leds_init(dev);
b43_set_status(dev, B43_STAT_INITIALIZED);
@@ -3503,6 +3506,7 @@ static int b43_op_start(struct ieee80211
int did_init = 0;
int err = 0;
+ b43_rfkill_init(dev);
Init rfkill _after_ the device is up.
mutex_lock(wl-mutex);
if (b43_status(dev) B43_STAT_INITIALIZED) {
@@ -3537,6 +3541,7 @@ static void b43_op_stop(struct ieee80211
b43_wireless_core_stop(dev);
b43_wireless_core_exit(dev);
mutex_unlock(wl-mutex);
+ b43_rfkill_exit(dev);
Exit rfkill before the device is going down.
}
static int b43_op_set_retry_limit(struct ieee80211_hw *hw,
Index: wireless-2.6/drivers/net/wireless/b43/leds.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/leds.c
+++
Re: [RFC/T V2] b43: Fix Radio On/Off LED action
On Tuesday 27 November 2007 22:22:22 Larry Finger wrote:
I'm wondering who causes this deadlock. registered should be false if
we are called back from rfkill_initialize, so it should return early before
the lock.
The following code has the competing lock:
static int rfkill_toggle_radio(struct rfkill *rfkill,
enum rfkill_state state)
{
int retval;
retval = mutex_lock_interruptible(rfkill-mutex);
if (retval)
return retval;
if (state != rfkill-state) {
retval = rfkill-toggle_radio(rfkill-data, state);
if (!retval) {
rfkill-state = state;
rfkill_led_trigger(rfkill, state);
}
}
mutex_unlock(rfkill-mutex);
return retval;
}
So it's a lock dependency between rfkill-mutex and wl-mutex?
So, now comes the question that really matters. Who is the caller
of rfkill_toggle_radio, in the case where it crashes?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T V2] b43: Fix Radio On/Off LED action
On Wednesday 28 November 2007 16:05:35 Larry Finger wrote:
Michael Buesch wrote:
So it's a lock dependency between rfkill-mutex and wl-mutex?
So, now comes the question that really matters. Who is the caller
of rfkill_toggle_radio, in the case where it crashes?
Here is the full dump. It looks to me as if b43_rfkill_soft_toggle() calls
rfkill_handler(), which
calls rfkill_toggle_radio() and it is calling b43_rfkill_soft_toggle(). I'd
call that a loop.
I think it's a different bug. The backtrace seems corrupted.
Can you try this patch? There is some circular locking in rfkill.
Index: wireless-2.6/net/rfkill/rfkill.c
===
--- wireless-2.6.orig/net/rfkill/rfkill.c 2007-11-20 19:09:35.0
+0100
+++ wireless-2.6/net/rfkill/rfkill.c2007-11-28 17:09:55.0 +0100
@@ -60,11 +60,7 @@ static void rfkill_led_trigger(struct rf
static int rfkill_toggle_radio(struct rfkill *rfkill,
enum rfkill_state state)
{
- int retval;
-
- retval = mutex_lock_interruptible(rfkill-mutex);
- if (retval)
- return retval;
+ int retval = 0;
if (state != rfkill-state) {
retval = rfkill-toggle_radio(rfkill-data, state);
@@ -74,7 +70,6 @@ static int rfkill_toggle_radio(struct rf
}
}
- mutex_unlock(rfkill-mutex);
return retval;
}
@@ -158,12 +153,13 @@ static ssize_t rfkill_state_store(struct
if (!capable(CAP_NET_ADMIN))
return -EPERM;
+ if (mutex_lock_interruptible(rfkill-mutex))
+ return -ERESTARTSYS;
error = rfkill_toggle_radio(rfkill,
state ? RFKILL_STATE_ON : RFKILL_STATE_OFF);
- if (error)
- return error;
+ mutex_unlock(rfkill-mutex);
- return count;
+ return error ? error : count;
}
static ssize_t rfkill_claim_show(struct device *dev,
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Simple 'fix' for radio switch LED regression
On Wednesday 28 November 2007 16:38:27 Larry Finger wrote:
Since addition of the rfkill callback, the LED associated with the off/on
switch on the radio has not worked because essential data in the rfkill
structure is missing. When that problem was fixed, difficulties in circular
locking surfaced. This patch fixes part of the regression in that the LED
is turned on if the radio switch is on at startup. Adding the code to toggle
the LED with the switch will be more involved and would likely miss the 2.6.24
window.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John and Michael,
I was able to get the full functionality working, but with two significant
problems: (1) the LED toggled only with a switch off-on sequence, not with
each switch change and (2) the module would no longer unload cleanly due to
circular locking. I will be essentually off-line after today, and I hope that
this hack, which will make the LED appear to work correctly, can be pushed
into 2.6.24 as it is a fix, but has minimal code impact. Nearly all of the
changes are needed just to make the LED on routine available to startup.
Furthermore, I'm certain these changes will be needed when the complete fix
is available.
That completely shortcuts the behaviour logic.
This patch trades one bug for another.
It will get other people upset, because their LEDs don't work as expected
anymore.
This is not a showstopper bug and there is no need to introduce dirty
fixes that trade one bug for another.
I'm pretty sure that this patch will break LEDs on my asus card. I didn't
try that, though.
Please don't apply this. We have enough time to develop the correct solution
to this problem.
leds.c |3 +--
leds.h |1 +
main.c |3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c
+++ wireless-2.6/drivers/net/wireless/b43/main.c
@@ -51,6 +51,7 @@
#include xmit.h
#include lo.h
#include pcmcia.h
+#include leds.h
MODULE_DESCRIPTION(Broadcom B43 wireless driver);
MODULE_AUTHOR(Martin Langer);
@@ -2799,6 +2797,8 @@ static int b43_op_config(struct ieee8021
b43_interrupt_enable(dev, savedirqs);
mmiowb();
spin_unlock_irqrestore(wl-irq_lock, flags);
+ if (dev-radio_hw_enable)
+ b43_led_turn_on(dev, 1, 1);
out_unlock_mutex:
mutex_unlock(wl-mutex);
Index: wireless-2.6/drivers/net/wireless/b43/leds.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/leds.c
+++ wireless-2.6/drivers/net/wireless/b43/leds.c
@@ -30,8 +30,7 @@
#include leds.h
-static void b43_led_turn_on(struct b43_wldev *dev, u8 led_index,
- bool activelow)
+void b43_led_turn_on(struct b43_wldev *dev, u8 led_index, bool activelow)
{
struct b43_wl *wl = dev-wl;
unsigned long flags;
Index: wireless-2.6/drivers/net/wireless/b43/leds.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/leds.h
+++ wireless-2.6/drivers/net/wireless/b43/leds.h
@@ -44,6 +44,7 @@ enum b43_led_behaviour {
void b43_leds_init(struct b43_wldev *dev);
void b43_leds_exit(struct b43_wldev *dev);
+void b43_led_turn_on(struct b43_wldev *dev, u8 led_index, bool activelow);
#else /* CONFIG_B43_LEDS */
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Simple 'fix' for radio switch LED regression
On Wednesday 28 November 2007 17:18:53 Larry Finger wrote: Michael Buesch wrote: On Wednesday 28 November 2007 16:38:27 Larry Finger wrote: Since addition of the rfkill callback, the LED associated with the off/on switch on the radio has not worked because essential data in the rfkill structure is missing. When that problem was fixed, difficulties in circular locking surfaced. This patch fixes part of the regression in that the LED is turned on if the radio switch is on at startup. Adding the code to toggle the LED with the switch will be more involved and would likely miss the 2.6.24 window. Signed-off-by: Larry Finger [EMAIL PROTECTED] --- John and Michael, I was able to get the full functionality working, but with two significant problems: (1) the LED toggled only with a switch off-on sequence, not with each switch change and (2) the module would no longer unload cleanly due to circular locking. I will be essentually off-line after today, and I hope that this hack, which will make the LED appear to work correctly, can be pushed into 2.6.24 as it is a fix, but has minimal code impact. Nearly all of the changes are needed just to make the LED on routine available to startup. Furthermore, I'm certain these changes will be needed when the complete fix is available. That completely shortcuts the behaviour logic. This patch trades one bug for another. It will get other people upset, because their LEDs don't work as expected anymore. This is not a showstopper bug and there is no need to introduce dirty fixes that trade one bug for another. I'm pretty sure that this patch will break LEDs on my asus card. I didn't try that, though. Please try the patch at least enough to see if it breaks the LEDs on your card. I don't think it will. There's no need to try this. Let's summerize what we have and what your patch does: We have a _nonconstant_ mapping of LEDs to LED behaviours. This mapping is done in the SPROM or in a special function which takes card types and revisions and assigns the behaviour to the LED. So the rfkill LED could be _any_ LED in the LED iospace. What your patch does now is to hardcode the LED to LED index 1 with an activelow capability. Why LED 1? Why activelow? Because this is the case in your particular type of b43 card. My asus card has two LEDs. One has a link is up, aka associated and a transmitting data LED. I don't know from the top of my head which indices those LEDs are, but let's simply assume they are index 0 and 1. (Remember this mapping is random and specific to the hardware). So what we do is poke with some random LED. Also, I'm pretty sure that these LEDs on my card are activehigh. So if your patch is applied to such a card it will and up with a nonworking LED. That's what we wanted to fix in the first place, right? ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T V2] b43: Fix Radio On/Off LED action
On Wednesday 28 November 2007 17:41:42 Larry Finger wrote: Michael Buesch wrote: I think it's a different bug. The backtrace seems corrupted. Can you try this patch? There is some circular locking in rfkill. I still get circular locking. The dump is Ok. b43 init: mutex_lock(wl-mutex) rfkill_init() mutex_lock(rfkill-mutex) in operation: rfkill poll (no locks held) calls into rfkill mutex_lock(rfkill-mutex) b43_rfkill_soft_toggle() mutex_lock(wl-mutex) As you can see the lock ordering of the two mutexes is different. The problem is that we cannot easily drop the wl-mutex on b43 init, as that would introduce some race conditions. This is specific to b43 and rt2x00 most likely doesn't have this requirement. I'm not sure how to properly fix this. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
On Monday 26 November 2007 23:15:53 Larry Finger wrote:
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to drivers/net/wireless/b43/rfkill.c as
follows:
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
@@ -133,6 +133,16 @@ 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 = input_allocate_device();
+ if (!rfk-poll_dev-input)
+ goto err_free_polldev;
+
+ 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);
+
Ehm, you saw a few lines above that we do
input_allocate_polled_device()?
101 struct input_polled_dev *input_allocate_polled_device(void)
102 {
103 struct input_polled_dev *dev;
104
105 dev = kzalloc(sizeof(struct input_polled_dev), GFP_KERNEL);
106 if (!dev)
107 return NULL;
108
109 dev-input = input_allocate_device();
110 if (!dev-input) {
111 kfree(dev);
112 return NULL;
113 }
114
115 return dev;
116 }
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: Fix Radio On/Off LED action
On Tuesday 27 November 2007 17:03:57 Larry Finger wrote:
Since addition of the rfkill callback, the LED associated with the off
switch on the radio has not worked because essential data in the rfkill
structure was missing. This hack adds the necessary data and places direct
calls to turn the leds on/off.
Signed-off-by: Larry Finger [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
@@ -23,6 +23,7 @@
*/
#include rfkill.h
+#include leds.h
#include b43.h
@@ -57,6 +58,10 @@ static void b43_rfkill_poll(struct input
report_change = 1;
b43info(wl, Radio hardware status changed to %s\n,
enabled ? ENABLED : DISABLED);
+ if (enabled)
+ b43_led_turn_on(dev, 1, 1);
+ else
+ b43_led_turn_off(dev, 1, 1);
}
mutex_unlock(wl-mutex);
This is not how led triggers work.
You are shortcutting the whole thing here. So you could as well
remove the whole rfkill and LEDs code.
Please properly register the LED in the leds code and
add a default LED trigger for the rfkill trigger.
This has several advantages to the user, among the possiblility to
reassign a LED to a different trigger.
@@ -70,11 +75,13 @@ static int b43_rfkill_soft_toggle(void *
struct b43_wldev *dev = data;
struct b43_wl *wl = dev-wl;
int err = 0;
+ int lock = mutex_is_locked(wl-mutex);
if (!wl-rfkill.registered)
return 0;
- mutex_lock(wl-mutex);
+ if (!lock)
+ mutex_lock(wl-mutex);
Nah, it shouldn't be locked by current in the first place, here.
(I guess that's what you are trying to check here).
That's what the !registered check above is for.
This !lock check is racy.
B43_WARN_ON(b43_status(dev) B43_STAT_INITIALIZED);
switch (state) {
case RFKILL_STATE_ON:
@@ -93,7 +100,8 @@ static int b43_rfkill_soft_toggle(void *
break;
}
out_unlock:
- mutex_unlock(wl-mutex);
+ if (!lock)
+ mutex_unlock(wl-mutex);
return err;
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: Fix Radio On/Off LED action
On Tuesday 27 November 2007 17:28:33 Larry Finger wrote: Michael Buesch wrote: On Tuesday 27 November 2007 17:03:57 Larry Finger wrote: This is not how led triggers work. You are shortcutting the whole thing here. So you could as well remove the whole rfkill and LEDs code. It just plain doesn't work now. What I'm trying to do is get something to the users that will restore the behavior they want while we work out the details of the rfkill and LEDs code. Well, ok. But we don't apply this to mainline. As a temporary patch for users it's OK. Please properly register the LED in the leds code and add a default LED trigger for the rfkill trigger. This has several advantages to the user, among the possiblility to reassign a LED to a different trigger. How do I do that? Well, what you basically have to do it restore the old mapping in b43_map_led(). Look at the case B43_LED_RADIO_ALL (and below) statement. It maps these LEDs to the rfkill trigger. So you have to find out which behaviour value your LED has and map that to the rfkill trigger in this function. So when the rfkill LED trigger triggers, it will enable/disable this LED. That's all done behind the scenes. @@ -70,11 +75,13 @@ static int b43_rfkill_soft_toggle(void * struct b43_wldev *dev = data; struct b43_wl *wl = dev-wl; int err = 0; + int lock = mutex_is_locked(wl-mutex); if (!wl-rfkill.registered) return 0; - mutex_lock(wl-mutex); + if (!lock) + mutex_lock(wl-mutex); Nah, it shouldn't be locked by current in the first place, here. (I guess that's what you are trying to check here). That's what the !registered check above is for. This !lock check is racy. If you recall my message from yesterday, I got a locking error. That is what I'm trying to prevent. I know it is racy, but I don't know the correct way to do it. I think RFkill has a bad design regarding this. It does synchronously call back into the driver from a call made by the driver. That is broken by design. Maybe it's best to fix this in rfkill and let it asynchronously call back on rfkill_init. Synchronous callbacks from calls made by drivers are broken by design and will lead to recursive lockings. We can not fix this in the driver, nor work around it in a sane way. We can hack around it, though, which is what the !registered flag tries to do. Though, it seems it doesn't work. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
On Tuesday 27 November 2007 19:33:41 Larry Finger wrote: Ivo van Doorn wrote: Hi, On Monday 26 November 2007 23:15:53 Larry Finger wrote: Based on the code in the rtx200 directories that has a call to input_allocate_device() that was not present in b43, I made a modification to drivers/net/wireless/b43/rfkill.c as follows: 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 @@ -133,6 +133,16 @@ 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 = input_allocate_device(); +if (!rfk-poll_dev-input) +goto err_free_polldev; + +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); + Ehm, you saw a few lines above that we do input_allocate_polled_device()? I had not investigated the details of input_allocate_polled_device(). The part that was missing in b43 is the initialization of the rfk-poll_dev-input data. I will be posting a patch/hack that restores the LED behavior that we had before the rfkill code went in. The concept of input_allocate_polled_device() was misintepretet by me as well, but when allocating the polled device, you also must allocate a input device seperately and make sure the poll_dev-input pointer is initialized. Otherwise the polled dev registration will fail. My testing shows that the separate input_allocate_device call is not needed - only the initialization is required. BTW, there is a bug in rt2x00rfkill.c. Where? It is not a bug as much as redundant code. It is a memory leak in rt2x00rfkill.c, as the structure is allocated twice. Ivo, look at the code of input_allocate_polled_device(). It already allocates the input dev. I posted a patch to clean up the code, which went to the wireless mailing list and to rt2400-dev. Sorry, I forgot to include you. Larry -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T V2] b43: Fix Radio On/Off LED action
On Tuesday 27 November 2007 21:02:47 Larry Finger wrote: Michael, I'm getting a little closer. The problem I discovered now is that b43_leds_init() was being called before b43_rfkill_init(), which prevented registration of the radio LED. Now, the LED is flashed on for about 1 second, then it goes off. Changing the switch does nothing. Ok, good catch. Is the switch properly polled and is the status change properly reported upstream? If yes, you might want to check (add printk to rfkill code) if the LED is properly triggered. This version uses mutex_trylock() to see if the mutex is already locked. It should do until rfkill is fixed. No it doesn't. This still introduces a race. I'm wondering who causes this deadlock. registered should be false if we are called back from rfkill_initialize, so it should return early before the lock. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
On Monday 26 November 2007 02:26:38 Larry Finger wrote: Michael and Ivo, I have done a little looking into the problem of the radio LED not coming on, and have found the following: 1. The call-back routine b43_rfkill_soft_toggle() is called once. When called, rfkill.registered is zero and the routine exits immediately. 2. The call-back routine b43_rfkill_poll() is never called, and the switch that controls the radio is never tested. 3. There is a log message input: Unspecified device as /class/input/input7, which I think arises from the rfkill registration. I have the necessary hardware and am willing to test any suggested changes. Larry Dunno. That's a poll-input-dev problem then. Do you have all poll-input options enabled? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V3] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Monday 26 November 2007 15:38:11 Larry Finger wrote:
The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:
(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to the supported list.
(3) Change the 2-bit routing code for address extensions to 0b10 rather
than the 0b01 used for the 32-bit case.
(4) Remove some magic numbers in the DMA setup.
The DMA implementation for this chip supports full 64-bit addressing with
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to Bias the placement of kernel pages at lower PFNs. When
commit 44048d70 reverted that code, the DMA error appeared. As a fix,
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
this problem is thought to arise from a hardware error.
This patch has been tested on my system, and by Cédric Caumont
[EMAIL PROTECTED] and by Matthieu PATOU [EMAIL PROTECTED] on a BCM4312.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring-dev-dev-dev;
+ gfp_t flags = GFP_KERNEL;
+ /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
+ * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
+ * has shown that 4K is sufficient for the latter as long as the buffer
+ * does not cross an 8K boundary.
+ *
+ * For unknown reasons - possibly a hardware error - the BCM4311 rev
+ * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
+ * which accounts for the GFP_DMA flag below.
+ */
+ if (ring-dma64)
+ flags = GFP_DMA;
Whoops, didn't notice this before. This needs to be
flags |= GFP_DMA;
ring-descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
- (ring-dmabase), GFP_KERNEL);
+ (ring-dmabase), flags);
if (!ring-descbase) {
b43err(ring-dev-wl, DMA ringmemory allocation failed\n);
return -ENOMEM;
The rest is acked.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V4] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Monday 26 November 2007 17:00:06 Larry Finger wrote:
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring-dev-dev-dev;
+ gfp_t flags = GFP_KERNEL;
+ /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
+ * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
+ * has shown that 4K is sufficient for the latter as long as the buffer
+ * does not cross an 8K boundary.
+ *
+ * For unknown reasons - possibly a hardware error - the BCM4311 rev
+ * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
+ * which accounts for the GFP_DMA flag below.
+ */
+ if (ring-dma64)
+ flags = GFP_DMA;
???
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: include FCS in frames handed to mac80211
From: Johannes Berg [EMAIL PROTECTED]
Sometimes it can be useful to see the FCS, especially when
bad-FCS frames are shown. Pass the FCS to mac80211 and let
it worry about snipping it off when required.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/main.c |3 ++-
drivers/net/wireless/b43/xmit.c |1 -
2 files changed, 2 insertions(+), 2 deletions(-)
--- everything.orig/drivers/net/wireless/b43/main.c 2007-11-22
23:35:41.208716199 +0100
+++ everything/drivers/net/wireless/b43/main.c 2007-11-22 23:36:03.138677951
+0100
@@ -4158,7 +4158,8 @@ static int b43_wireless_init(struct ssb_
}
/* fill hw info */
- hw-flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE;
+ hw-flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
+ IEEE80211_HW_RX_INCLUDES_FCS;
hw-max_signal = 100;
hw-max_rssi = -110;
hw-max_noise = -110;
--- everything.orig/drivers/net/wireless/b43/xmit.c 2007-11-22
23:36:05.668676810 +0100
+++ everything/drivers/net/wireless/b43/xmit.c 2007-11-22 23:36:22.668677190
+0100
@@ -489,7 +489,6 @@ void b43_rx(struct b43_wldev *dev, struc
}
wlhdr = (struct ieee80211_hdr *)(skb-data);
fctl = le16_to_cpu(wlhdr-frame_control);
- skb_trim(skb, skb-len - FCS_LEN);
if (macstat B43_RX_MAC_DEC) {
unsigned int keyidx;
---
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Friday 23 November 2007 06:36:55 Larry Finger wrote:
Michael Buesch wrote:
partially acked.
Though, I'm not quite sure yet why you remove that
address extension bits. The specs clearly say that they _are_ there.
And it makes sense to use them, as two bytes of the address are used
for the routing stuff. So the highest 2 bits of the address have to be put
somewhere else. That's the Transmit Channel Control Word and
Receive Channel Control Word where 0x0003 are the extension bits.
The appropriate section of dmacontroller_setup() in my patched source is as
follows:
if (ring-tx) {
if (ring-dma64) {
u64 ringbase = (u64) (ring-dmabase);
b43_dma_write(ring, B43_DMA64_TXCTL,
B43_DMA64_TXENABLE);
b43_dma_write(ring, B43_DMA64_TXRINGLO,
(ringbase 0x));
b43_dma_write(ring, B43_DMA64_TXRINGHI,
(ringbase 32));
} else {
.. untouched 32-bit stuff
}
} else {
err = alloc_initial_descbuffers(ring);
if (err)
goto out;
if (ring-dma64) {
u64 ringbase = (u64) (ring-dmabase);
value = (ring-frameoffset B43_DMA64_RXFROFF_SHIFT)
| B43_DMA64_RXENABLE;
b43_dma_write(ring, B43_DMA64_RXCTL, value);
b43_dma_write(ring, B43_DMA64_RXRINGLO,
(ringbase 0x));
b43_dma_write(ring, B43_DMA64_RXRINGHI,
(ringbase 32));
b43_dma_write(ring, B43_DMA64_RXINDEX, ring-nr_slots
*
sizeof(struct b43_dmadesc64));
} else {
... 32-bit stuff
}
No address extensions are used here because the specs clearly state that a
flat 64-bit address is
used to specify the Descriptor Ring address. My code matches the specs.
I'm not sure which specifications you use, but here it clearly describes the
extension bits:
http://bcm-v4.sipsolutions.net/802.11/DMA#TransmitChannelControlWord-1
However I do think that this might be related to the bug you are explaining
in the comment:
+ * For unknown reasons - possibly a hardware error - the BCM4311 rev
+ * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
+ * which accounts for the GFP_DMA flag below.
the error, and that part does not use any extension bits. Secondly, the
address extension stuff
would only apply if my computer had more than 2^(62) bytes of RAM, which is
something like 10
billion GB - an amount that probably exceeds the total RAM in the world.
This is not true. We live in a world with IO-MMUs.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: include full 64-bit timestamp in monitor mode
From: Johannes Berg [EMAIL PROTECTED]
When monitor mode is enabled, this will make b43 read out the
full 64-bit MAC time from the chip for each received packet.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/b43.h |2 ++
drivers/net/wireless/b43/main.c |2 ++
drivers/net/wireless/b43/xmit.c | 18 +-
3 files changed, 21 insertions(+), 1 deletion(-)
--- everything.orig/drivers/net/wireless/b43/b43.h 2007-11-22
22:56:20.648678709 +0100
+++ everything/drivers/net/wireless/b43/b43.h 2007-11-22 23:03:27.268675020
+0100
@@ -635,6 +635,8 @@ struct b43_wl {
/* List of all wireless devices on this chip */
struct list_head devlist;
u8 nr_devs;
+
+ bool radiotap_enabled;
};
/* Pointers to the firmware data and meta information about it. */
--- everything.orig/drivers/net/wireless/b43/main.c 2007-11-22
22:55:49.608678981 +0100
+++ everything/drivers/net/wireless/b43/main.c 2007-11-22 23:03:53.678676051
+0100
@@ -2853,6 +2853,8 @@ static int b43_op_config(struct ieee8021
b43_short_slot_timing_disable(dev);
}
+ dev-wl-radiotap_enabled = !!(conf-flags IEEE80211_CONF_RADIOTAP);
+
/* Adjust the desired TX power level. */
if (conf-power_level != 0) {
if (conf-power_level != phy-power_level) {
--- everything.orig/drivers/net/wireless/b43/xmit.c 2007-11-22
22:54:33.498725965 +0100
+++ everything/drivers/net/wireless/b43/xmit.c 2007-11-22 23:15:44.808681966
+0100
@@ -526,7 +526,23 @@ void b43_rx(struct b43_wldev *dev, struc
else
status.rate = b43_plcp_get_bitrate_cck(plcp);
status.antenna = !!(phystat0 B43_RX_PHYST0_ANT);
- status.mactime = mactime;
+
+ /*
+* If monitors are present get full 64-bit timestamp. This
+* code assumes we get to process the packet within 16 bits
+* of timestamp, i.e. about 65 milliseconds after the PHY
+* received the first symbol.
+*/
+ if (dev-wl-radiotap_enabled) {
+ u16 low_mactime_now;
+
+ b43_tsf_read(dev, status.mactime);
+ low_mactime_now = status.mactime;
+ status.mactime = status.mactime ~0xULL;
+ status.mactime += mactime;
+ if (low_mactime_now = mactime)
+ status.mactime -= 0x1;
+ }
chanid = (chanstat B43_RX_CHAN_ID) B43_RX_CHAN_ID_SHIFT;
switch (chanstat B43_RX_CHAN_PHYTYPE) {
---
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43-fwcutter: unsupported file support
On Friday 23 November 2007 12:17:26 Johannes Berg wrote: This patch makes fwcutter support only those files we know are working and marks the other one unsupported. To allow developers to still work with such files, an --unsupported command line option is added that allows one to extract firmware from such unsupported files. Some code restructuring was necessary to support the --unsupported flag with other flags in any order. Also, because this is a significant change, bump the version number. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Applied, thanks. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Wednesday 21 November 2007 22:38:12 Larry Finger wrote:
The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
has not been supported until now. The changes include the following:
(1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
(2) Add PHY revision 9 to the supported list.
(3) Fix 64-bit addressing errors.
(4) Remove some magic numbers in the DMA setup.
The DMA implementation for this chip supports full 64-bit addressing with
one exception. Whenever the Descriptor Ring Buffer is in high memory, a
fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
to code to Bias the placement of kernel pages at lower PFNs. When
commit 44048d70 reverted that code, the DMA error appeared. As a fix,
use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
this problem is thought to arise from a hardware error.
This patch has been tested on my system and by Cédric Caumont
[EMAIL PROTECTED].
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch is intended for the everything branch of wireless-2.6.
Larry
---
dma.c | 50 ++
main.c |3 ++-
wa.c |1 +
3 files changed, 29 insertions(+), 25 deletions(-)
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
+++ wireless-2.6/drivers/net/wireless/b43/dma.c
@@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
addrhi = (((u64) dmaaddr 32) ~SSB_DMA_TRANSLATION_MASK);
addrext = (((u64) dmaaddr 32) SSB_DMA_TRANSLATION_MASK)
SSB_DMA_TRANSLATION_SHIFT;
- addrhi |= ssb_dma_translation(ring-dev-dev);
+ addrhi |= (ssb_dma_translation(ring-dev-dev) 1);
if (slot == ring-nr_slots - 1)
ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
if (start)
@@ -426,9 +426,21 @@ static inline
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring-dev-dev-dev;
+ gfp_t flags = GFP_KERNEL;
+ /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
+ * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
+ * has shown that 4K is sufficient for the latter as long as the buffer
+ * does not cross an 8K boundary.
+ *
+ * For unknown reasons - possibly a hardware error - the BCM4311 rev
+ * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
+ * which accounts for the GFP_DMA flag below.
+ */
+ if (ring-dma64)
+ flags = GFP_DMA;
ring-descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
- (ring-dmabase), GFP_KERNEL);
+ (ring-dmabase), flags);
if (!ring-descbase) {
b43err(ring-dev-wl, DMA ringmemory allocation failed\n);
return -ENOMEM;
@@ -483,7 +495,7 @@ int b43_dmacontroller_rx_reset(struct b4
return 0;
}
-/* Reset the RX DMA channel */
+/* Reset the TX DMA channel */
int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int
dma64)
{
int i;
@@ -636,18 +648,12 @@ static int dmacontroller_setup(struct b4
if (ring-dma64) {
u64 ringbase = (u64) (ring-dmabase);
- addrext = ((ringbase 32) SSB_DMA_TRANSLATION_MASK)
- SSB_DMA_TRANSLATION_SHIFT;
- value = B43_DMA64_TXENABLE;
- value |= (addrext B43_DMA64_TXADDREXT_SHIFT)
- B43_DMA64_TXADDREXT_MASK;
- b43_dma_write(ring, B43_DMA64_TXCTL, value);
+ b43_dma_write(ring, B43_DMA64_TXCTL,
+ B43_DMA64_TXENABLE);
b43_dma_write(ring, B43_DMA64_TXRINGLO,
(ringbase 0x));
b43_dma_write(ring, B43_DMA64_TXRINGHI,
- ((ringbase 32)
-~SSB_DMA_TRANSLATION_MASK)
- | trans);
+ (ringbase 32));
} else {
u32 ringbase = (u32) (ring-dmabase);
@@ -668,20 +674,15 @@ static int dmacontroller_setup(struct b4
if (ring-dma64) {
u64 ringbase = (u64) (ring-dmabase);
- addrext = ((ringbase 32) SSB_DMA_TRANSLATION_MASK)
- SSB_DMA_TRANSLATION_SHIFT;
- value = (ring-frameoffset B43_DMA64_RXFROFF_SHIFT);
- value |= B43_DMA64_RXENABLE;
- value |= (addrext B43_DMA64_RXADDREXT_SHIFT)
- B43_DMA64_RXADDREXT_MASK;
+
Re: [PATCH v3] remove bcm43xx
On Wednesday 21 November 2007 00:26:48 Rafael J. Wysocki wrote: On Tuesday, 20 of November 2007, Michael Buesch wrote: On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote: Having both drivers in 2.6.24 should help find out if there's anything which should be ironed out with b43/b43legacy, but right now they are already working a lot better than bcm43xx, and they are more stable. So I couldn't find a reason why we shouldn't remove bcm43xx in 2.6.25. Many people use the old driver and you are forcing them to switch in a rather unfriendly fashion. Moreover, the switch generally involves a configuration change (on my system eth1 became wlan0) and is not _that_ seamless. IMvHO, the schedule of the removal of this driver should be discussed on LKML. Ok, so we are going to add Rafael J. Wysocki as the bcm43xx maintainer and remove everyone else. I'm OK with that. [That wasn't nice.] Exactly. _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more. Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be dropped anyway after some time - when no one uses it any more. Still, it need not be (and IMHO it shouldn't be) your decision to drop it. Who is responsible to do that decision, if the driver authors that wrote all the code aren't? I'd be very happy to shift bcm43xx maintainership to someone else, but there is _nobody_ who wants to do it. Face it. Nobody wants bcm43xx anymore. And the only sane way to handle this is to run one release cycle with both drivers included and remove the old driver after that. bcm43xx is basically dropped since a year and everybody who cares knows that. And nobody cares to maintain that piece of junk in the future. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: schedule bcm43xx removal for 2.6.26 -- Re: [PATCH v3] remove bcm43xx
On Wednesday 21 November 2007 14:59:27 John W. Linville wrote: On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote: On Tuesday, 20 of November 2007, Michael Buesch wrote: It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to replace bcm43xx. And we already do a parrallel release cycle with both drivers included so people can switch. What else do you want? _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more. Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be dropped anyway after some time - when no one uses it any more. Still, it need not be (and IMHO it shouldn't be) your decision to drop it. It is probably true that we haven't communicated this very well outside the wireless team. We probably should have added bcm43xx to the feature removal schedule before the 2.6.24 merge window closed. How about if we mark bcm43xx as Obsolete in MAINTAINERS and add an entry to Documentation/feature-removal-schedule.txt with a When of 2.6.26? I think that should give everyone sufficient notice...? So, is SoftMAC already scheduled? Otherwise, I think when we are about to remove bcm43xx in 2.6.25 someone is going to complain that removal of softmac was not scheduled... Btw: Does someone actually read that feature-removal-schedule.txt file? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v3] remove bcm43xx
On Monday 19 November 2007 23:36:44 Andreas Schwab wrote: b43 still does not work at all on ppc. This is absolutely _wrong_. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v3] remove bcm43xx
On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote: Having both drivers in 2.6.24 should help find out if there's anything which should be ironed out with b43/b43legacy, but right now they are already working a lot better than bcm43xx, and they are more stable. So I couldn't find a reason why we shouldn't remove bcm43xx in 2.6.25. Many people use the old driver and you are forcing them to switch in a rather unfriendly fashion. Moreover, the switch generally involves a configuration change (on my system eth1 became wlan0) and is not _that_ seamless. IMvHO, the schedule of the removal of this driver should be discussed on LKML. Ok, so we are going to add Rafael J. Wysocki as the bcm43xx maintainer and remove everyone else. I'm OK with that. It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to replace bcm43xx. And we already do a parrallel release cycle with both drivers included so people can switch. What else do you want? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [Bug 9414] Not work light of button-led with module b43 in chipset broadcom 4318
On Tuesday 20 November 2007 05:46:28 Larry Finger wrote: [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9414 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Michael, Just like this guy, the light on my wireless switch does not work, and has not since the rfkill logic was changed. I have been too busy to complain; however, the issue needs to ba addressed. How does one supply the necessary information so that the light will be changed as the switch is moved? I don't know. You must tell me what kind of LED this is. There is a LED trigger in rfkill. You just have to hook that up to the LED. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v3] remove bcm43xx
On Tuesday 20 November 2007 15:11:07 Andreas Schwab wrote: Michael Buesch [EMAIL PROTECTED] writes: On Monday 19 November 2007 23:36:44 Andreas Schwab wrote: b43 still does not work at all on ppc. This is absolutely _wrong_. Of course it is wrong, but apparently the only way to get attention to a blocker bug. I didn't hear about your bug before. Are you using latest driver from wireless-2.6 and the officially supported firmware version from 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 v3] remove bcm43xx
On Tuesday 20 November 2007 16:09:27 Larry Finger wrote:
Andreas Schwab wrote:
Stefano Brivio [EMAIL PROTECTED] writes:
--- drivers/net/wireless/b43/main.c.orig2007-11-20
01:12:12.186524483 +0100
+++ drivers/net/wireless/b43/main.c 2007-11-20 01:12:34.922702865 +0100
@@ -947,7 +947,7 @@
while (1) {
v0 = b43_read32(dev, B43_MMIO_XMITSTAT_0);
- if (!(v0 0x0001))
+ if (!v0)
break;
v1 = b43_read32(dev, B43_MMIO_XMITSTAT_1);
(probably it's not the solution, I just want to see what happens then).
That didn't change anything.
BTW, what firmware are you using?
It's 410.2160 from wl_ap.o.
Please try version 351.126 from
http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2,
which is the officially supported version.
There was some minor API change for newer firmware.
I think the TX and RX header layout slightly changed. I'll address that
later, as it's not too important now. (Or if someone else does want
to fix it, please send some patches...)
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] remove bcm43xx
On Monday 19 November 2007 17:12:17 Stefano Brivio wrote: Remove bcm43xx. Fix some left-over URLs and ifdefs in b43 and b43legacy drivers. Stefano, please send the fixes for b43 and b43legacy as a seperate patch, as they have to go into 2.6.24. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix compilation errors in ssb
On Friday 16 November 2007 07:48:23 Larry Finger wrote: Recent changes in ssb sprom handling break compilation. These two patches fix the problem. Signed-off-by: Larry Finger [EMAIL PROTECTED] --- John, These two changes should be applied to the everything branch of wireless-2.6 ASAP. Sorry about the mixup - I have no idea what happened. are your sprom r4 changes already applied? I didn't test that in the b44, yet. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: Implement the BCM94311MCG rev 02 card with a rev 13 802.11 core
On Thursday 15 November 2007 06:55:42 Larry Finger wrote:
This patch file will enable the usage of the b43 driver with the
BCM94311MCG wlan mini-PCI (rev 02), which has not been supported.
This PCIe card uses 64-bit DMA. Most of the changes were needed
to implement this mode. It has been tested on the x86_64 architecture,
but should work on all platforms. FYI, full 64-bit DMA addressing
is implemented and the driver should work with a full 2^(64) bytes
of RAM. No, I have not tested that feature!
This patch is intended to be applied to the everything branch of
the wireless-2.6 git tree. For it to work, the set of 6 patches to
modify the SPROM handling code of ssb that I recently submitted must
be applied as well.
There is one anomaly with the code. When it initializes the DMA, and
enables interrupts for the first time, a single PHY TX Error is
generated. I have code to suppress that error message; however, it was
in the bottom-half interrupt handler, and I'm still trying to fix it
in less critical code.
The commitment text is shown below:
Index: wireless-2.6/drivers/net/wireless/b43/dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
+++ wireless-2.6/drivers/net/wireless/b43/dma.c
@@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
addrhi = (((u64) dmaaddr 32) ~SSB_DMA_TRANSLATION_MASK);
addrext = (((u64) dmaaddr 32) SSB_DMA_TRANSLATION_MASK)
SSB_DMA_TRANSLATION_SHIFT;
- addrhi |= ssb_dma_translation(ring-dev-dev);
+ addrhi |= (ssb_dma_translation(ring-dev-dev) 1);
if (slot == ring-nr_slots - 1)
ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
if (start)
Wait, this looks broken to me. It looks like the bug is more
inside of the ssb_dma_translation function, rather than here.
@@ -426,14 +426,15 @@ static inline
static int alloc_ringmemory(struct b43_dmaring *ring)
{
struct device *dev = ring-dev-dev-dev;
+ int size = (ring-dma64) ? 8192 : B43_DMA_RINGMEMSIZE;
Uhm, a page is also 4k in x86_64?
Why doesn't using a page here work? What does happen?
- ring-descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
+ ring-descbase = dma_alloc_coherent(dev, size,
(ring-dmabase), GFP_KERNEL);
if (!ring-descbase) {
b43err(ring-dev-wl, DMA ringmemory allocation failed\n);
return -ENOMEM;
}
- memset(ring-descbase, 0, B43_DMA_RINGMEMSIZE);
+ memset(ring-descbase, 0, size);
return 0;
}
@@ -483,7 +484,7 @@ int b43_dmacontroller_rx_reset(struct b4
return 0;
}
-/* Reset the RX DMA channel */
+/* Reset the TX DMA channel */
int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int
dma64)
{
int i;
@@ -636,18 +637,13 @@ static int dmacontroller_setup(struct b4
if (ring-dma64) {
u64 ringbase = (u64) (ring-dmabase);
- addrext = ((ringbase 32) SSB_DMA_TRANSLATION_MASK)
- SSB_DMA_TRANSLATION_SHIFT;
- value = B43_DMA64_TXENABLE;
- value |= (addrext B43_DMA64_TXADDREXT_SHIFT)
- B43_DMA64_TXADDREXT_MASK;
- b43_dma_write(ring, B43_DMA64_TXCTL, value);
+ b43_dma_write(ring, B43_DMA64_TXCTL,
+ B43_DMA64_TXENABLE);
Ehm, why are you removing this?
b43_dma_write(ring, B43_DMA64_TXRINGLO,
(ringbase 0x));
b43_dma_write(ring, B43_DMA64_TXRINGHI,
((ringbase 32)
-~SSB_DMA_TRANSLATION_MASK)
- | trans);
+0x));
Huh?
} else {
u32 ringbase = (u32) (ring-dmabase);
@@ -668,20 +664,16 @@ static int dmacontroller_setup(struct b4
if (ring-dma64) {
u64 ringbase = (u64) (ring-dmabase);
- addrext = ((ringbase 32) SSB_DMA_TRANSLATION_MASK)
- SSB_DMA_TRANSLATION_SHIFT;
- value = (ring-frameoffset B43_DMA64_RXFROFF_SHIFT);
- value |= B43_DMA64_RXENABLE;
- value |= (addrext B43_DMA64_RXADDREXT_SHIFT)
- B43_DMA64_RXADDREXT_MASK;
+ value = (ring-frameoffset B43_DMA64_RXFROFF_SHIFT)
+ | B43_DMA64_RXENABLE;
b43_dma_write(ring, B43_DMA64_RXCTL, value);
b43_dma_write(ring, B43_DMA64_RXRINGLO,
(ringbase 0x));
b43_dma_write(ring, B43_DMA64_RXRINGHI,
Re: [RFC/T] b43: Implement the BCM94311MCG rev 02 card with a rev 13 802.11 core
On Thursday 15 November 2007 16:02:48 Larry Finger wrote: @@ -695,11 +687,12 @@ static int dmacontroller_setup(struct b4 b43_dma_write(ring, B43_DMA32_RXRING, (ringbase ~SSB_DMA_TRANSLATION_MASK) | trans); - b43_dma_write(ring, B43_DMA32_RXINDEX, 200); + b43_dma_write(ring, B43_DMA32_RXINDEX, ring-nr_slots * +sizeof(struct b43_dmadesc32)); I'm not sure why you do this change. It took me a while to figure out where the magic number of 200 came from, and what I needed for the 64-bit case. In fact I think the 200 is a bug and should be 0x200. To me, this change makes it clearer. The 200 is just a random number. I think we don't really care what the value is. (Except zero, which doesn't work on some devices). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: silence a bogus gcc warning
On Sunday 11 November 2007 10:27:03 Frank Lichtenheld wrote: On Sat, Nov 10, 2007 at 05:27:43PM +0100, Michael Buesch wrote: On Saturday 10 November 2007 16:25:33 John W. Linville wrote: On Sat, Nov 10, 2007 at 04:14:03PM +0100, Michael Buesch wrote: From: Frank Lichtenheld [EMAIL PROTECTED] inititalise ret to 0 to avoid the following bogus warning: CC [M] drivers/net/wireless/b43/debugfs.o drivers/net/wireless/b43/debugfs.c: In function ‘b43_debugfs_read’: drivers/net/wireless/b43/debugfs.c:355: warning: ‘ret’ may be used uninitialized in this function Signed-off-by: Frank Lichtenheld [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Isn't this what uninitialized_var() is for? Erh, I didn't actually knew that existed, sorry. OTOH in this case it is actually longer to write. I'd be OK with that, too. Should I send a changed patch? Yes. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: silence a bogus gcc warning
From: Frank Lichtenheld [EMAIL PROTECTED] inititalise ret to 0 to avoid the following bogus warning: CC [M] drivers/net/wireless/b43/debugfs.o drivers/net/wireless/b43/debugfs.c: In function ‘b43_debugfs_read’: drivers/net/wireless/b43/debugfs.c:355: warning: ‘ret’ may be used uninitialized in this function Signed-off-by: Frank Lichtenheld [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- drivers/net/wireless/b43/debugfs.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/b43/debugfs.c b/drivers/net/wireless/b43/debugfs.c index 734e70e..d8ac058 100644 --- a/drivers/net/wireless/b43/debugfs.c +++ b/drivers/net/wireless/b43/debugfs.c @@ -352,7 +352,7 @@ static ssize_t b43_debugfs_read(struct file *file, char __user *userbuf, struct b43_wldev *dev; struct b43_debugfs_fops *dfops; struct b43_dfs_file *dfile; - ssize_t ret; + ssize_t ret = 0; char *buf; const size_t bufsize = 1024 * 128; const size_t buforder = get_order(bufsize); -- 1.5.3.4 --- -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Output message at startup if hardware switch for radio is off
On Friday 09 November 2007 23:47:37 Larry Finger wrote: Now that the radio is controlled by rfkill, there is a potential difficulty in helping a new user get started, as it is unlikely that they will have setup rfkill. This patch prints a message if the interface is started with the hardware switch off. Signed-off-by: Larry Finger [EMAIL PROTECTED] --- John, This patch is intended for the everything branch of wireless-2.6. Larry Well... Pressing the rfkill button is the _FIRST_ thing that I would do, if the device does not work. I'm wondering why people have a problem with that. On other operating systems it's the very same. On Windows there is no dmesg. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: silence a bogus gcc warning
On Saturday 10 November 2007 16:25:33 John W. Linville wrote: On Sat, Nov 10, 2007 at 04:14:03PM +0100, Michael Buesch wrote: From: Frank Lichtenheld [EMAIL PROTECTED] inititalise ret to 0 to avoid the following bogus warning: CC [M] drivers/net/wireless/b43/debugfs.o drivers/net/wireless/b43/debugfs.c: In function ‘b43_debugfs_read’: drivers/net/wireless/b43/debugfs.c:355: warning: ‘ret’ may be used uninitialized in this function Signed-off-by: Frank Lichtenheld [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Isn't this what uninitialized_var() is for? I'd be OK with that, too. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: fix shared IRQ race condition
On Wednesday 07 November 2007 18:16:11 Stefano Brivio wrote: Fix an IRQ race condition in b43. If we call b43_stop_wireless_core(), it will set the status of the device to INITIALIZED and the IRQ handler won't care any longer about IRQs, thus the kernel will disable the IRQ if it's shared (unless we boot it with the 'irqpoll' option). So we must disable IRQs before changing the device status. Signed-off-by: Stefano Brivio [EMAIL PROTECTED] --- --- wireless-2.6/drivers/net/wireless/b43/main.c.orig 2007-11-07 17:55:30.553591943 +0100 +++ wireless-2.6/drivers/net/wireless/b43/main.c 2007-11-07 17:59:23.356020048 +0100 @@ -2979,6 +2979,16 @@ if (b43_status(dev) B43_STAT_STARTED) return; + + /* Disable and sync interrupts. We must do this before than + * setting the status to INITIALIZED, as the interrupt handler + * won't care about IRQs then. */ + spin_lock_irqsave(wl-irq_lock, flags); + dev-irq_savedstate = b43_interrupt_disable(dev, B43_IRQ_ALL); + b43_read32(dev, B43_MMIO_GEN_IRQ_MASK); /* flush */ + spin_unlock_irqrestore(wl-irq_lock, flags); + b43_synchronize_irq(dev); + b43_set_status(dev, B43_STAT_INITIALIZED); mutex_unlock(wl-mutex); @@ -2989,13 +2999,6 @@ ieee80211_stop_queues(wl-hw); //FIXME this could cause a deadlock, as mac80211 seems buggy. - /* Disable and sync interrupts. */ - spin_lock_irqsave(wl-irq_lock, flags); - dev-irq_savedstate = b43_interrupt_disable(dev, B43_IRQ_ALL); - b43_read32(dev, B43_MMIO_GEN_IRQ_MASK); /* flush */ - spin_unlock_irqrestore(wl-irq_lock, flags); - b43_synchronize_irq(dev); - b43_mac_suspend(dev); free_irq(dev-dev-irq, dev); b43dbg(wl, Wireless interface stopped\n); 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: Fix PCMCIA-host lowlevel bus access
This fixes the lowlevel bus access routines for
PCMCIA based devices.
There are still a few issues with register access sideeffects after
this patch. This will be addressed in a later patch.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/ssb/pcmcia.c
===
--- wireless-2.6.orig/drivers/ssb/pcmcia.c 2007-11-06 18:19:27.0
+0100
+++ wireless-2.6/drivers/ssb/pcmcia.c 2007-11-07 15:48:37.0 +0100
@@ -63,17 +63,17 @@ int ssb_pcmcia_switch_coreidx(struct ssb
err = pcmcia_access_configuration_register(pdev, reg);
if (err != CS_SUCCESS)
goto error;
- read_addr |= (reg.Value 0xF) 12;
+ read_addr |= ((u32)(reg.Value 0x0F)) 12;
reg.Offset = 0x30;
err = pcmcia_access_configuration_register(pdev, reg);
if (err != CS_SUCCESS)
goto error;
- read_addr |= reg.Value 16;
+ read_addr |= ((u32)reg.Value) 16;
reg.Offset = 0x32;
err = pcmcia_access_configuration_register(pdev, reg);
if (err != CS_SUCCESS)
goto error;
- read_addr |= reg.Value 24;
+ read_addr |= ((u32)reg.Value) 24;
cur_core = (read_addr - SSB_ENUM_BASE) / SSB_CORE_SIZE;
if (cur_core == coreidx)
@@ -152,28 +152,29 @@ error:
goto out_unlock;
}
-/* These are the main device register access functions.
- * do_select_core is inline to have the likely hotpath inline.
- * All unlikely codepaths are out-of-line. */
-static inline int do_select_core(struct ssb_bus *bus,
-struct ssb_device *dev,
-u16 *offset)
+static int select_core_and_segment(struct ssb_device *dev,
+ u16 *offset)
{
+ struct ssb_bus *bus = dev-bus;
int err;
- u8 need_seg = (*offset = 0x800) ? 1 : 0;
+ u8 need_segment;
+
+ if (*offset = 0x800) {
+ *offset -= 0x800;
+ need_segment = 1;
+ } else
+ need_segment = 0;
if (unlikely(dev != bus-mapped_device)) {
err = ssb_pcmcia_switch_core(bus, dev);
if (unlikely(err))
return err;
}
- if (unlikely(need_seg != bus-mapped_pcmcia_seg)) {
- err = ssb_pcmcia_switch_segment(bus, need_seg);
+ if (unlikely(need_segment != bus-mapped_pcmcia_seg)) {
+ err = ssb_pcmcia_switch_segment(bus, need_segment);
if (unlikely(err))
return err;
}
- if (need_seg == 1)
- *offset -= 0x800;
return 0;
}
@@ -181,32 +182,31 @@ static inline int do_select_core(struct
static u16 ssb_pcmcia_read16(struct ssb_device *dev, u16 offset)
{
struct ssb_bus *bus = dev-bus;
- u16 x;
- if (unlikely(do_select_core(bus, dev, offset)))
+ if (unlikely(select_core_and_segment(dev, offset)))
return 0x;
- x = readw(bus-mmio + offset);
- return x;
+ return readw(bus-mmio + offset);
}
static u32 ssb_pcmcia_read32(struct ssb_device *dev, u16 offset)
{
struct ssb_bus *bus = dev-bus;
- u32 x;
+ u32 lo, hi;
- if (unlikely(do_select_core(bus, dev, offset)))
+ if (unlikely(select_core_and_segment(dev, offset)))
return 0x;
- x = readl(bus-mmio + offset);
+ lo = readw(bus-mmio + offset);
+ hi = readw(bus-mmio + offset + 2);
- return x;
+ return (lo | (hi 16));
}
static void ssb_pcmcia_write16(struct ssb_device *dev, u16 offset, u16 value)
{
struct ssb_bus *bus = dev-bus;
- if (unlikely(do_select_core(bus, dev, offset)))
+ if (unlikely(select_core_and_segment(dev, offset)))
return;
writew(value, bus-mmio + offset);
}
@@ -215,12 +215,12 @@ static void ssb_pcmcia_write32(struct ss
{
struct ssb_bus *bus = dev-bus;
- if (unlikely(do_select_core(bus, dev, offset)))
+ if (unlikely(select_core_and_segment(dev, offset)))
return;
- readw(bus-mmio + offset);
- writew(value 16, bus-mmio + offset + 2);
- readw(bus-mmio + offset);
- writew(value, bus-mmio + offset);
+ 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);
}
/* Not static, as it's used in main.c */
Index: wireless-2.6/drivers/ssb/main.c
===
--- wireless-2.6.orig/drivers/ssb/main.c2007-11-06 17:34:27.0
[PATCH] b43: properly request pcmcia IRQ
PCMCIA needs an additional step to request the IRQ. No need to add code to release the IRQ here, as that's done automatically in pcmcia_disable_device(). Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-2.6/drivers/net/wireless/b43/pcmcia.c === --- wireless-2.6.orig/drivers/net/wireless/b43/pcmcia.c 2007-11-07 15:54:21.0 +0100 +++ wireless-2.6/drivers/net/wireless/b43/pcmcia.c 2007-11-07 18:45:08.0 +0100 @@ -112,6 +112,14 @@ static int __devinit b43_pcmcia_probe(st if (res != CS_SUCCESS) goto err_disable; + dev-irq.Attributes = IRQ_TYPE_DYNAMIC_SHARING | IRQ_FIRST_SHARED; + dev-irq.IRQInfo1 = IRQ_LEVEL_ID | IRQ_SHARE_ID; + dev-irq.Handler = NULL; /* The handler is registered later. */ + dev-irq.Instance = NULL; + res = pcmcia_request_irq(dev, dev-irq); + if (res != CS_SUCCESS) + goto err_disable; + res = pcmcia_request_configuration(dev, dev-conf); if (res != CS_SUCCESS) goto err_disable; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43legacy: Fix sparse warning
Fix a sparse warning about a nonstatic function.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Note that this patch might collide with Stefano's recently
sent patches. But it should be trivial enough to fix that.
Index: wireless-2.6/drivers/net/wireless/b43legacy/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43legacy/main.c 2007-11-07
20:31:06.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43legacy/main.c 2007-11-07
20:47:36.0 +0100
@@ -3238,7 +3238,7 @@ out_mutex_unlock:
return err;
}
-void b43legacy_stop(struct ieee80211_hw *hw)
+static void b43legacy_stop(struct ieee80211_hw *hw)
{
struct b43legacy_wl *wl = hw_to_b43legacy_wl(hw);
struct b43legacy_wldev *dev = wl-current_dev;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix kconfig dependencies for rfkill and leds
Fix dependencies for built-in b43. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- I thought that I already submitted this patch, but it's not in wireless-2.6. Maybe it was lost somewhere inbetween us or I simply forgot to send it. Stefano, can you check if this patch is already applied to b43legacy? Index: wireless-2.6/drivers/net/wireless/b43/Kconfig === --- wireless-2.6.orig/drivers/net/wireless/b43/Kconfig 2007-10-27 13:28:16.0 +0200 +++ wireless-2.6/drivers/net/wireless/b43/Kconfig 2007-10-27 14:29:28.0 +0200 @@ -61,16 +61,18 @@ config B43_PCMCIA If unsure, say N. -# LED support +# This config option automatically enables b43 LEDS support, +# if it's possible. config B43_LEDS bool - depends on B43 MAC80211_LEDS + depends on B43 MAC80211_LEDS (LEDS_CLASS = y || LEDS_CLASS = B43) default y -# RFKILL support +# This config option automatically enables b43 RFKILL support, +# if it's possible. config B43_RFKILL bool - depends on B43 RFKILL RFKILL_INPUT INPUT_POLLDEV + depends on B43 (RFKILL = y || RFKILL = B43) RFKILL_INPUT (INPUT_POLLDEV = y || INPUT_POLLDEV = B43) default y config B43_DEBUG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43: pcmcia-host initialization bugfixes
Fix the initialization for PCMCIA devices.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/pcmcia.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/pcmcia.c 2007-11-04
12:45:10.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/pcmcia.c 2007-11-04
12:46:24.0 +0100
@@ -65,12 +65,12 @@ static int __devinit b43_pcmcia_probe(st
tuple_t tuple;
cisparse_t parse;
int err = -ENOMEM;
- int res;
+ int res = 0;
unsigned char buf[64];
ssb = kzalloc(sizeof(*ssb), GFP_KERNEL);
if (!ssb)
- goto out;
+ goto out_error;
err = -ENODEV;
tuple.DesiredTuple = CISTPL_CONFIG;
@@ -96,10 +96,12 @@ static int __devinit b43_pcmcia_probe(st
dev-io.NumPorts2 = 0;
dev-io.Attributes2 = 0;
- win.Attributes = WIN_MEMORY_TYPE_CM | WIN_ENABLE | WIN_USE_WAIT;
+ win.Attributes = WIN_ADDR_SPACE_MEM | WIN_MEMORY_TYPE_CM |
+WIN_ENABLE | WIN_DATA_WIDTH_16 |
+WIN_USE_WAIT;
win.Base = 0;
win.Size = SSB_CORE_SIZE;
- win.AccessSpeed = 1000;
+ win.AccessSpeed = 250;
res = pcmcia_request_window(dev, win, dev-win);
if (res != CS_SUCCESS)
goto err_kfree_ssb;
@@ -108,21 +110,26 @@ static int __devinit b43_pcmcia_probe(st
mem.Page = 0;
res = pcmcia_map_mem_page(dev-win, mem);
if (res != CS_SUCCESS)
- goto err_kfree_ssb;
+ goto err_disable;
res = pcmcia_request_configuration(dev, dev-conf);
if (res != CS_SUCCESS)
goto err_disable;
err = ssb_bus_pcmciabus_register(ssb, dev, win.Base);
+ if (err)
+ goto err_disable;
dev-priv = ssb;
- out:
- return err;
- err_disable:
+ return 0;
+
+err_disable:
pcmcia_disable_device(dev);
- err_kfree_ssb:
+err_kfree_ssb:
kfree(ssb);
+out_error:
+ printk(KERN_ERR b43-pcmcia: Initialization failed (%d, %d)\n,
+ res, err);
return err;
}
@@ -131,22 +138,21 @@ static void __devexit b43_pcmcia_remove(
struct ssb_bus *ssb = dev-priv;
ssb_bus_unregister(ssb);
- pcmcia_release_window(dev-win);
pcmcia_disable_device(dev);
kfree(ssb);
dev-priv = NULL;
}
static struct pcmcia_driver b43_pcmcia_driver = {
- .owner = THIS_MODULE,
- .drv = {
- .name = b43-pcmcia,
- },
- .id_table = b43_pcmcia_tbl,
- .probe = b43_pcmcia_probe,
- .remove = b43_pcmcia_remove,
- .suspend = b43_pcmcia_suspend,
- .resume = b43_pcmcia_resume,
+ .owner = THIS_MODULE,
+ .drv= {
+ .name = b43-pcmcia,
+ },
+ .id_table = b43_pcmcia_tbl,
+ .probe = b43_pcmcia_probe,
+ .remove = __devexit_p(b43_pcmcia_remove),
+ .suspend= b43_pcmcia_suspend,
+ .resume = b43_pcmcia_resume,
};
int b43_pcmcia_init(void)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 1 of 6] ssb: Add new SPROM structure while keeping the old
On Tuesday 06 November 2007 20:14:11 Larry Finger wrote:
This is patch 1 of 6.
The SPROM's for various devices utilizing the Sonics Silicon Backplane come
with various revisions. The Revision 2 SPROM inherited the data layout of 1,
and
Revision 3 inherited the layout of 2. The first instance of Revision 4 has
now been found in a BCM4328 wireless LAN card. This device does not inherit
any
layout from previous versions. Although it was possible to create a data
structure that kept all the old layouts, we decided to start fresh, keep only
those SPROM variables that are used by the drivers that utilize ssb, and to
do the conversion in such a manner that neither compilation or execution will
be affected if a bisection lands in the middle of these changes, while keeping
the patches as small as possible.
In this patch, the sprom structures are changed while maintaining the old
ones.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/include/linux/ssb/ssb.h
===
--- wireless-2.6.orig/include/linux/ssb/ssb.h
+++ wireless-2.6/include/linux/ssb/ssb.h
@@ -78,8 +78,32 @@ struct ssb_sprom_r3 {
u32 ofdmgpo;/* G-PHY OFDM Power Offset */
};
-struct ssb_sprom_r4 {
- /* TODO */
+struct ssb_sprom_data {
+ u8 il0mac[6]; /* MAC address for 802.11b/g */
+ u8 et0mac[6]; /* MAC address for Ethernet */
+ u8 et1mac[6]; /* MAC address for 802.11a */
+ u8 et0phyaddr:5;/* MII address for enet0 */
+ u8 et1phyaddr:5;/* MII address for enet1 */
While we are at it, please also get rid of these ugly foo:X bitfields.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 6 of 6] ssb: Remove the old, now unused, data structure
On Tuesday 06 November 2007 20:17:00 Larry Finger wrote:
Patch 6 of 6.
The old, now unused, data structures and SPROM extraction routines
are removed.
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
Index: wireless-2.6/include/linux/ssb/ssb.h
===
--- wireless-2.6.orig/include/linux/ssb/ssb.h
+++ wireless-2.6/include/linux/ssb/ssb.h
@@ -15,69 +15,6 @@ struct pcmcia_device;
struct ssb_bus;
struct ssb_driver;
-
-struct ssb_sprom_r1 {
- u16 pci_spid; /* Subsystem Product ID for PCI */
- u16 pci_svid; /* Subsystem Vendor ID for PCI */
- u16 pci_pid;/* Product ID for PCI */
- u8 il0mac[6]; /* MAC address for 802.11b/g */
- u8 et0mac[6]; /* MAC address for Ethernet */
- u8 et1mac[6]; /* MAC address for 802.11a */
- u8 et0phyaddr:5;/* MII address for enet0 */
- u8 et1phyaddr:5;/* MII address for enet1 */
- u8 et0mdcport:1;/* MDIO for enet0 */
- u8 et1mdcport:1;/* MDIO for enet1 */
- u8 board_rev; /* Board revision */
- u8 country_code:4; /* Country Code */
- u8 antenna_a:2; /* Antenna 0/1 available for A-PHY */
- u8 antenna_bg:2;/* Antenna 0/1 available for B-PHY and G-PHY */
- u16 pa0b0;
- u16 pa0b1;
- u16 pa0b2;
- u16 pa1b0;
- u16 pa1b1;
- u16 pa1b2;
- u8 gpio0; /* GPIO pin 0 */
- u8 gpio1; /* GPIO pin 1 */
- u8 gpio2; /* GPIO pin 2 */
- u8 gpio3; /* GPIO pin 3 */
- u16 maxpwr_a; /* A-PHY Power Amplifier Max Power (in dBm
Q5.2) */
- u16 maxpwr_bg; /* B/G-PHY Power 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) */
- u8 antenna_gain_a; /* A-PHY Antenna gain (in dBm Q5.2) */
- u8 antenna_gain_bg; /* B/G-PHY Antenna gain (in dBm Q5.2) */
- u8 oem[8]; /* OEM string (rev 1 only) */
-};
-
-struct ssb_sprom_r2 {
- u16 boardflags_hi; /* Boardflags (high 16 bits) */
- u8 maxpwr_a_lo; /* A-PHY Max Power Low */
- u8 maxpwr_a_hi; /* A-PHY Max Power High */
- u16 pa1lob0;/* A-PHY PA Low Settings */
- u16 pa1lob1;/* A-PHY PA Low Settings */
- u16 pa1lob2;/* A-PHY PA Low Settings */
- u16 pa1hib0;/* A-PHY PA High Settings */
- u16 pa1hib1;/* A-PHY PA High Settings */
- u16 pa1hib2;/* A-PHY PA High Settings */
- u8 ofdm_pwr_off;/* OFDM Power Offset from CCK Level */
- u8 country_str[2]; /* Two char Country Code */
-};
-
-struct ssb_sprom_r3 {
- u32 ofdmapo;/* A-PHY OFDM Mid Power Offset */
- u32 ofdmalpo; /* A-PHY OFDM Low Power Offset */
- u32 ofdmahpo; /* A-PHY OFDM High Power Offset */
- u8 gpioldc_on_cnt; /* GPIO LED Powersave Duty Cycle ON count */
- u8 gpioldc_off_cnt; /* GPIO LED Powersave Duty Cycle OFF count */
- u8 cckpo_1M:4; /* CCK Power Offset for Rate 1M */
- u8 cckpo_2M:4; /* CCK Power Offset for Rate 2M */
- u8 cckpo_55M:4; /* CCK Power Offset for Rate 5.5M */
- u8 cckpo_11M:4; /* CCK Power Offset for Rate 11M */
- u32 ofdmgpo;/* G-PHY OFDM Power Offset */
-};
-
struct ssb_sprom_data {
u8 il0mac[6]; /* MAC address for 802.11b/g */
u8 et0mac[6]; /* MAC address for Ethernet */
@@ -109,16 +46,6 @@ struct ssb_sprom_data {
struct ssb_sprom {
u8 revision;
u8 crc;
- /* The valid r# fields are selected by the revision.
- * Revision 3 and lower inherit from lower revisions.
- */
- union {
- struct {
- struct ssb_sprom_r1 r1;
- struct ssb_sprom_r2 r2;
- struct ssb_sprom_r3 r3;
- };
- };
struct ssb_sprom_data data;
};
I'd also like to get rid of the revision and crc fields, as they
are of no use to drivers. So you can rename struct ssb_sprom_data
to struct ssb_sprom and remove the old struct ssb_sprom.
If that creates problems with merging (bisect), just create one big patch.
I like big patches more than hundreds of small ones that change this
and that and in the end revert everything, just for the sake of
having multiple patches. :)
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] ssb: Add code for SPROM Rev 4
On Saturday 03 November 2007 16:19:46 Larry Finger wrote:
The BCM4328 has a revision 4 SPROM. The necessary changes to handle the
layout and different size of this revision are implemented. The size of
the SPROM is now stored in the ssb_bus struct and used from that location
whenever possible. For those routines that need the size, but do not have
access to that struct, a size argument is added.
Recognition of the PCI_ID of the BCM4328 is also implemented. Note that
the PCI_ID is 0x4328, but the chipid is 0x4321.
This code has been tested by Michael Gerdau [EMAIL PROTECTED].
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/include/linux/ssb/ssb.h
===
--- wireless-2.6.orig/include/linux/ssb/ssb.h
+++ wireless-2.6/include/linux/ssb/ssb.h
@@ -79,7 +79,39 @@ struct ssb_sprom_r3 {
};
struct ssb_sprom_r4 {
- /* TODO */
+ u16 pci_spid; /* Subsystem Product ID for PCI */
+ u16 pci_svid; /* Subsystem Vendor ID for PCI */
+ u16 pci_pid;/* Product ID for PCI */
+ u8 il0mac[6]; /* MAC address for 802.11b/g */
+ u8 et0mac[6]; /* MAC address for Ethernet */
+ u8 et1mac[6]; /* MAC address for 802.11a */
+ u8 et0phyaddr:5;/* MII address for enet0 */
+ u8 et1phyaddr:5;/* MII address for enet1 */
+ u8 et0mdcport:1;/* MDIO for enet0 */
+ u8 et1mdcport:1;/* MDIO for enet1 */
+ u8 board_rev; /* Board revision */
+ u8 country_code:4; /* Country Code */
+ u8 antenna_a:2; /* Antenna 0/1 available for A-PHY */
+ u8 antenna_bg:2;/* Antenna 0/1 available for B-PHY and G-PHY */
+ u16 pa0b0;
+ u16 pa0b1;
+ u16 pa0b2;
+ u16 pa1b0;
+ u16 pa1b1;
+ u16 pa1b2;
+ u8 gpio0; /* GPIO pin 0 */
+ u8 gpio1; /* GPIO pin 1 */
+ u8 gpio2; /* GPIO pin 2 */
+ 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) */
+ u8 antenna_gain_a; /* A-PHY Antenna gain (in dBm Q5.2) */
+ u8 antenna_gain_bg; /* B/G-PHY Antenna gain (in dBm Q5.2) */
+ /* The variables above this point must match those of ssb_sprom_r1 */
+ /* TODO - add any special ssb_sprom_r4 variables below this point. */
};
struct ssb_sprom {
@@ -288,6 +320,7 @@ struct ssb_bus {
/* ID information about the Chip. */
u16 chip_id;
u16 chip_rev;
+ u16 sprom_size; /* number of words in sprom */
u8 chip_package;
/* List of devices (cores) on the backplane. */
Larry, I did not forget your patch.
But I need to think a little bit more about this.
The union above is not really what I'd like to have here. In fact,
I think to get the v4 sprom implemented the sprom struct has to be
redesigned.
I think we must leave the path of partitioning the sprom struct into
versions, because that obviously doesn't work anymore.
Instead, I think we must develop _one_ common struct that is capable
of holding the information from any sprom. (Note that the struct layout
does not need to reflect the real hardware layout).
And I think we should also remove the fields that are not needed at all,
like the PCI ID stuff.
something like this:
struct ssb_sprom_pathvar {
bool this_pathvar_is_available;
...foobar data
};
struct ssb_sprom {
u8 wl_mac_addr[ETH_ALEN];
u8 eth0_mac_addr[ETH_ALEN];
u8 eth1_mac_addr[ETH_ALEN];
...
u8 gpio0;
u8 gpio1;
...
antennagain...
struct ssb_sprom_pathvar pv0;
struct ssb_sprom_pathvar pv1;
...
};
Note that I did _not_ look closely at the pathvar stuff, so this
might be a bad idea to design it this way.
But the point I was going to make with that was; we probably need
some this data is valid bits for different parts of the sprom
struct, as for example v1-3 don't have these pathvars (So the drivers
must be told it's invalid data).
The reason for all this valid-bit stuff is that I think we should
remove any sprom-versioning knowledge from the drivers. That
should be abstracted.
Any idea on how to improve that?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] ssb: Add code for SPROM Rev 4
On Monday 05 November 2007 17:03:47 Larry Finger wrote: u8 path_data0[SPROM_PATH_DATA_SIZE]; u8 path_data1 ... where SPROM_PATH_DATA_SIZE = 0x26. Once we see how the data are used, it may make more sense to have these data be u16, or even a union so that we can have it both ways. ^^ Whoops, endianess broken :) I'm not sure we need a separate valid bit for path data. In the sprom that we are working with, Ok, even better then. The valid bit was just an idea for stuff in the sprom which cannot be determined valid or not in another way. As I said earlier, my current patch is working OK for present needs. Once we come to an agreement regarding the sprom data structures, I will begin implementing them. As I see it, conversion will be a 3-step process. We will need a patch to add the new structure, a second to populate that structure, patches to convert b44, b43, and b43legacy to use the new data, and a final patch to remove the old structure. In this manner, bisection will be supported. cool :) Are you going to try a redesign of the structure? I'm not too motivated to do it, as I don't know too much about the v4 sprom, yet. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] A PHY init rewrite
On Sunday 04 November 2007 18:36:26 Stefano Brivio wrote: On Sun, 4 Nov 2007 18:25:05 +0100 Stefano Brivio [EMAIL PROTECTED] wrote: Signed-off-by: Stefano Brivio [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Cc: Michael Busch [EMAIL PROTECTED] instead, sorry. :) :) I tested this on a 4318 and and 4306. So you can add an Acked-by: Michael Buesch [EMAIL PROTECTED] for the G-PHY parts. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Rewrite and fix rfkill init
The rfkill subsystem doesn't like code like that
rfkill_allocate();
rfkill_register();
rfkill_unregister();
rfkill_register(); /* - This will crash */
This sequence happens with
modprobe b43
ifconfig wlanX up
ifconfig wlanX down
ifconfig wlanX up
Fix this by always re-allocating the rfkill stuff before register.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Note that this has to be ported to b43legacy.
Some volunteers? :)
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-11-03
14:19:21.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-11-03
14:26:39.0 +0100
@@ -3686,7 +3686,6 @@ static int b43_setup_modes(struct b43_wl
static void b43_wireless_core_detach(struct b43_wldev *dev)
{
- b43_rfkill_free(dev);
/* We release firmware that late to not be required to re-request
* is all the time when we reinit the core. */
b43_release_firmware(dev);
@@ -3772,7 +3771,6 @@ static int b43_wireless_core_attach(stru
if (!wl-current_dev)
wl-current_dev = dev;
INIT_WORK(dev-restart_work, b43_chip_reset);
- b43_rfkill_alloc(dev);
b43_radio_turn_off(dev, 1);
b43_switch_analog(dev, 0);
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/rfkill.c 2007-11-02
20:16:14.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/rfkill.c 2007-11-03
14:19:38.0 +0100
@@ -47,18 +47,21 @@ static void b43_rfkill_poll(struct input
struct b43_wldev *dev = poll_dev-private;
struct b43_wl *wl = dev-wl;
bool enabled;
+ bool report_change = 0;
mutex_lock(wl-mutex);
B43_WARN_ON(b43_status(dev) B43_STAT_INITIALIZED);
enabled = b43_is_hw_radio_enabled(dev);
if (unlikely(enabled != dev-radio_hw_enable)) {
dev-radio_hw_enable = enabled;
+ report_change = 1;
b43info(wl, Radio hardware status changed to %s\n,
enabled ? ENABLED : DISABLED);
- mutex_unlock(wl-mutex);
+ }
+ mutex_unlock(wl-mutex);
+
+ if (unlikely(report_change))
input_report_key(poll_dev-input, KEY_WLAN, enabled);
- } else
- mutex_unlock(wl-mutex);
}
/* Called when the RFKILL toggled in software. */
@@ -68,18 +71,11 @@ static int b43_rfkill_soft_toggle(void *
struct b43_wl *wl = dev-wl;
int err = 0;
- /* When RFKILL is registered, it will call back into this callback.
-* wl-mutex will already be locked when this happens.
-* So first trylock. On contention check if we are in initialization.
-* Silently return if that happens to avoid a deadlock. */
- if (mutex_trylock(wl-mutex) == 0) {
- if (b43_status(dev) B43_STAT_INITIALIZED)
- return 0;
- mutex_lock(wl-mutex);
- }
- if (b43_status(dev) B43_STAT_INITIALIZED)
- goto out_unlock;
+ if (!wl-rfkill.registered)
+ return 0;
+ mutex_lock(wl-mutex);
+ B43_WARN_ON(b43_status(dev) B43_STAT_INITIALIZED);
switch (state) {
case RFKILL_STATE_ON:
if (!dev-radio_hw_enable) {
@@ -104,11 +100,11 @@ out_unlock:
char * b43_rfkill_led_name(struct b43_wldev *dev)
{
- struct b43_wl *wl = dev-wl;
+ struct b43_rfkill *rfk = (dev-wl-rfkill);
- if (!wl-rfkill.rfkill)
+ if (!rfk-registered)
return NULL;
- return rfkill_get_led_name(wl-rfkill.rfkill);
+ return rfkill_get_led_name(rfk-rfkill);
}
void b43_rfkill_init(struct b43_wldev *dev)
@@ -117,53 +113,13 @@ void b43_rfkill_init(struct b43_wldev *d
struct b43_rfkill *rfk = (wl-rfkill);
int err;
- if (rfk-rfkill) {
- err = rfkill_register(rfk-rfkill);
- if (err) {
- b43warn(wl, Failed to register RF-kill button\n);
- goto err_free_rfk;
- }
- }
- if (rfk-poll_dev) {
- err = input_register_polled_device(rfk-poll_dev);
- if (err) {
- b43warn(wl, Failed to register RF-kill polldev\n);
- goto err_free_polldev;
- }
- }
-
- return;
-err_free_rfk:
- rfkill_free(rfk-rfkill);
- rfk-rfkill = NULL;
-err_free_polldev:
- input_free_polled_device(rfk-poll_dev);
- rfk-poll_dev = NULL;
-}
-
-void b43_rfkill_exit(struct b43_wldev *dev)
-{
- struct b43_rfkill *rfk = (dev-wl-rfkill);
-
- if (rfk-poll_dev)
- input_unregister_polled_device(rfk-poll_dev);
- if (rfk-rfkill)
- rfkill_unregister
[PATCH] b43: debugfs SHM read buffer overrun fix
Fix possible buffer overrun.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
We are searching a new b43legacy maintainer.
So if someone is interested in this job, please start with porting
this easy patch to b43legacy. ;)
Index: wireless-2.6/drivers/net/wireless/b43/debugfs.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/debugfs.c2007-11-02
18:26:55.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/debugfs.c 2007-11-02
18:28:24.0 +0100
@@ -128,7 +128,7 @@ static ssize_t shm_read_file(struct b43_
__le16 *le16buf = (__le16 *)buf;
for (i = 0; i 0x1000; i++) {
- if (bufsize = 0)
+ if (bufsize sizeof(tmp))
break;
tmp = b43_shm_read16(dev, B43_SHM_SHARED, 2 * i);
le16buf[i] = cpu_to_le16(tmp);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix rfkill callback deadlock
On Tuesday 30 October 2007 02:56:51 David Ellingsworth wrote: If that is the case, then a proper fix would be to use two locks to protect access to the status. One for allowing read access when no one is writing, and another for allowing exclusive write access. In such a configuration you could allow multiple readers while having only one writer. The above fix is not proper since the lock obtained by another section of code could be released before or during the status check. We don't care for that case, as the status is rechecked under lock later. This really is not a problem. We only care for the case where status!=INITIALIZED. Because then we mustn't aquire the lock and return silently. And that's what we do. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Change error message for failed rc module (was: possible bug in ssb/b43)
On Sunday 28 October 2007 11:40:21 Johannes Berg wrote: Please compile and load rc80211_simple. rc80211_simple is so little code, can't we just compile it into mac80211 module and make it configurable only for EMBEDDED? Yep, great idea. Let's make this default. I will do a patch. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm43xx: Error: Microcode bcm43xx_microcode5.fw not available or load failed.
On Sunday 28 October 2007 13:59:01 Ralf Saalmueller wrote: Hello to the dev team and thank you very much for your work. First I like to tell: I have the firmware installed: /lib/firmware/b43# ls bcm43xx needs the old firmware files in /lib/firmware/bcm43xx_*.fw -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] mac80211: make simple rate control algorithm built-in
On Sunday 28 October 2007 14:17:44 Johannes Berg wrote: Too frequently people do not have module autoloading enabled or fail to install the rate control module correctly, hence their hardware probing fails due to no rate control algorithm being available. This makes the 'simple' algorithm built into the mac80211 module unless EMBEDDED is enabled in which case it can be disabled (eg. if the wanted driver requires another rate control algorithm.) Signed-off-by: Johannes Berg [EMAIL PROTECTED] 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] b43: Dereference of wl-current_dev must be protected by wl-mutex
Put all access to wl-current_dev under protection of the mutex.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Larry Finger [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-10-28
15:46:24.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-10-28
15:54:55.0 +0100
@@ -2813,18 +2813,25 @@ static int b43_dev_set_key(struct ieee80
struct ieee80211_key_conf *key)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
- struct b43_wldev *dev = wl-current_dev;
+ struct b43_wldev *dev;
unsigned long flags;
u8 algorithm;
u8 index;
- int err = -EINVAL;
+ int err;
DECLARE_MAC_BUF(mac);
if (modparam_nohwcrypt)
return -ENOSPC; /* User disabled HW-crypto */
- if (!dev)
- return -ENODEV;
+ mutex_lock(wl-mutex);
+ spin_lock_irqsave(wl-irq_lock, flags);
+
+ dev = wl-current_dev;
+ err = -ENODEV;
+ if (!dev || b43_status(dev) B43_STAT_INITIALIZED)
+ goto out_unlock;
+
+ err = -EINVAL;
switch (key-alg) {
case ALG_WEP:
if (key-keylen == 5)
@@ -2840,20 +2847,11 @@ static int b43_dev_set_key(struct ieee80
break;
default:
B43_WARN_ON(1);
- goto out;
+ goto out_unlock;
}
-
index = (u8) (key-keyidx);
if (index 3)
- goto out;
-
- mutex_lock(wl-mutex);
- spin_lock_irqsave(wl-irq_lock, flags);
-
- if (b43_status(dev) B43_STAT_INITIALIZED) {
- err = -ENODEV;
goto out_unlock;
- }
switch (cmd) {
case SET_KEY:
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Use the retry limit parameters from mac80211
Use the limits provided by mac80211.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Larry Finger [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-10-28
16:09:00.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-10-28
16:12:51.0 +0100
@@ -75,14 +75,6 @@ module_param_named(bad_frames_preempt, m
MODULE_PARM_DESC(bad_frames_preempt,
enable(1) / disable(0) Bad Frames Preemption);
-static int modparam_short_retry = B43_DEFAULT_SHORT_RETRY_LIMIT;
-module_param_named(short_retry, modparam_short_retry, int, 0444);
-MODULE_PARM_DESC(short_retry, Short-Retry-Limit (0 - 15));
-
-static int modparam_long_retry = B43_DEFAULT_LONG_RETRY_LIMIT;
-module_param_named(long_retry, modparam_long_retry, int, 0444);
-MODULE_PARM_DESC(long_retry, Long-Retry-Limit (0 - 15));
-
static char modparam_fwpostfix[16];
module_param_string(fwpostfix, modparam_fwpostfix, 16, 0444);
MODULE_PARM_DESC(fwpostfix, Postfix for the .fw files to load.);
@@ -3261,6 +3253,22 @@ static void b43_imcfglo_timeouts_workaro
#endif /* CONFIG_SSB_DRIVER_PCICORE */
}
+/* Write the short and long frame retry limit values. */
+static void b43_set_retry_limits(struct b43_wldev *dev,
+unsigned int short_retry,
+unsigned int long_retry)
+{
+ /* The retry limit is a 4-bit counter. Enforce this to avoid overflowing
+* the chip-internal counter. */
+ short_retry = min(short_retry, (unsigned int)0xF);
+ long_retry = min(long_retry, (unsigned int)0xF);
+
+ b43_shm_write16(dev, B43_SHM_SCRATCH, B43_SHM_SC_SRLIMIT,
+ short_retry);
+ b43_shm_write16(dev, B43_SHM_SCRATCH, B43_SHM_SC_LRLIMIT,
+ long_retry);
+}
+
/* Shutdown a wireless core */
/* Locking: wl-mutex */
static void b43_wireless_core_exit(struct b43_wldev *dev)
@@ -3349,15 +3357,8 @@ static int b43_wireless_core_init(struct
}
b43_hf_write(dev, hf);
- /* Short/Long Retry Limit.
-* The retry-limit is a 4-bit counter. Enforce this to avoid overflowing
-* the chip-internal counter.
-*/
- tmp = limit_value(modparam_short_retry, 0, 0xF);
- b43_shm_write16(dev, B43_SHM_SCRATCH, B43_SHM_SC_SRLIMIT, tmp);
- tmp = limit_value(modparam_long_retry, 0, 0xF);
- b43_shm_write16(dev, B43_SHM_SCRATCH, B43_SHM_SC_LRLIMIT, tmp);
-
+ b43_set_retry_limits(dev, B43_DEFAULT_SHORT_RETRY_LIMIT,
+B43_DEFAULT_LONG_RETRY_LIMIT);
b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_SFFBLIM, 3);
b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_LFFBLIM, 2);
@@ -3534,19 +3535,40 @@ static void b43_stop(struct ieee80211_hw
mutex_unlock(wl-mutex);
}
+static int b43_op_set_retry_limit(struct ieee80211_hw *hw,
+ u32 short_retry_limit, u32 long_retry_limit)
+{
+ struct b43_wl *wl = hw_to_b43_wl(hw);
+ struct b43_wldev *dev;
+ int err = 0;
+
+ mutex_lock(wl-mutex);
+ dev = wl-current_dev;
+ if (unlikely(!dev || (b43_status(dev) B43_STAT_INITIALIZED))) {
+ err = -ENODEV;
+ goto out_unlock;
+ }
+ b43_set_retry_limits(dev, short_retry_limit, long_retry_limit);
+out_unlock:
+ mutex_unlock(wl-mutex);
+
+ return err;
+}
+
static const struct ieee80211_ops b43_hw_ops = {
- .tx = b43_tx,
- .conf_tx = b43_conf_tx,
- .add_interface = b43_add_interface,
- .remove_interface = b43_remove_interface,
- .config = b43_dev_config,
- .config_interface = b43_config_interface,
- .configure_filter = b43_configure_filter,
- .set_key = b43_dev_set_key,
- .get_stats = b43_get_stats,
- .get_tx_stats = b43_get_tx_stats,
- .start = b43_start,
- .stop = b43_stop,
+ .tx = b43_tx,
+ .conf_tx= b43_conf_tx,
+ .add_interface = b43_add_interface,
+ .remove_interface = b43_remove_interface,
+ .config = b43_dev_config,
+ .config_interface = b43_config_interface,
+ .configure_filter = b43_configure_filter,
+ .set_key= b43_dev_set_key,
+ .get_stats = b43_get_stats,
+ .get_tx_stats = b43_get_tx_stats,
+ .start = b43_start,
+ .stop = b43_stop,
+ .set_retry_limit= b43_op_set_retry_limit,
};
/* Hard-reset the chip. Do not call this directly.
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/xmit.c 2007-10-28
16:08:36.0 +0100
+++ wireless-2.6
[PATCH] b43: consistent naming for ieee80211_ops
Use a consistent naming scheme for the ops.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Larry Finger [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-10-28
16:20:03.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-10-28
16:24:51.0 +0100
@@ -2486,8 +2486,9 @@ static int b43_rng_init(struct b43_wl *w
return err;
}
-static int b43_tx(struct ieee80211_hw *hw,
- struct sk_buff *skb, struct ieee80211_tx_control *ctl)
+static int b43_op_tx(struct ieee80211_hw *hw,
+struct sk_buff *skb,
+struct ieee80211_tx_control *ctl)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl-current_dev;
@@ -2505,21 +2506,21 @@ static int b43_tx(struct ieee80211_hw *h
spin_unlock_irqrestore(wl-irq_lock, flags);
} else
err = b43_dma_tx(dev, skb, ctl);
- out:
+out:
if (unlikely(err))
return NETDEV_TX_BUSY;
return NETDEV_TX_OK;
}
-static int b43_conf_tx(struct ieee80211_hw *hw,
- int queue,
- const struct ieee80211_tx_queue_params *params)
+static int b43_op_conf_tx(struct ieee80211_hw *hw,
+ int queue,
+ const struct ieee80211_tx_queue_params *params)
{
return 0;
}
-static int b43_get_tx_stats(struct ieee80211_hw *hw,
- struct ieee80211_tx_queue_stats *stats)
+static int b43_op_get_tx_stats(struct ieee80211_hw *hw,
+ struct ieee80211_tx_queue_stats *stats)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl-current_dev;
@@ -2537,12 +2538,12 @@ static int b43_get_tx_stats(struct ieee8
err = 0;
}
spin_unlock_irqrestore(wl-irq_lock, flags);
- out:
+out:
return err;
}
-static int b43_get_stats(struct ieee80211_hw *hw,
-struct ieee80211_low_level_stats *stats)
+static int b43_op_get_stats(struct ieee80211_hw *hw,
+ struct ieee80211_low_level_stats *stats)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
unsigned long flags;
@@ -2695,7 +2696,7 @@ static int b43_antenna_from_ieee80211(u8
}
}
-static int b43_dev_config(struct ieee80211_hw *hw, struct ieee80211_conf *conf)
+static int b43_op_config(struct ieee80211_hw *hw, struct ieee80211_conf *conf)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev;
@@ -2800,7 +2801,7 @@ static int b43_dev_config(struct ieee802
return err;
}
-static int b43_dev_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
+static int b43_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
const u8 *local_addr, const u8 *addr,
struct ieee80211_key_conf *key)
{
@@ -2893,7 +2894,6 @@ BUG_ON(!key);
out_unlock:
spin_unlock_irqrestore(wl-irq_lock, flags);
mutex_unlock(wl-mutex);
-out:
if (!err) {
b43dbg(wl, %s hardware based encryption for keyidx: %d,
mac: %s\n,
@@ -2903,9 +2903,9 @@ out:
return err;
}
-static void b43_configure_filter(struct ieee80211_hw *hw,
-unsigned int changed, unsigned int *fflags,
-int mc_count, struct dev_addr_list *mc_list)
+static void b43_op_configure_filter(struct ieee80211_hw *hw,
+ unsigned int changed, unsigned int *fflags,
+ int mc_count, struct dev_addr_list *mc_list)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl-current_dev;
@@ -2940,8 +2940,9 @@ static void b43_configure_filter(struct
spin_unlock_irqrestore(wl-irq_lock, flags);
}
-static int b43_config_interface(struct ieee80211_hw *hw,
- int if_id, struct ieee80211_if_conf *conf)
+static int b43_op_config_interface(struct ieee80211_hw *hw,
+ int if_id,
+ struct ieee80211_if_conf *conf)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl-current_dev;
@@ -3427,8 +3428,8 @@ static int b43_wireless_core_init(struct
return err;
}
-static int b43_add_interface(struct ieee80211_hw *hw,
-struct ieee80211_if_init_conf *conf)
+static int b43_op_add_interface(struct ieee80211_hw *hw,
+ struct ieee80211_if_init_conf *conf)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev;
@@ -3467,8 +3468,8 @@ static int b43_add_interface(struct ieee
return err;
}
-static void b43_remove_interface(struct
[PATCH] b43: Fix rfkill callback deadlock
wl-mutex might already be locked on initialization.
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-10-27
13:28:16.0 +0200
+++ wireless-2.6/drivers/net/wireless/b43/rfkill.c 2007-10-28
17:13:55.0 +0100
@@ -61,15 +61,22 @@ static void b43_rfkill_poll(struct input
mutex_unlock(wl-mutex);
}
-/* Called when the RFKILL toggled in software.
- * This is called without locking. */
+/* Called when the RFKILL toggled in software. */
static int b43_rfkill_soft_toggle(void *data, enum rfkill_state state)
{
struct b43_wldev *dev = data;
struct b43_wl *wl = dev-wl;
int err = 0;
- mutex_lock(wl-mutex);
+ /* When RFKILL is registered, it will call back into this callback.
+* wl-mutex will already be locked when this happens.
+* So first trylock. On contention check if we are in initialization.
+* Silently return if that happens to avoid a deadlock. */
+ if (mutex_trylock(wl-mutex) == 0) {
+ if (b43_status(dev) B43_STAT_INITIALIZED)
+ return 0;
+ mutex_lock(wl-mutex);
+ }
if (b43_status(dev) B43_STAT_INITIALIZED)
goto out_unlock;
@@ -89,7 +96,6 @@ static int b43_rfkill_soft_toggle(void *
b43_radio_turn_off(dev, 0);
break;
}
-
out_unlock:
mutex_unlock(wl-mutex);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43legacy: Remove set_key callback
We don't need the set_key callback, as we don't do hw crypto.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/wireless/b43legacy/main.c
===
--- linux-2.6.orig/drivers/net/wireless/b43legacy/main.c
+++ linux-2.6/drivers/net/wireless/b43legacy/main.c
@@ -2603,32 +2603,6 @@ out_unlock_mutex:
return err;
}
-static int b43legacy_dev_set_key(struct ieee80211_hw *hw,
-enum set_key_cmd cmd,
-const u8 *local_addr, const u8 *addr,
-struct ieee80211_key_conf *key)
-{
- struct b43legacy_wl *wl = hw_to_b43legacy_wl(hw);
- struct b43legacy_wldev *dev = wl-current_dev;
- unsigned long flags;
- int err = -EOPNOTSUPP;
- DECLARE_MAC_BUF(mac);
-
- if (!dev)
- return -ENODEV;
- mutex_lock(wl-mutex);
- spin_lock_irqsave(wl-irq_lock, flags);
-
- if (b43legacy_status(dev) B43legacy_STAT_INITIALIZED) {
- err = -ENODEV;
- }
- spin_unlock_irqrestore(wl-irq_lock, flags);
- mutex_unlock(wl-mutex);
- b43legacydbg(wl, Using software based encryption for
-mac: %s\n, print_mac(mac, addr));
- return err;
-}
-
static void b43legacy_configure_filter(struct ieee80211_hw *hw,
unsigned int changed,
unsigned int *fflags,
@@ -3284,7 +3258,6 @@ static const struct ieee80211_ops b43leg
.remove_interface = b43legacy_remove_interface,
.config = b43legacy_dev_config,
.config_interface = b43legacy_config_interface,
- .set_key = b43legacy_dev_set_key,
.configure_filter = b43legacy_configure_filter,
.get_stats = b43legacy_get_stats,
.get_tx_stats = b43legacy_get_tx_stats,
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: What to do to add support for BCM4328 to the b43 module
On Sunday 28 October 2007 22:50:12 Michael Gerdau wrote: Hi, I have a Dell XPS M1710 which sports a BCM4328. I have it working by means of ndiswrapper but would have rather have it supported by the b43 module. What could I do to help here ? Note I never wrote a linux driver and am not sure I'm up to the task. Neither have I any documentation w/r to that chip. I'm happy to apply and try whatever patches are sent to me, both for trying actual driver patches as well as stuff to help reverse engineering. I'm also willing (though not sure whether I sport the required skills) to try to learn how to write the driver myself but I'm sure I'd need some help to get me started. If you want to help, you should join the reverse engineering team. Implementing the driver is not the problem. Creating the specifications by reverse engineering is the bigger problem where people are needed. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix rfkill callback deadlock
On Sunday 28 October 2007 23:37:10 David Ellingsworth wrote:
From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PATCH] b43: Fix
rfkill callback deadlock Date: Sun, 28 Oct 2007 17:27:10 +0100 CC: [EMAIL
PROTECTED]; bcm43xx-dev@lists.berlios.de; [EMAIL PROTECTED] wl-mutex
might already be locked on initialization. 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-10-27
13:28:16.0 +0200 +++
wireless-2.6/drivers/net/wireless/b43/rfkill.c 2007-10-28
17:13:55.0 +0100 @@ -61,15 +61,22 @@ static void
b43_rfkill_poll(struct input mutex_unlock(wl-mutex); } -/* Called
when the RFKILL toggled in software. - * This is called without locking.
*/ +/* Called when the RFKILL toggled in software. */ static int
b43_rfkill_soft_toggle(void *data, enum rfkill_state state) { struct
b43_wldev *dev = data; struct b43_wl *wl = dev-wl; int err = 0; -
mutex_lock(wl-mutex); + /* When RFKILL is registered, it will call back
into this callback. + * wl-mutex will already be locked when this
happens. + * So first trylock. On contention check if we are in
initialization. + * Silently return if that happens to avoid a deadlock.
*/ + if (mutex_trylock(wl-mutex) == 0) { + if (b43_status(dev)
B43_STAT_INITIALIZED) + return 0; + mutex_lock(wl-mutex); + } if
(b43_status(dev) B43_STAT_INITIALIZED) goto out_unlock;
Why not replace the above lines up to and including -
mutex_loc(wl-mutext); with:
if(b43_status(dev) B43_STAT_INITIALIZED)
return 0;
mutex_lock(wl-mutex) @@ -89,7 +96,6 @@ static int
b43_rfkill_soft_toggle(void * b43_radio_turn_off(dev, 0); break; } -
out_unlock: mutex_unlock(wl-mutex);
___ Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
_
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews
I'm sorry. Your mailer completely fucked up the context
so I'm not really able to see what you want to tell me.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix rfkill callback deadlock
On Monday 29 October 2007 01:06:51 David Ellingsworth wrote:
- mutex_lock(wl-mutex);
+ /* When RFKILL is registered, it will call back into this callback.
+ * wl-mutex will already be locked when this happens.
+ * So first trylock. On contention check if we are in initialization.
+ * Silently return if that happens to avoid a deadlock. */
+ if (mutex_trylock(wl-mutex) == 0) {
+ if (b43_status(dev) B43_STAT_INITIALIZED)
+ return 0;
+ mutex_lock(wl-mutex);
+ }
if (b43_status(dev) B43_STAT_INITIALIZED)
goto out_unlock;
Why not replace everything above up to and including the -
mutex_lock(wl-mutex); with:
if(b43_status(dev) B43_STAT_INITIALIZED)
return 0;
mutex_lock(wl-mutex);
because the status should be queried under lock, of course.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Fix initcall ordering
ssb must init after PCI but before the ssb drivers.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Christian Casteyde [EMAIL PROTECTED]
Fixes-bug: #9219
Index: wireless-2.6/drivers/ssb/main.c
===
--- wireless-2.6.orig/drivers/ssb/main.c2007-10-27 14:54:40.0
+0200
+++ wireless-2.6/drivers/ssb/main.c 2007-10-27 14:57:15.0 +0200
@@ -1147,7 +1147,10 @@ static int __init ssb_modinit(void)
return err;
}
-subsys_initcall(ssb_modinit);
+/* ssb must be initialized after PCI but before the ssb drivers.
+ * That means we must use some initcall between subsys_initcall
+ * and device_initcall. */
+fs_initcall(ssb_modinit);
static void __exit ssb_modexit(void)
{
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Fix initcall ordering
ssb must init after PCI but before the ssb drivers.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Christian Casteyde [EMAIL PROTECTED]
Fixes-bug: #9219
Index: wireless-2.6/drivers/ssb/main.c
===
--- wireless-2.6.orig/drivers/ssb/main.c2007-10-27 14:54:40.0
+0200
+++ wireless-2.6/drivers/ssb/main.c 2007-10-27 14:57:15.0 +0200
@@ -1147,7 +1147,10 @@ static int __init ssb_modinit(void)
return err;
}
-subsys_initcall(ssb_modinit);
+/* ssb must be initialized after PCI but before the ssb drivers.
+ * That means we must use some initcall between subsys_initcall
+ * and device_initcall. */
+fs_initcall(ssb_modinit);
static void __exit ssb_modexit(void)
{
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Change error message for failed rc module (was: possible bug in ssb/b43)
On Saturday 27 October 2007 23:56:39 evan foss wrote: snip ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) ssb: Sonics Silicon Backplane found on PCI device :01:00.0 b43-phy1: Broadcom 4311 WLAN found b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 phy1: Failed to select rate control algorithm phy1: Failed to initialize rate control algorithm b43: probe of ssb0:0 failed with error -2 That's not a ssb or b43 bug. Please compile and load rc80211_simple. I think we should change this error message, as obviously people don't understand that the issue is a failed module request for the rc module. Maybe add another message like Please install a mac80211 rate control module, such as rc80211_simple if the error code is -ENOENT (-2) Another suggestion? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Installation of b43
On Wednesday 24 October 2007 17:50:25 Larry Finger wrote: Although I have resigned as maintainer, I am not leaving the project entirely. My situation is that I will not have access to a broadband connection for 3-4 months, and will have to rely on dial-up over a shared line. I will be able to do E-mail, but not kernel updates. I will certainly help you in any way that I can. Of course you'll get the required help from all of us. Basically, becoming a b43legacy maintainer is easy. Just start hacking on it. Start understanding the code. Maybe make suggestions/patches on what to do better. Simply start working on it. If that works well, we'll put your name into the MAINTAINERS file and you are the official maintainer. That's how it worked for Larry. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Installation of b43
On Tuesday 23 October 2007 22:12:01 Daniel Fiser wrote: Hi everybody, please, could someone instruct me, how to install b43 driver for my broadcom bcm4318 device? I have found at linuxwireless.org that my device is supported by b43 driver and I was glad of it, because I needn't to use ndiswrapper, but I haven't found how to install this driver. Please, could someone help me? Get the wireless development kernel sources with git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git The drivers will be includes there. Secondly, I would like to offer my assistance on this project. I am able to write C code or I can help any other way We are searching for new b43legacy maintainer. So if you want to dig into that code, please do so and maybe you'll become the new maintainer. It's up to you. ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Status of support for some chips
On Monday 22 October 2007 00:27:20 Larry Finger wrote: All WPA encryption/decryption is done in software for bcm43xx, b43, and b43legacy drivers. b43 will do everything but tkip in hardware. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH #3] b43: Fix sparse warnings.
On Thursday 18 October 2007 21:53:22 John W. Linville wrote: On Wed, Oct 17, 2007 at 06:34:03PM +0200, Michael Buesch wrote: The remaining warning in phy.c will be fixed later. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- John, this is the third time I submit this. Is something wrong with this patch or did you simply forget to apply it? Where are you looking? It is in Linus' tree. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a09404a2338163f181d170c7abdc2242b6c6f03 John Uhm, it still applies to wireless-2.6#everything. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 driver Openwrt
On Wednesday 17 October 2007 21:48:35 Артем Антонов wrote: Hi! I've tried b43 driver on openwrt. Device - ASUS WL500-gP (bcm4318) lspci -vv output: 00:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) Subsystem: ASUSTeK Computer Inc. A6U notebook embedded card Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Interrupt: pin A routed to IRQ 6 Region 0: Memory at 40002000 (32-bit, non-prefetchable) [size=8K] with these patches https://lists.berlios.de/pipermail/bcm43xx-dev/attachments/20070814/38e5a3de/attachment.ksh; https://lists.berlios.de/pipermail/bcm43xx-dev/attachments/20070814/ca6c6ac2/attachment.kshb43 doesn't work. at boot time there are errors: PCI: Device :00:02.0 not available because of resource collisions b43-pci-bridge: probe of :00:02.0 failed with error -22 You cannot run the old non-SSB based b44 module together with b43. You must run b43 and the new SSB based b44 module (that's called version 2). (full logs are here: https://dev.openwrt.org/ticket/2521) When i try to load b43 module - nothing happens (even no logs). b43 module is loading, but no reaction. I tried to cancel this patch https://lists.berlios.de/pipermail/bcm43xx-dev/attachments/20070814/38e5a3de/attachment.ksh And driver loads, and it's even working %) PCI: Enabling device :00:02.0 ( - 0002) PCI: Fixing up device :00:02.0 PCI: Setting latency timer of device :00:02.0 to 64 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243) ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243) ssb: Sonics Silicon Backplane found on PCI device :00:02.0 b43-phy0: Broadcom 4318 WLAN found b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 b43-phy0 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config phy0: Selected rate control algorithm 'simple' b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) b43-phy0 debug: Chip initialized b43-phy0 debug: 32-bit DMA initialized b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 1 Best regards. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 driver Openwrt
(Please stay on-list. I won't debug bugs in private anymore. Doing this on list tends to result in fixes a _lot_ faster, as a lot more people are involved). On Thursday 18 October 2007 18:23:01 Артем Антонов wrote: I've updated b44, but it didn't solve the problem. PCI: fixing up bridge PCI: Setting latency timer of device :00:00.0 to 64 PCI: Fixing up device :00:00.0 PCI: Device :00:02.0 not available because of resource collisions You must still be loading something twice. Are you loading bcm43xx? b43-pci-bridge: probe of :00:02.0 failed with error -22 Time: MIPS clocksource has been installed. NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered squashfs: version 3.0 (2006/03/15) Phillip Lougher Registering mini_fo version $Id$ JFFS2 version 2.2. (NAND) (SUMMARY) В(c) 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler deadline registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled serial8250: ttyS0 at MMIO 0x0 (irq = 3) is a 16550A serial8250: ttyS1 at MMIO 0x0 (irq = 3) is a 16550A b44.c:v2.0 eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:1a:92:bc:d1:88 eth1: Broadcom 44xx/47xx 10/100BaseT Ethernet 40:10:18:00:00:2d -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Make b43_stop() static
This fixes a sparse warning.
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-10-17
20:02:21.0 +0200
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-10-17
20:04:27.0 +0200
@@ -3561,7 +3561,7 @@ static int b43_start(struct ieee80211_hw
return err;
}
-void b43_stop(struct ieee80211_hw *hw)
+static void b43_stop(struct ieee80211_hw *hw)
{
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl-current_dev;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH #3] b43: Fix sparse warnings.
The remaining warning in phy.c will be fixed later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is the third time I submit this.
Is something wrong with this patch or did you simply forget to apply it?
Index: wireless-2.6/drivers/net/wireless/b43/pio.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/pio.c2007-10-17
18:16:25.0 +0200
+++ wireless-2.6/drivers/net/wireless/b43/pio.c 2007-10-17 18:19:45.0
+0200
@@ -60,7 +60,7 @@ static u16 tx_get_next_word(const u8 * t
source = packet;
i -= txhdr_size;
}
- ret = le16_to_cpu(*((u16 *) (source + i)));
+ ret = le16_to_cpu(*((__le16 *)(source + i)));
*pos += 2;
return ret;
@@ -104,7 +104,7 @@ static u16 generate_cookie(struct b43_pi
struct b43_pio_txpacket *packet)
{
u16 cookie = 0x;
- int packetindex;
+ u16 packetindex;
/* We use the upper 4 bits for the PIO
* controller ID and the lower 12 bits
@@ -125,7 +125,7 @@ static u16 generate_cookie(struct b43_pi
default:
B43_WARN_ON(1);
}
- packetindex = pio_txpacket_getindex(packet);
+ packetindex = packet-index;
B43_WARN_ON(packetindex ~0x0FFF);
cookie |= (u16) packetindex;
@@ -286,6 +286,7 @@ static void setup_txqueues(struct b43_pi
packet-queue = queue;
INIT_LIST_HEAD(packet-list);
+ packet-index = i;
list_add(packet-list, queue-txfree);
}
@@ -518,9 +519,10 @@ static void pio_rx_error(struct b43_pioq
void b43_pio_rx(struct b43_pioqueue *queue)
{
- u16 preamble[21] = { 0 };
+ __le16 preamble[21] = { 0 };
struct b43_rxhdr_fw4 *rxhdr;
- u16 tmp, len, macstat;
+ u16 tmp, len;
+ u32 macstat;
int i, preamble_readwords;
struct sk_buff *skb;
@@ -537,7 +539,7 @@ void b43_pio_rx(struct b43_pioqueue *que
}
b43dbg(queue-dev-wl, PIO RX timed out\n);
return;
- data_ready:
+data_ready:
len = b43_pio_read(queue, B43_PIO_RXDATA);
if (unlikely(len 0x700)) {
@@ -558,7 +560,7 @@ void b43_pio_rx(struct b43_pioqueue *que
preamble[i + 1] = cpu_to_le16(tmp);
}
rxhdr = (struct b43_rxhdr_fw4 *)preamble;
- macstat = le16_to_cpu(rxhdr-mac_status);
+ macstat = le32_to_cpu(rxhdr-mac_status);
if (macstat B43_RX_MAC_FCSERR) {
pio_rx_error(queue,
(queue-mmio_base == B43_MMIO_PIO1_BASE),
@@ -583,7 +585,7 @@ void b43_pio_rx(struct b43_pioqueue *que
skb_put(skb, len);
for (i = 0; i len - 1; i += 2) {
tmp = b43_pio_read(queue, B43_PIO_RXDATA);
- *((u16 *) (skb-data + i)) = cpu_to_le16(tmp);
+ *((__le16 *)(skb-data + i)) = cpu_to_le16(tmp);
}
if (len % 2) {
tmp = b43_pio_read(queue, B43_PIO_RXDATA);
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/xmit.c 2007-10-17
18:16:25.0 +0200
+++ wireless-2.6/drivers/net/wireless/b43/xmit.c2007-10-17
18:19:45.0 +0200
@@ -121,10 +121,12 @@ void b43_generate_plcp_hdr(struct b43_pl
__u8 *raw = plcp-raw;
if (b43_is_ofdm_rate(bitrate)) {
- *data = b43_plcp_get_ratecode_ofdm(bitrate);
+ u32 d;
+
+ d = b43_plcp_get_ratecode_ofdm(bitrate);
B43_WARN_ON(octets 0xF000);
- *data |= (octets 5);
- *data = cpu_to_le32(*data);
+ d |= (octets 5);
+ *data = cpu_to_le32(d);
} else {
u32 plen;
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c 2007-10-17
18:16:25.0 +0200
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-10-17
18:19:45.0 +0200
@@ -1045,7 +1045,7 @@ static void handle_irq_noise(struct b43_
B43_WARN_ON(!dev-noisecalc.calculation_running);
if (dev-noisecalc.channel_at_start != phy-channel)
goto drop_calculation;
- *((u32 *) noise) = cpu_to_le32(b43_jssi_read(dev));
+ *((__le32 *)noise) = cpu_to_le32(b43_jssi_read(dev));
if (noise[0] == 0x7F || noise[1] == 0x7F ||
noise[2] == 0x7F || noise[3] == 0x7F)
goto generate_new;
@@ -1575,8 +1575,7 @@ static int do_request_fw(struct b43_wlde
const char *name,
const struct firmware **fw)
{
- const size_t plen = sizeof(modparam_fwpostfix) + 32;
- char path[plen];
+ char path[sizeof(modparam_fwpostfix) + 32
[PATCH] b43: jiffies_round - jiffies_round_relative conversion - b43/b43legacy
When rounding a relative timeout we need to use round_jiffies_relative(). Signed-off-by: Anton Blanchard [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c index c141a26..41049a4 100644 --- a/drivers/net/wireless/b43/main.c +++ b/drivers/net/wireless/b43/main.c @@ -2392,7 +2392,7 @@ out_requeue: if (b43_debug(dev, B43_DBG_PWORK_FAST)) delay = msecs_to_jiffies(50); else - delay = round_jiffies(HZ * 15); + delay = round_jiffies_relative(HZ * 15); queue_delayed_work(wl-hw-workqueue, dev-periodic_work, delay); out: mutex_unlock(wl-mutex); diff --git a/drivers/net/wireless/b43legacy/main.c b/drivers/net/wireless/b43legacy/main.c index f074951..bd0bd9b 100644 --- a/drivers/net/wireless/b43legacy/main.c +++ b/drivers/net/wireless/b43legacy/main.c @@ -2260,7 +2260,7 @@ out_requeue: if (b43legacy_debug(dev, B43legacy_DBG_PWORK_FAST)) delay = msecs_to_jiffies(50); else - delay = round_jiffies(HZ); + delay = round_jiffies_relative(HZ); queue_delayed_work(dev-wl-hw-workqueue, dev-periodic_work, delay); out: --- -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Fwd: [-mm Patch] drivers/net/wireless/b43legacy/main.c: initialize the correct return value
From: Adrian Bunk [EMAIL PROTECTED] Initialize err in drivers/net/wireless/b43legacy/main.c::b43legacy_start() in case of returning an uninitialized value. Signed-off-by: WANG Cong [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- drivers/net/wireless/b43/main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23-mm1/drivers/net/wireless/b43legacy/main.c === --- linux-2.6.23-mm1.orig/drivers/net/wireless/b43legacy/main.c +++ linux-2.6.23-mm1/drivers/net/wireless/b43legacy/main.c @@ -3306,7 +3306,7 @@ static int b43legacy_start(struct ieee80 struct b43legacy_wl *wl = hw_to_b43legacy_wl(hw); struct b43legacy_wldev *dev = wl-current_dev; int did_init = 0; - int err; + int err = 0; mutex_lock(wl-mutex); --- -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 with upstream-davem stacktrace
On Monday 15 October 2007 11:05:26 Richard Purdie wrote: On Sun, 2007-10-14 at 11:42 +0200, Johannes Berg wrote: On Sat, 2007-10-13 at 17:26 +0200, Michael Buesch wrote: I also saw this sometimes, but I have absolutely no idea how that happens. Someone any idea? Nope, but adding more CCs :) I briefly looked at the code and couldn't track it. Got a powerpc oops with disassembly? It appears to be having a problem in the strcmp in led_trigger_set_default() which is odd. Code above that checks if one of the options is NULL so all I can think it either the default_trigger string being passed in is invalid or there is a trigger with an invalid name registered with the system. Is this an SMP system and would something else be registering an LED trigger on another processor or similar? There is locking there which should be sufficient though. So no, I'm not sure whats going on either... I think this is some kind of a race, as it does only happen rarely and is not really reproducible. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch] ssb: fix build failure
From: Ingo Molnar [EMAIL PROTECTED] fix build failure if PCMCIA=m but SSB=y: drivers/built-in.o: In function `ssb_pcmcia_switch_coreidx': : undefined reference to `pcmcia_access_configuration_register' (fix symmetric bug for PCI too.) Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- drivers/ssb/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux/drivers/ssb/Kconfig === --- linux.orig/drivers/ssb/Kconfig +++ linux/drivers/ssb/Kconfig @@ -22,7 +22,7 @@ config SSB config SSB_PCIHOST_POSSIBLE bool - depends on SSB PCI + depends on SSB (PCI = SSB) default y config SSB_PCIHOST @@ -37,7 +37,7 @@ config SSB_PCIHOST config SSB_PCMCIAHOST_POSSIBLE bool - depends on SSB PCMCIA EXPERIMENTAL + depends on SSB (PCMCIA = SSB) EXPERIMENTAL default y config SSB_PCMCIAHOST --- -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch #2] ssb: fix build failure
From: Ingo Molnar [EMAIL PROTECTED] fix build failure if PCMCIA=m but SSB=y: drivers/built-in.o: In function `ssb_pcmcia_switch_coreidx': : undefined reference to `pcmcia_access_configuration_register' (fix symmetric bug for PCI too.) Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- drivers/ssb/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux/drivers/ssb/Kconfig === --- linux.orig/drivers/ssb/Kconfig +++ linux/drivers/ssb/Kconfig @@ -22,7 +22,7 @@ config SSB config SSB_PCIHOST_POSSIBLE bool - depends on SSB PCI + depends on SSB (PCI = y || PCI = SSB) default y config SSB_PCIHOST @@ -37,7 +37,7 @@ config SSB_PCIHOST config SSB_PCMCIAHOST_POSSIBLE bool - depends on SSB PCMCIA EXPERIMENTAL + depends on SSB (PCMCIA = y || PCMCIA = SSB) EXPERIMENTAL default y config SSB_PCMCIAHOST --- -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix regression in 2.6.23-git3 due to change in calling add_uevent_var
On Sunday 14 October 2007 06:46:47 Larry Finger wrote:
In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence
for add_uevent_var was changed, but the ssb driver was not modified, which
leads to a Unable to handle kernel paging request oops. This patch fixes
the problem.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/ssb/main.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Index: linux-2.6/drivers/ssb/main.c
===
--- linux-2.6.orig/drivers/ssb/main.c
+++ linux-2.6/drivers/ssb/main.c
@@ -320,22 +320,17 @@ static int ssb_bus_match(struct device *
return 0;
}
-static int ssb_device_uevent(struct device *dev, char **envp, int num_envp,
- char *buffer, int buffer_size)
+static int ssb_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct ssb_device *ssb_dev = dev_to_ssb_dev(dev);
- int ret, i = 0, length = 0;
+ int ret;
if (!dev)
return -ENODEV;
- ret = add_uevent_var(envp, num_envp, i,
- buffer, buffer_size, length,
- MODALIAS=ssb:v%04Xid%04Xrev%02X,
+ ret = add_uevent_var(env, MODALIAS=ssb:v%04Xid%04Xrev%02X,
ssb_dev-id.vendor, ssb_dev-id.coreid,
ssb_dev-id.revision);
- envp[i] = NULL;
-
return ret;
}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: regression on bcm4318
On Saturday 13 October 2007 10:17:30 Vitaly Bordug wrote: phy1: Failed to select rate control algorithm phy1: Failed to initialize rate control algorithm That's nothing b43 or ssb related. Compile and load the rc80211_simple module. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: regression on bcm4318
On Saturday 13 October 2007 16:14:31 Vitaly Bordug wrote: Hello Michael, On Sat, 13 Oct 2007 10:24:47 +0200 Michael Buesch wrote: On Saturday 13 October 2007 10:17:30 Vitaly Bordug wrote: phy1: Failed to select rate control algorithm phy1: Failed to initialize rate control algorithm That's nothing b43 or ssb related. Compile and load the rc80211_simple module. oh, thanks, that was broken module dependencies. Well at least it is saved in archive now, no nobody else would step into it. Another question: is this driver known to work okay in ad-hoc or master mode? I gave it a try and there is no driver-side whine, but it does not seem to work either. I see couple of packages turnaround, sometimes even dhcp server is able to feed IP via wlan (host is acting as kinda AP), but nothing after that. Master and adhoc is not stable, yet. It might work, though. But I didn't really test that recently. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 with upstream-davem stacktrace
On Saturday 13 October 2007 18:23:33 Christian Hoffmann wrote: Hi all, I tried (I think) latest b43 driver on a bcm4318. It works quite well, but on a series of connect/reconnect I had attached stack in dmesg. Any idea? Chris FYI (normal dmesg output) b43-phy0: Broadcom 4318 WLAN found b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 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: Chip initialized b43-phy0 debug: 32-bit DMA initialized b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 I also saw this sometimes, but I have absolutely no idea how that happens. Someone any idea? 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 general protection fault: [1] SMP CPU 0 Modules linked in: eeprom ircomm_tty ircomm af_packet snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device radeon drm cpufreq_conservative cpufreq_userspace cpufreq _powersave powernow_k8 pcmcia snd_atiixp_modem arc4 snd_atiixp ecb blkcipher rc8 0211_simple snd_ac97_codec yenta_socket ac97_bus snd_pcm rsrc_nonstatic snd_time r snd pcmcia_core b43 firmware_class parport_pc ohci1394 ide_cd ssb rfkill mac80 211 rtc_cmos irda crc_ccitt rtc_core k8temp rtc_lib cfg80211 led_class tifm_7xx1 output battery ac parport ieee1394 button cdrom tifm_core container soundcore s nd_page_alloc tg3 hwmon joydev input_polldev i2c_piix4 serio_raw ide_disk ehci_h cd ohci_hcd usbcore radeonfb fb_ddc i2c_algo_bit i2c_core edd ext3 mbcache jbd f an atiixp ide_core thermal processor Pid: 2295, comm: NetworkManager Not tainted 2.6.23-rc9-default #1 RIP: 0010:[802f38aa] [802f38aa] strcmp+0x0/0x1a RSP: 0018:810078fe5740 EFLAGS: 00010283 RAX: 81007d1f5f70 RBX: 81007d1f5f40 RCX: 80418988 RDX: 881ed3d0 RSI: 8048498b RDI: 66355f306e616c77 RBP: 81007da723a8 R08: R09: R10: 881ed3a0 R11: 803921b5 R12: 81007da72000 R13: 0001 R14: R15: 66355f306e616c77 FS: 40800950(0063) GS:804fc000() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00616278 CR3: 79556000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process NetworkManager (pid: 2295, threadinfo 810078fe4000, task 810079f be040) Stack: 803861f8 81007da723a8 81007da723a8 881ec218 81007da72000 81007da7240a 81007da723a0 882da4ba 810078fe57f8 81007d5802e0 Call Trace: [803861f8] led_trigger_set_default+0x3a/0x77 [881ec218] :led_class:led_classdev_register+0xb9/0x10d [882da4ba] :b43:b43_register_led+0x83/0xb6 [882da750] :b43:b43_leds_init+0x263/0x293 [8828501d] :ssb:ssb_pci_switch_core+0x40/0x4b [882cae47] :b43:b43_chip_init+0x56c/0x8d6 [882cb435] :b43:b43_wireless_core_init+0x284/0x766 [882cc585] :b43:b43_start+0x2e/0x6d [8824d8e9] :mac80211:ieee80211_open+0x1b6/0x39d [8039704a] dev_open+0x2f/0x67 [80395c8a] dev_change_flags+0xaa/0x161 [8039db81] do_setlink+0x279/0x34b [8039e60b] rtnetlink_rcv_msg+0x0/0x1dc [8039edcf] rtnl_setlink+0xf5/0x116 [803ab484] netlink_run_queue+0x68/0xf7 [8039e587] rtnetlink_rcv+0x28/0x43 [803aba04] netlink_data_ready+0x12/0x50 [803aa6fa] netlink_sendskb+0x23/0x3c [803ab9df] netlink_sendmsg+0x2ac/0x2bf [80391845] memcpy_fromiovec+0x36/0x66 [8038a98c] sock_sendmsg+0xea/0x107 [8024699f] autoremove_wake_function+0x0/0x2e [8024699f] autoremove_wake_function+0x0/0x2e [8024699f] autoremove_wake_function+0x0/0x2e [8038abc0] sys_sendmsg+0x217/0x28a [803aa9b8] netlink_insert+0x13c/0x14b [8038bb35] sys_getsockname+0x9c/0xb2 [8020bc8e] system_call+0x7e/0x83 Code: 8a 17 88 d0 2a 06 48 ff c6 84 c0 75 09 84 d2 74 05 48 ff c7 RIP [802f38aa] strcmp+0x0/0x1a RSP 810078fe5740 (none):~ # -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Use input-polldev for the rfkill switch
On Wednesday 10 October 2007 16:51:38 Dmitry Torokhov wrote: I don't think that broadcom driver should depend on RFKILL_INPUT... RFKILL_INPUT is a default link between input and rfkill layers but it is by no means a mandatory component. I think proper dependency should be: depends on B43 RFKILL INPUT select INPUT_POLLDEV b43 rfkill support is useless without also having RFKILL_INPUT, as the button reporting is done though it. b43 does _not_ depend on RFKILL_INPUT, but b43-rfkill support is disabled, if there's no RFKILL_INPUT compiled. No, it is not. One can have a userspace daemon claiming the rfkill switch... No, that's impossible with b43. We normally specify dependencies that are needed to build the code, not necessarily to use it. It's like various joystick drivers do not depend on joydev or evdev modules although most people would need these modules as well to use their joysticks. Or SCSI drivers don't depend on sd or sr being selected, etc, etc. Yeah, well. As I said. This is not a dependency. It's an auto-select option, which automatically selects the code. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Use input-polldev for the rfkill switch
On Saturday 29 September 2007 18:52:48 David Woodhouse wrote: Does this bit belong to your other patch? I'm not sure what you are trying to ask. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Leds spinlock SMP compilefix
This was missing an address operator. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-2.6/drivers/net/wireless/b43/leds.c === --- wireless-2.6.orig/drivers/net/wireless/b43/leds.c 2007-09-29 12:44:08.0 +0200 +++ wireless-2.6/drivers/net/wireless/b43/leds.c2007-09-30 00:02:18.0 +0200 @@ -37,14 +37,14 @@ static void b43_led_turn_on(struct b43_w unsigned long flags; u16 ctl; - spin_lock_irqsave(wl-leds_lock, flags); + spin_lock_irqsave(wl-leds_lock, flags); ctl = b43_read16(dev, B43_MMIO_GPIO_CONTROL); if (activelow) ctl = ~(1 led_index); else ctl |= (1 led_index); b43_write16(dev, B43_MMIO_GPIO_CONTROL, ctl); - spin_unlock_irqrestore(wl-leds_lock, flags); + spin_unlock_irqrestore(wl-leds_lock, flags); } static void b43_led_turn_off(struct b43_wldev *dev, u8 led_index, @@ -54,14 +54,14 @@ static void b43_led_turn_off(struct b43_ unsigned long flags; u16 ctl; - spin_lock_irqsave(wl-leds_lock, flags); + spin_lock_irqsave(wl-leds_lock, flags); ctl = b43_read16(dev, B43_MMIO_GPIO_CONTROL); if (activelow) ctl |= (1 led_index); else ctl = ~(1 led_index); b43_write16(dev, B43_MMIO_GPIO_CONTROL, ctl); - spin_unlock_irqrestore(wl-leds_lock, flags); + spin_unlock_irqrestore(wl-leds_lock, flags); } /* Callback from the LED subsystem. */ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Leds spinlock SMP compilefix
On Tuesday 02 October 2007 22:20:53 John W. Linville wrote: I'll just roll this into the b43: LED triggers support patch. Yep, thanks a lot. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Rewrite pwork locking policy.
Implement much easier and more lightweight locking for
the periodic work.
This also removes the last big busywait loop and replaces it
by a sleeping loop.
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-09-28
14:31:48.0 +0200
+++ wireless-2.6/drivers/net/wireless/b43/main.c2007-09-28
15:59:40.0 +0200
@@ -1989,6 +1989,7 @@ void b43_mac_enable(struct b43_wldev *de
{
dev-mac_suspended--;
B43_WARN_ON(dev-mac_suspended 0);
+ B43_WARN_ON(irqs_disabled());
if (dev-mac_suspended == 0) {
b43_write32(dev, B43_MMIO_MACCTL,
b43_read32(dev, B43_MMIO_MACCTL)
@@ -1999,6 +2000,11 @@ void b43_mac_enable(struct b43_wldev *de
b43_read32(dev, B43_MMIO_MACCTL);
b43_read32(dev, B43_MMIO_GEN_IRQ_REASON);
b43_power_saving_ctl_bits(dev, 0);
+
+ /* Re-enable IRQs. */
+ spin_lock_irq(dev-wl-irq_lock);
+ b43_interrupt_enable(dev, dev-irq_savedstate);
+ spin_unlock_irq(dev-wl-irq_lock);
}
}
@@ -2008,23 +2014,34 @@ void b43_mac_suspend(struct b43_wldev *d
int i;
u32 tmp;
+ might_sleep();
+ B43_WARN_ON(irqs_disabled());
B43_WARN_ON(dev-mac_suspended 0);
+
if (dev-mac_suspended == 0) {
+ /* Mask IRQs before suspending MAC. Otherwise
+* the MAC stays busy and won't suspend. */
+ spin_lock_irq(dev-wl-irq_lock);
+ tmp = b43_interrupt_disable(dev, B43_IRQ_ALL);
+ spin_unlock_irq(dev-wl-irq_lock);
+ b43_synchronize_irq(dev);
+ dev-irq_savedstate = tmp;
+
b43_power_saving_ctl_bits(dev, B43_PS_AWAKE);
b43_write32(dev, B43_MMIO_MACCTL,
b43_read32(dev, B43_MMIO_MACCTL)
~B43_MACCTL_ENABLED);
/* force pci to flush the write */
b43_read32(dev, B43_MMIO_MACCTL);
- for (i = 1; i; i--) {
+ for (i = 40; i; i--) {
tmp = b43_read32(dev, B43_MMIO_GEN_IRQ_REASON);
if (tmp B43_IRQ_MAC_SUSPENDED)
goto out;
- udelay(1);
+ msleep(1);
}
b43err(dev-wl, MAC suspend failed\n);
}
- out:
+out:
dev-mac_suspended++;
}
@@ -2373,77 +2390,36 @@ static void do_periodic_work(struct b43_
b43_periodic_every15sec(dev);
}
-/* Estimate a Badness value based on the periodic work
- * state-machine state. Badness is worse (bigger), if the
- * periodic work will take longer.
+/* Periodic work locking policy:
+ * The whole periodic work handler is protected by
+ * wl-mutex. If another lock is needed somewhere in the
+ * pwork callchain, it's aquired in-place, where it's needed.
*/
-static int estimate_periodic_work_badness(unsigned int state)
-{
- int badness = 0;
-
- if (state % 8 == 0) /* every 120 sec */
- badness += 10;
- if (state % 4 == 0) /* every 60 sec */
- badness += 5;
- if (state % 2 == 0) /* every 30 sec */
- badness += 1;
-
-#define BADNESS_LIMIT 4
- return badness;
-}
-
static void b43_periodic_work_handler(struct work_struct *work)
{
- struct b43_wldev *dev =
- container_of(work, struct b43_wldev, periodic_work.work);
- unsigned long flags, delay;
- u32 savedirqs = 0;
- int badness;
+ struct b43_wldev *dev = container_of(work, struct b43_wldev,
+periodic_work.work);
+ struct b43_wl *wl = dev-wl;
+ unsigned long delay;
- mutex_lock(dev-wl-mutex);
+ mutex_lock(wl-mutex);
if (unlikely(b43_status(dev) != B43_STAT_STARTED))
goto out;
if (b43_debug(dev, B43_DBG_PWORK_STOP))
goto out_requeue;
- badness = estimate_periodic_work_badness(dev-periodic_state);
- if (badness BADNESS_LIMIT) {
- spin_lock_irqsave(dev-wl-irq_lock, flags);
- /* Suspend TX as we don't want to transmit packets while
-* we recalibrate the hardware. */
- b43_tx_suspend(dev);
- savedirqs = b43_interrupt_disable(dev, B43_IRQ_ALL);
- /* Periodic work will take a long time, so we want it to
-* be preemtible and release the spinlock. */
- spin_unlock_irqrestore(dev-wl-irq_lock, flags);
- b43_synchronize_irq(dev);
-
- do_periodic_work(dev);
+ do_periodic_work(dev);
- spin_lock_irqsave(dev-wl-irq_lock
