Re: b43 regression
On Dec 10, 2007 2:36 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > I have identified another regression introduced by > commit f04b3787bbce4567e28069a9ec97dcd804626ac7. > > On my device it shows up as broken transmission after > a suspend/resume cycle. The workaround for it is to boot > a known good driver (in my case the vendor driver in OSX) > and then reboot (without turning the machine off) into the > broken driver. > > It seems like we unintentionally removed some significant > initialization step in that patch. I could not identify it, yet. > The patch I sent yesterday did fix two other bugs, but not this one. > > I am trying to find the reason for this. > If someone wants to help searching, the best way would be to look > at that patch I mentioned above and compare the stuff that it > removes to the stuff that it adds. There must be some tiny line > that it removes but does not re-add it at another place. > Four eyes see more than two. > > I have no idea how this bug could be related to the few bugreports > in the redhat bugzilla. Though, one could test that by trying a > kernel that does not include the patch. > > Sorry for the inconvenience. > > -- > Greetings Michael. > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > RE: 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. -- Brennan Ashton Bellingham, Washington "The box said, 'Requires Windows XP or better'. So I installed Linux" ___ 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
Michael Buesch wrote: > > 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. The request_module() call is in the version I just sent you. If rfkill-input is a module, it loads correctly. If the code is built-in or if the code was not built at al, it generates an error; therefore, my error message is a little ambiguous. If I use the CONFIG variables, I could generate really proper messages, but I decided to skip that part. Larry ___ 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: 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: 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
rfkill-input is not automatically loaded
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. Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
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"
b43 regression
I have identified another regression introduced by commit f04b3787bbce4567e28069a9ec97dcd804626ac7. On my device it shows up as broken transmission after a suspend/resume cycle. The workaround for it is to boot a known good driver (in my case the vendor driver in OSX) and then reboot (without turning the machine off) into the broken driver. It seems like we unintentionally removed some significant initialization step in that patch. I could not identify it, yet. The patch I sent yesterday did fix two other bugs, but not this one. I am trying to find the reason for this. If someone wants to help searching, the best way would be to look at that patch I mentioned above and compare the stuff that it removes to the stuff that it adds. There must be some tiny line that it removes but does not re-add it at another place. Four eyes see more than two. I have no idea how this bug could be related to the few bugreports in the redhat bugzilla. Though, one could test that by trying a kernel that does not include the patch. Sorry for the inconvenience. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
