Re: [PATCH] bcm43xx-mac80211: Fix for tx_bias equal to 0xFF
On Saturday 26 May 2007 19:55:30 Larry Finger wrote: > With it, my 4311 connects with bcm43xx-mac80211. Without it, no connection. Ok, it seems to fix the itssi thing, but that re-enables txpower adjustment, which reveals the whole bunch of bugs in there. :) So before I can merge this, I have to fix these bugs there. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix for tx_bias equal to 0xFF
On Saturday 26 May 2007 19:55:30 Larry Finger wrote: > Michael Buesch wrote: > > > > Ok, on which specification bits is this actually based? :) > > txpower_bg still needs a rewrite, and I have a patch for that in > > the pipeline, but it's still buggy due to missing specs stuff. > > > > It is not in the V4 specifications that I have found, but the V3 (softmac) > driver does this "fixup". I cannot find this in the sm driver. Can you give me a hint where to search? > With it, my 4311 connects with bcm43xx-mac80211. Without it, no connection. Ok, nice. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix for tx_bias equal to 0xFF
On Saturday 26 May 2007 23:11:34 Larry Finger wrote: > Michael Buesch wrote: > > On Saturday 26 May 2007 19:55:30 Larry Finger wrote: > >> Michael Buesch wrote: > >>> Ok, on which specification bits is this actually based? :) > >>> txpower_bg still needs a rewrite, and I have a patch for that in > >>> the pipeline, but it's still buggy due to missing specs stuff. > >>> > >> It is not in the V4 specifications that I have found, but the V3 (softmac) > >> driver does this "fixup". > > > > I cannot find this in the sm driver. Can you give me a hint > > where to search? > > > >> With it, my 4311 connects with bcm43xx-mac80211. Without it, no connection. > > > > Ok, nice. > > > > My memory was faulty earlier, but it is coming back. V3 differs in that > txctl1 (the equivalent of > tx_bias) is not initialized to 0xFF, but is given a value of 0-3 in > bcm43xx_default_txctl1. I added > trace code that checked the value being written to radio register 0x52 and > dumped the stack when the > value was still 0xFF. On that basis, I made it look like the code in > bcm43xx_phy_initg when tx_bias > is 0xFF. > > Would you prefer the equivalent of bcm43xx_default_txctl1? That wouldn't be > difficult. Ok, I have patches that are designed to fix this. But still not done. > Are the txpower adjustment bugs a problem with the specs? Is there anything I > can do? I'm not sure what causes this, yet. It's either a bug in estimating the current power or in calculating the new attenuation values. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4306 mini pci trouble
On Wednesday 30 May 2007 22:07:29 Markus Rothe wrote: > Hello, > > I'm trying to use bcm43xx_mac80211 module from wireless-dev git > (checked out today). Unfortunately I've some problems. The device is > not recognized. I cannot "ifconfig ethx up" for example. > > From dmesg: > > [...] > ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) > ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) > ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) > ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) > ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) > ssb: Switching to ChipCommon core, index 0 > ssb: Switching to PCI core, index 4 > ssb: Sonics Silicon Backplane found on PCI device :02:03.0 > bcm43xx_mac80211: Broadcom 4306 WLAN found > ssb: Switching to IEEE 802.11 core, index 1 > bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 > bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 > bcm43xx_mac80211: Radio turned off > wmaster0: Failed to select rate control algorithm > wmaster0: Failed to initialize rate control algorithm > bcm43xx_mac80211: probe of ssb0:0 failed with error -2 > > $ lsmod > Module Size Used by > snd_pcm_oss32160 0 > snd_mixer_oss 12928 2 snd_pcm_oss > snd_seq_oss24960 0 > snd_seq_device 5384 1 snd_seq_oss > snd_seq_midi_event 5504 1 snd_seq_oss > snd_seq37168 4 snd_seq_oss,snd_seq_midi_event > nvidia 4539476 12 > bcm43xx_mac80211 382688 0 > mac80211 114692 1 bcm43xx_mac80211 > cfg80211 12936 1 mac80211 > snd_intel8x0 26140 1 > snd_ac97_codec 87456 1 snd_intel8x0 > ac97_bus2048 1 snd_ac97_codec > snd_pcm52232 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec > snd_timer 15364 2 snd_seq,snd_pcm > snd_page_alloc 7176 2 snd_intel8x0,snd_pcm You must load the rate control algorithm module rc80211-simple, for example. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4306 mini pci trouble
On Wednesday 30 May 2007 23:04:48 Larry Finger wrote: > Michael Buesch wrote: > > On Wednesday 30 May 2007 22:07:29 Markus Rothe wrote: > >> Hello, > >> > >> I'm trying to use bcm43xx_mac80211 module from wireless-dev git > >> (checked out today). Unfortunately I've some problems. The device is > >> not recognized. I cannot "ifconfig ethx up" for example. > >> > >> From dmesg: > >> > >> [...] > >> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) > >> ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) > >> ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) > >> ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) > >> ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) > >> ssb: Switching to ChipCommon core, index 0 > >> ssb: Switching to PCI core, index 4 > >> ssb: Sonics Silicon Backplane found on PCI device :02:03.0 > >> bcm43xx_mac80211: Broadcom 4306 WLAN found > >> ssb: Switching to IEEE 802.11 core, index 1 > >> bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 > >> bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 > >> bcm43xx_mac80211: Radio turned off > >> wmaster0: Failed to select rate control algorithm > >> wmaster0: Failed to initialize rate control algorithm > >> bcm43xx_mac80211: probe of ssb0:0 failed with error -2 > >> > >> $ lsmod > >> Module Size Used by > >> snd_pcm_oss32160 0 > >> snd_mixer_oss 12928 2 snd_pcm_oss > >> snd_seq_oss24960 0 > >> snd_seq_device 5384 1 snd_seq_oss > >> snd_seq_midi_event 5504 1 snd_seq_oss > >> snd_seq37168 4 snd_seq_oss,snd_seq_midi_event > >> nvidia 4539476 12 > >> bcm43xx_mac80211 382688 0 > >> mac80211 114692 1 bcm43xx_mac80211 > >> cfg80211 12936 1 mac80211 > >> snd_intel8x0 26140 1 > >> snd_ac97_codec 87456 1 snd_intel8x0 > >> ac97_bus2048 1 snd_ac97_codec > >> snd_pcm52232 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec > >> snd_timer 15364 2 snd_seq,snd_pcm > >> snd_page_alloc 7176 2 snd_intel8x0,snd_pcm > > > > You must load the rate control algorithm module > > rc80211-simple, for example. > > > > That loads automatically here. > > Why isn't the ssb module shown in the lsmod list? Must be built-in then. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4306 mini pci trouble
On Thursday 31 May 2007 08:21:02 Markus Rothe wrote: > On Wed, 30 May 2007 23:05:38 +0200, > Michael Buesch <[EMAIL PROTECTED]> wrote: > > On Wednesday 30 May 2007 23:04:48 Larry Finger wrote: > > > Michael Buesch wrote: > [snip] > > > That loads automatically here. > > > > > > Why isn't the ssb module shown in the lsmod list? > > > > Must be built-in then. > > yes, ssb was build in. > > On Wed, 30 May 2007 22:46:50 +0200, > Michael Buesch <[EMAIL PROTECTED]> wrote: > > You must load the rate control algorithm module > > rc80211-simple, for example. > > That fixed the problem. Shouldn't the module be loaded automatically? > Something like "if no rate control is loaded then load and use > rc80211-simple else use the already loaded module". > Do you have module autoload support compiled in? Because it loads automatically for me (and Larry and all others :) ) > Unfortunately I have another problem, which might be access point > or laptop related and not a driver problem (as in "the combination was > bought on ebay recently and newer worked so far, though this is the > first attempt"). I'm getting a timeout when connecting to the AP. > > May 31 08:13:44 dell bcm43xx_mac80211: Using hardware based encryption > for keyidx: 0, mac: ff:ff:ff:ff:ff:ff May 31 08:13:45 dell > wlan0_rename: privacy configuration mismatch and mixed-cell disabled - > disassociate May 31 08:13:45 dell bcm43xx_mac80211: Using hardware > based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff May 31 08:13:45 > dell wlan0_rename: Initial auth_alg=0 May 31 08:13:45 dell > wlan0_rename: authenticate with AP 00:09:5b:74:7f:5b May 31 08:13:45 > dell wlan0_rename: Initial auth_alg=0 May 31 08:13:45 dell > wlan0_rename: authenticate with AP 00:09:5b:74:7f:5b May 31 08:13:45 > dell wlan0_rename: Initial auth_alg=0 May 31 08:13:45 dell > wlan0_rename: authenticate with AP 00:09:5b:74:7f:5b May 31 08:13:45 > dell wlan0_rename: authenticate with AP 00:09:5b:74:7f:5b May 31 > 08:13:45 dell wlan0_rename: authenticate with AP 00:09:5b:74:7f:5b May > 31 08:13:46 dell wlan0_rename: authentication with AP 00:09:5b:74:7f:5b > timed out Try to move closer to the AP. > And one last question: Why is eth1 *and* wlan0_rename created? > shouldn't be there only one interface for one device? (I'm using udev > 104 if that matters). Dunno. Ask your udev configuration. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Compaq Presario F557US
On Friday 01 June 2007 01:13:03 John W. M. Stevens wrote: > On Thu, 2007-05-31 at 19:27 +0200, Martin Langer wrote: > > On Thu, May 31, 2007 at 01:10:30PM -0400, Andrew J. Barr wrote: > > > On Thu, 31 May 2007 11:02:37 -0600 > > > "John W. M. Stevens" <[EMAIL PROTECTED]> wrote: > > > > > > > Sorry, the input file is either wrong or not supported by > > > > bcm43xx-fwcutter. This file has an unknown MD5sum > > > > 162475477be5af17346b430446ebdd9d > > > > > > ... > > > > > > > The above message (with different md5sums) was printed out when > > > > attempting to use the tool against *all* of the files extracted from > > > > sp34488.exe. > > > > > > You need to run it against bcmwl5.sys, if I remember correctly. > > > > Nope. There it's either bcmwl6.sys or bcmwl664.sys. I think that > > Broadcom increased it from bcmwl5.sys to bcmwl6.sys for the Vista line. > > > > Nevertheless, the driver file is already supported by the SVN version. > > > > filename : bcmwl664.sys > > version: 4.102.15.61 > > MD5: 97f98e5e6a83585e42b1e1e15716aae8 > > microcodes : 4 5 11 13 > > pcms : 4 5 > > I will use svn top of trunk, then. I was using the stable version (6). Don't use any firmware not supported by the stable fwcutter releases, as it's not supported by the driver. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Locking problem in bcm43xx-mac80211
On Friday 01 June 2007 19:55:24 Larry Finger wrote: > When a 'modprobe -r bcm43xx-mac80211' command is given with the interface up, > the following kernel > BUG is issued: Known. Ignore it for now. I sent out a patch to Jiri to fix this, but it hasn't been acked (yet?). Jiri thinks it introduces a race. I think it doesn't. ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Upgrade to f7 breaks bcm43xx module
On Friday 01 June 2007 20:11:51 John H. wrote: > bcm43xx mac80211: > YOUR FIRMWARE IS TOO OLD. Firmware from binary drivers older than > version 4.x is unsupported. You must upgrade your firmware files. > > I get that now with f7 and 2.6.21 and didn't with fc6 2.6.20. > > However, I read that the error is not what it sounds like. What is > the solution? Well, I tried to make the error message pretty clear. And I'm really out of additional suggestions. But you could try to read the message again. It tells you exactly what to do. ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] bcm43xx-mac80211: Make wireless statistics yield reasonable values
On Friday 01 June 2007 23:16:35 Larry Finger wrote: > The changes contained herein are needed to get reasonable numbers for wireless > statistics in bcm43xx-mac80211. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> If nobody else complains, go for a merge, John. :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Latest GPHY (APHY) init rewrite
Here's latest version of the GPHY (APHY) init rewrite patch.
I fixed a bunch of bugs, but it's still broken.
It applies to my tree.
Index: bu3sch-wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_wa.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ bu3sch-wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_wa.c
2007-06-02 17:33:22.0 +0200
@@ -0,0 +1,668 @@
+/*
+
+ Broadcom BCM43xx wireless driver
+
+ PHY workarounds.
+
+ Copyright (c) 2005 Martin Langer <[EMAIL PROTECTED]>,
+ Copyright (c) 2005-2007 Stefano Brivio <[EMAIL PROTECTED]>
+ Copyright (c) 2005-2007 Michael Buesch <[EMAIL PROTECTED]>
+ Copyright (c) 2005, 2006 Danny van Dyk <[EMAIL PROTECTED]>
+ Copyright (c) 2005, 2006 Andreas Jaggi <[EMAIL PROTECTED]>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; see the file COPYING. If not, write to
+ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor,
+ Boston, MA 02110-1301, USA.
+
+*/
+
+#include "bcm43xx.h"
+#include "bcm43xx_main.h"
+#include "bcm43xx_tables.h"
+#include "bcm43xx_phy.h"
+#include "bcm43xx_wa.h"
+
+static void bcm43xx_wa_papd(struct bcm43xx_wldev *dev)
+{
+ u16 backup;
+
+ backup = bcm43xx_ofdmtab_read16(dev, BCM43xx_OFDMTAB_PWRDYN2, 0);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_PWRDYN2, 0, 7);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_UNKNOWN_APHY, 0, 0);
+ bcm43xx_dummy_transmission(dev);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_PWRDYN2, 0, backup);
+}
+
+static void bcm43xx_wa_auxclipthr(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_phy_write(dev, BCM43xx_PHY_OFDM(0x8E), 0x3800);
+}
+
+static void bcm43xx_wa_afcdac(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_phy_write(dev, 0x0035, 0x03FF);
+ bcm43xx_phy_write(dev, 0x0036, 0x0400);
+}
+
+static void bcm43xx_wa_txdc_offset(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_DC, 0, 0x0051);
+}
+
+void bcm43xx_wa_initgains(struct bcm43xx_wldev *dev)
+{
+ struct bcm43xx_phy *phy = &dev->phy;
+
+ bcm43xx_phy_write(dev, BCM43xx_PHY_LNAHPFCTL, 0x1FF9);
+ bcm43xx_phy_write(dev, BCM43xx_PHY_LPFGAINCTL,
+ bcm43xx_phy_read(dev, BCM43xx_PHY_LPFGAINCTL) & 0xFF0F);
+ if (phy->rev <= 2)
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_LPFGAIN, 0,
0x1FBF);
+ bcm43xx_radio_write16(dev, 0x0002, 0x1FBF);
+
+ bcm43xx_phy_write(dev, 0x0024, 0x4680);
+ bcm43xx_phy_write(dev, 0x0020, 0x0003);
+ bcm43xx_phy_write(dev, 0x001D, 0x0F40);
+ bcm43xx_phy_write(dev, 0x001F, 0x1C00);
+ if (phy->rev <= 3)
+ bcm43xx_phy_write(dev, 0x002A,
+ (bcm43xx_phy_read(dev, 0x002A) & 0x00FF) | 0x0400);
+ else if (phy->rev == 5) {
+ bcm43xx_phy_write(dev, 0x002A,
+ (bcm43xx_phy_read(dev, 0x002A) & 0x00FF) | 0x1A00);
+ bcm43xx_phy_write(dev, 0x00CC, 0x2121);
+ }
+ if (phy->rev >= 3)
+ bcm43xx_phy_write(dev, 0x00BA, 0x3ED5);
+}
+
+static void bcm43xx_wa_divider(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_phy_write(dev, 0x002B, bcm43xx_phy_read(dev, 0x002B) & ~0x0100);
+ bcm43xx_phy_write(dev, 0x008E, 0x58C1);
+}
+
+static void bcm43xx_wa_gt(struct bcm43xx_wldev *dev) /* Gain table. */
+{
+ if (dev->phy.rev <= 2) {
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN2, 0, 15);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN2, 1, 31);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN2, 2, 42);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN2, 3, 48);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN2, 4, 58);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN0, 0, 19);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN0, 1, 19);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN0, 2, 19);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN0, 3, 19);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN0, 4, 21);
+ bcm43xx_ofdmtab_write16(dev, BCM43xx_OFDMTAB_GAIN0, 5, 21);
+
Re: [PATCH] mac80211-bcm43xx : Fix long delays
On Monday 04 June 2007 15:39:40 Marc Pignat wrote: > from: Marc Pignat <[EMAIL PROTECTED]> > > Replace long udelay by mdelay (long udelay are not supported on all arch). > > Signed-off-by: Marc Pignat <[EMAIL PROTECTED]> > > --- > > The file drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c doesn't compile > for > ARM architecture (and possibly others). > > Here is the patch for replacing long (>1000) udelay by corresponding mdelay. > > Regards > > Marc > > --- drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c.orig 2007-06-04 > 14:49:39.0 +0200 > +++ drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c 2007-06-04 > 14:52:26.0 +0200 > @@ -3860,7 +3860,7 @@ void bcm43xx_radio_init2060(struct bcm43 > > err = bcm43xx_radio_selectchannel(dev, BCM43xx_DEFAULT_CHANNEL_A, 0); > assert(err == 0); > - udelay(1000); > + mdelay(1); > } > > static inline > @@ -3997,7 +3997,7 @@ int bcm43xx_radio_selectchannel(struct b > phy->channel = channel; > //XXX: Using the longer of 2 timeouts (8000 vs 2000 usecs). Specs states > // that 2000 usecs might suffice. > - udelay(8000); > + mdelay(8); > Let's not apply this patch. This replaces something idiotic with something braindead. ;) Better make it possible to use msleep. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fixed MAC in monitor mode
On Wednesday 06 June 2007 21:12:19 Chris Hotte wrote: > /* > Hello, I've been lurking for a bit and finally decided to break cover. I > really hate to disturb the list for this question as my understanding > might be less than full when it comes to expected functionality. > > I've been trying to do some network analysis using my 4318. When the > card is put into monitor mode however, the Link Encap for eth1 goes to > UNSPEC and the Mac address is displayed as a 16 byte value separated by > dashes ie: > > Managed vs Monitor mode. > eth1 Link encap:Ethernet HWaddr AA:BB:CC:DD:EE:FF > eth1 Link encap:UNSPEC HWaddr > AA-BB-CC-DD-EE-FF-00-00-00-00-00-00-00-00-00-00 I'd say this is all expected bahaviour. > > This breaks my ability to assign an arbitrary 6 byte MAC address while > in monitor mode. I need to be able to do this. Why on earth would you need to assign some MAC to an interface in monitor mode? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fixed MAC in monitor mode
On Wednesday 06 June 2007 21:45:38 Chris Hotte wrote: > > > Why on earth would you need to assign some MAC to an > > interface in monitor mode. > > Well, as everyone knows the WEP security algorithm is broken. Currently > some of our software still depends on it so were stuck with it. For the > time being I'm doing everything I can do monitor for weakness using > tools like aircrack-ng. http://www.aircrack-ng.org > > So far I've only been able to test my network passively using this 4813 > card due to this behaviour. The packet injection patch currently applies > and works, but has several slowdown issues. However for my purposes this > is fine. I'm not war driving ;-) > > I've watched demonstrations of wlan cards accepting 6 byte MAC > assignments while in monitor mode without complaint on the site above. > If this is contrary to expected behaviour, then I'm thinking they must > be using additional mods. Eh, so? You still didn't say why you need to assign some MAC address to the card then. In monitor mode the card is promisc. That means the MAC filter is bypassed. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4311 very unstable in kernel 2.6.21.4
On Sunday 10 June 2007 07:23:47 Brennan Ashton wrote: > My bcm4311 has become very unsable in the new 2.6.21.4 kernel. It frequently > has core crashes, and recently when i modprobed, caused the system to crash. What is a core crash? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
TX power stuff confusion
I implemented the new stuff for the TX power adjustment and it seems to work fine. Good work on the specs! :) There's one thing left I'm confused about. That's the LO rf-attenuation bb-attenuation tables. So in LO calibration we calculate tables for the attenuation values in these tables http://bcm-v4.sipsolutions.net/802.11/LO/Tables note that these tables have "gaps" and don't include all possible attenuation values a device can be tuned to in the txpower adjustment. So, the LO adjustment with the recalculated attenuation values is part of the TXpower adjustment (last step). If I recalculated the attenuation values, there is a good chance I hit some for which we did not precalibrate the LO tables (the gaps). Of course the LO code complains. I have no idea how this is possible to work. The head of http://bcm-v4.sipsolutions.net/802.11/LO/GPHY/BuildingTheTable says: "The I and Q values are kept for each possible attenuation value and are indexed by RF Attenuation and Baseband Attenuation." But that's not what's described on the same page in the algorithm description. There we do calculate the LO values _just_ for the values in the tables from http://bcm-v4.sipsolutions.net/802.11/LO/Tables which do _not_ include all possible attenuation values. If you want example code, look into my development tree. All my development patches are applied there. The code there spews lots of LO warnings (after waiting some time until power recalibration hits in). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: TX power stuff confusion
On Monday 11 June 2007 07:59:06 Pavel Roskin wrote: > I saw some stack traces and messages That's what this mail was about, in the first place. ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[RFC PATCH] bcm43xx QoS support
This incomplete patch tries to implement QoS support in
the bcm43xx driver.
It's incomplete, because we don't upload the QoS parameters
to the hardware, yet.
http://bcm-v4.sipsolutions.net/802.11/QoS
We might need some stack support to implement this (I'm not
entirely sure, as I didn't read the whole ieee 802.11e, yet).
Does some stack support for QoS exist? We need to upload
some TX-opportunity, Interframe-space and some other values
to the firmware. Not sure where to get them from, yet (didn't
completely read 802.11e, yet :) ).
The bcm43xx device has 6 DMA rings, but I think only 4
are usable for 802.11e QoS. The other two seem to be useful
for APs, though.
This patch also implements per-DMAring-locking. So this
(theoretically) enables the stack to simultaneously transmit
on two (or more) rings. Though, I'm not sure the stack exploits this
behaviour, yet.
Index: bu3sch-wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
===
---
bu3sch-wireless-dev.orig/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
2007-06-02 23:14:46.0 +0200
+++ bu3sch-wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
2007-06-16 00:38:59.0 +0200
@@ -290,6 +290,50 @@ void return_slot(struct bcm43xx_dmaring
ring->used_slots--;
}
+/* Mac80211-queue to bcm43xx-ring mapping */
+static struct bcm43xx_dmaring * priority_to_txring(struct bcm43xx_wldev *dev,
+ int queue_priority)
+{
+ struct bcm43xx_dmaring *ring;
+
+ /* 0 = highest priority */
+ switch (queue_priority) {
+ default:
+ assert(0);
+ /* fallthrough */
+ case 0:
+ ring = dev->dma.tx_ring3;
+ break;
+ case 1:
+ ring = dev->dma.tx_ring2;
+ break;
+ case 2:
+ ring = dev->dma.tx_ring1;
+ break;
+ case 3:
+ ring = dev->dma.tx_ring0;
+ break;
+ case 4:
+ ring = dev->dma.tx_ring4;
+ break;
+ case 5:
+ ring = dev->dma.tx_ring5;
+ break;
+ }
+
+ return ring;
+}
+
+/* Bcm43xx-ring to mac80211-queue mapping */
+static inline int txring_to_priority(struct bcm43xx_dmaring *ring)
+{
+ static const u8 idx_to_prio[] =
+ { 3, 2, 1, 0, 4, 5, };
+
+ return idx_to_prio[ring->index];
+}
+
+
u16 bcm43xx_dmacontroller_base(int dma64bit, int controller_idx)
{
static const u16 map64[] = {
@@ -816,6 +860,7 @@ struct bcm43xx_dmaring * bcm43xx_setup_d
} else
assert(0);
}
+ spin_lock_init(&ring->lock);
#ifdef CONFIG_BCM43XX_MAC80211_DEBUG
ring->last_injected_overflow = jiffies;
#endif
@@ -1171,37 +1216,39 @@ int bcm43xx_dma_tx(struct bcm43xx_wldev
struct sk_buff *skb,
struct ieee80211_tx_control *ctl)
{
- struct bcm43xx_dmaring *ring = dev->dma.tx_ring1;
+ struct bcm43xx_dmaring *ring;
int err = 0;
+ unsigned long flags;
+ ring = priority_to_txring(dev, ctl->queue);
+ spin_lock_irqsave(&ring->lock, flags);
assert(ring->tx);
if (unlikely(free_slots(ring) < SLOTS_PER_PACKET)) {
- /* This should never trigger, as we call
-* ieee80211_stop_queue() when it's full.
-*/
printkl(KERN_ERR PFX "DMA queue overflow\n");
- return NETDEV_TX_BUSY;
+ err = -ENOSPC;
+ goto out_unlock;
}
/* Check if the queue was stopped in mac80211,
-* but we got called nevertheless. */
+* but we got called nevertheless.
+* That would be a mac80211 bug. */
assert(!ring->stopped);
err = dma_tx_fragment(ring, skb, ctl);
if (unlikely(err)) {
printkl(KERN_ERR PFX "DMA tx mapping failure\n");
- return NETDEV_TX_BUSY;
+ goto out_unlock;
}
-
ring->nr_tx_packets++;
if ((free_slots(ring) < SLOTS_PER_PACKET) ||
should_inject_overflow(ring)) {
/* This TX ring is full. */
- /* FIXME: we currently only have one queue, so hardcode queue 0
here. */
- ieee80211_stop_queue(dev->wl->hw, 0);
+ ieee80211_stop_queue(dev->wl->hw, txring_to_priority(ring));
ring->stopped = 1;
}
+out_unlock:
+ spin_unlock_irqrestore(&ring->lock, flags);
- return 0;
+ return err;
}
void bcm43xx_dma_handle_txstatus(struct bcm43xx_wldev *dev,
@@ -1216,6 +1263,9 @@ void bcm43xx_dma_handle_txstatus(struct
ring = parse_cookie(dev, status->cookie, &slot);
if (unlikely(!ring))
return;
+ assert(irqs_disabled());
+ spin_lock(&ring->lock);
+
assert(r
Please pull latest and greatest bcm43xx
John, Please pull for-linville branch of my tree. It contains a lot of bugfixes and makes a _big_ step towards mergability for mainline. It's not 100% ready for a merge, yet, but we are making good progress. The transmission power problems on the 4306, that were one of the big merge blockers, seem almost all fixed. I get good performance now. I also added lots of txpower debugging stuff so one can actually see what's going on and how it's scaling. Together with Michael Wu's sta-locking rewrite patch for mac80211 we have the most critical merge blockers resolved now. I'd like people to test this code. It will spew a big assertion failure and a stacktrace on loading. Ignore that for now. It's known and considered nonfatal for now. The following changes since commit 9181e959da76d85d688d8ec763702ed2f3b4edf9: John W. Linville: rt2x00firmware.c: include delay.h to avoid build error on ppc64 are found in the git repository at: http://bu3sch.de/git/wireless-dev.git/ for-linville Michael Buesch: bcm43xx-mac80211: Don't stop the mac80211 software queues in pwork. Merge branch 'master' of git://git.kernel.org/.../linville/wireless-dev bcm43xx-mac80211: Use the mac80211 provided workqueue bcm43xx-mac80211: Fix mutex leakage in pwork. bcm43xx-mac80211: Flush the workqueue to make sure periodic work has finished. bcm43xx-mac80211: Implement runtime debugging mechanism. bcm43xx-mac80211: Code to inject TX ring overflows. bcm43xx-mac80211: Rewrite the attenuation adjustment. Merge branch 'master' of git://git.kernel.org/.../linville/wireless-dev ssb: Fix maxpwr and itssi read. bcm43xx-mac80211: Add more txpower debugging. bcm43xx-mac80211: add debugfs file to manually control txpower bcm43xx-mac80211: Some LO cleanups Merge branch 'master' of git://git.kernel.org/.../linville/wireless-dev bcm43xx-mac80211: Use the dynamic min/max values for adjusting the attenuation. drivers/net/wireless/mac80211/bcm43xx/bcm43xx.h| 29 + .../wireless/mac80211/bcm43xx/bcm43xx_debugfs.c| 210 + .../wireless/mac80211/bcm43xx/bcm43xx_debugfs.h| 21 + .../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 63 +++ .../net/wireless/mac80211/bcm43xx/bcm43xx_dma.h| 10 drivers/net/wireless/mac80211/bcm43xx/bcm43xx_lo.c | 107 ++-- drivers/net/wireless/mac80211/bcm43xx/bcm43xx_lo.h |6 .../net/wireless/mac80211/bcm43xx/bcm43xx_main.c | 64 +-- .../net/wireless/mac80211/bcm43xx/bcm43xx_phy.c| 515 --- .../net/wireless/mac80211/bcm43xx/bcm43xx_phy.h| 23 + .../net/wireless/mac80211/bcm43xx/bcm43xx_xmit.c | 18 + .../net/wireless/mac80211/bcm43xx/bcm43xx_xmit.h |2 drivers/ssb/pci.c | 12 include/linux/ssb/ssb_regs.h | 12 14 files changed, 693 insertions(+), 399 deletions(-) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] mac80211-bcm43xx : Fix long delays
On Monday 04 June 2007 15:39:40 Marc Pignat wrote: > from: Marc Pignat <[EMAIL PROTECTED]> > > Replace long udelay by mdelay (long udelay are not supported on all arch). > > Signed-off-by: Marc Pignat <[EMAIL PROTECTED]> > > --- > > The file drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c doesn't compile > for > ARM architecture (and possibly others). > > Here is the patch for replacing long (>1000) udelay by corresponding mdelay. > > Regards I committed a better fix for this: http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=818425d293e07f2e7aa84428bf466d1cf9b803b1 -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
New debugging framework in bcm43xx-mac80211
Hi Larry, I just wanted to notify you that I am building up a new dynamic debugging framework in bcm43xx-mac80211. Debugging in the driver is a mess, because you don't get enough useful information out of the driver. My approach is to add boolean debugfs files to dynamically enable verbose (and/or expensive) debugging techniques at runtime, so one can easily track down problems without modifying kernel code. Currently my framework includes debugging features to debug the DMA-ring-overflow, the TX power adjustment and some periodic work debugging. The periodic work and TXpower debugging is probably also useful to you. The pwork debugging allows you do completely stop pwork or to run it faster (every 50msec, instead of every 1sec). This should help in tracking down races or things like that. We had that in the past... Here's the patch which adds the pwork debugging, so you get a clue what I'm talking about. The main new function is bcm43xx_debug(), which is used to check if a debugging feature is enabled. Compiles to 0 for nondebug-builds. http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=402e3940d5e4d4f715ff434197c6b911e09317fc If you have an idea for a place where we should add a dynamic debugging feature, please tell me (and/or submit a patch). Adding a new dyndebug-feature is easy. Just add it to the enum in bcm43xx_debug.h and use the add_dyn_dbg() macro in bcm43xx_debug.c to create the file. (the file is removed automagically). And of course check for the flag somewhere in the code with bcm43xx_debug() ;) . Have fun. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Please pull bcm43xx-mac80211
It's growing..., better pull it :P This log includes all the stuff from the last pull request, too. The following changes since commit 9181e959da76d85d688d8ec763702ed2f3b4edf9: John W. Linville: rt2x00firmware.c: include delay.h to avoid build error on ppc64 are found in the git repository at: http://bu3sch.de/git/wireless-dev.git/ for-linville Johannes Berg: bcm43xx: honour promisc bit even in monitor mode Michael Buesch: bcm43xx-mac80211: Don't stop the mac80211 software queues in pwork. Merge branch 'master' of git://git.kernel.org/.../linville/wireless-dev bcm43xx-mac80211: Use the mac80211 provided workqueue bcm43xx-mac80211: Fix mutex leakage in pwork. bcm43xx-mac80211: Flush the workqueue to make sure periodic work has finished. bcm43xx-mac80211: Implement runtime debugging mechanism. bcm43xx-mac80211: Code to inject TX ring overflows. bcm43xx-mac80211: Rewrite the attenuation adjustment. Merge branch 'master' of git://git.kernel.org/.../linville/wireless-dev ssb: Fix maxpwr and itssi read. bcm43xx-mac80211: Add more txpower debugging. bcm43xx-mac80211: add debugfs file to manually control txpower bcm43xx-mac80211: Some LO cleanups Merge branch 'master' of git://git.kernel.org/.../linville/wireless-dev bcm43xx-mac80211: Use the dynamic min/max values for adjusting the attenuation. ssb: b44 sprom workaround; avoid warning message ssb: Rewrite invariants fetching code. ssb: Replace ceildiv() by DIV_ROUND_UP() bcm43xx-mac80211: Kill all huge udelay()s. bcm43xx-mac80211: Add cond_resched() into LO calibration. bcm43xx-mac80211: Fix rate memory init for A-PHY. bcm43xx-mac80211: Fix MAC address upload. bcm43xx-mac80211: Also write BSSID macfilter. bcm43xx-mac80211: Add pwork debugging. bcm43xx-mac80211: Run TX without taking the global spinlock. drivers/net/wireless/mac80211/bcm43xx/bcm43xx.h| 39 + .../wireless/mac80211/bcm43xx/bcm43xx_debugfs.c| 216 - .../wireless/mac80211/bcm43xx/bcm43xx_debugfs.h| 23 + .../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 189 ++-- .../net/wireless/mac80211/bcm43xx/bcm43xx_dma.h| 12 .../net/wireless/mac80211/bcm43xx/bcm43xx_leds.c |4 drivers/net/wireless/mac80211/bcm43xx/bcm43xx_lo.c | 117 ++-- drivers/net/wireless/mac80211/bcm43xx/bcm43xx_lo.h |6 .../net/wireless/mac80211/bcm43xx/bcm43xx_main.c | 202 .../net/wireless/mac80211/bcm43xx/bcm43xx_pcmcia.c |7 .../net/wireless/mac80211/bcm43xx/bcm43xx_phy.c| 565 --- .../net/wireless/mac80211/bcm43xx/bcm43xx_phy.h| 23 - .../net/wireless/mac80211/bcm43xx/bcm43xx_xmit.c | 48 ++ .../net/wireless/mac80211/bcm43xx/bcm43xx_xmit.h | 17 + drivers/ssb/driver_chipcommon.c| 20 - drivers/ssb/main.c | 49 +- drivers/ssb/pci.c | 76 ++- drivers/ssb/pcmcia.c |7 drivers/ssb/ssb_private.h | 22 - include/linux/ssb/ssb.h| 41 + include/linux/ssb/ssb_regs.h | 12 21 files changed, 1085 insertions(+), 610 deletions(-) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Status for bcm43xx-mac80211 on BCM4311
On Friday 22 June 2007 19:09:41 Larry Finger wrote: > Michael, > > I have now gotten some fairly reproducible iperf results with the latest > version from your tree > using my BCM4311. In general, the transmission rate is higher than the > receive rate. In addition, it > is much more consistent. While receiving, I might get a rate of 2 Mbs, but > the next several are > likely to be 50 Kbs, or less. The other thing I note is that I get no > throughput for speeds that use > OFDM. > > Using my code for setting and fixing the rate, I get the following > transmission rates: > > Rate Set Iperf Rate > > 1 Mbs 1.24 Mbs > 2 2.01 > 5.5 4.13 > 116.58 > > My tx_power settings are as follows: > > larrylap:~ # cat /sys/kernel/debug/bcm43xx_mac80211/phy0/tx_power_g > Control: AUTOMATIC > Baseband attenuation: 0 > Radio attenuation: 3 > TX Mixer Gain: OFF > PA Gain 2dB: OFF > PA Gain 3dB: OFF > > I get the following with tx_power debugging turned on: > > bcm43xx_mac80211: Current TX power output: 19.0 dBm, Desired TX power output: > 18.50 dBm > bcm43xx_mac80211: Tuning TX-power to bbatt(0), rfatt(3), tx_control(0x00), > tx_bias(0x00), tx_magn(0x00) > > Are there any specific settings for tx_power_g that you would like me to try? Nothing specific. Just play around with it a little bit. Try setting maximum and minimum attenuation settings. Try to enable/disable the various gains, etc... Maximum is set by simply setting some big value such as 99. It will clamp that into range then. Also try the UDP mode of iperf. As with TCP mode TX might bias the RX results. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix deviations from OFDM table specs
On Friday 22 June 2007 21:43:43 Larry Finger wrote:
> This patch fixes some differences between the specs in
> http://bcm-v4.sipsolutions.net/802.11/PHY/G/workarounds/WRSSI_offset and
> the bcm43xx-mac80211 code.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> Index: wireless-mb/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
> ===
> --- wireless-mb.orig/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
> +++ wireless-mb/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
> @@ -961,12 +961,8 @@ static void bcm43xx_phy_setupg(struct bc
> if (phy->rev == 1) {
> for (i = 0; i < BCM43xx_TAB_RETARD_SIZE; i++)
> bcm43xx_ofdmtab_write32(dev, 0x2400, i,
> bcm43xx_tab_retard[i]);
> - for (i = 0; i < 4; i++) {
> - bcm43xx_ofdmtab_write16(dev, 0x5404, i, 0x0020);
> - bcm43xx_ofdmtab_write16(dev, 0x5408, i, 0x0020);
> - bcm43xx_ofdmtab_write16(dev, 0x540C, i, 0x0020);
> - bcm43xx_ofdmtab_write16(dev, 0x5410, i, 0x0020);
> - }
> + for (i = 4; i < 20; i++)
> + bcm43xx_ofdmtab_write16(dev, 0x5400, i, 0x0020);
> bcm43xx_phy_agcsetup(dev);
>
> if ((bus->boardinfo.vendor == SSB_BOARDVENDOR_BCM) &&
> @@ -977,7 +973,7 @@ static void bcm43xx_phy_setupg(struct bc
> bcm43xx_ofdmtab_write16(dev, 0x5001, 0, 0x0002);
> bcm43xx_ofdmtab_write16(dev, 0x5002, 0, 0x0001);
> } else {
> - for (i = 0; i <= 0x2F; i++)
> + for (i = 0; i < 0x20; i++)
> bcm43xx_ofdmtab_write16(dev, 0x1000, i, 0x0820);
> bcm43xx_phy_agcsetup(dev);
> bcm43xx_phy_read(dev, 0x0400); /* dummy read */
>
>
Stefano's big patch is supposed to fix this. Though, it doesn't work, yet.
I'll give your patch a try and apply it, if it works fine. Did you test it?
On which devices?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix deviations from OFDM table specs
On Saturday 23 June 2007 04:26:42 Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 22 June 2007 21:43:43 Larry Finger wrote:
> >> This patch fixes some differences between the specs in
> >> http://bcm-v4.sipsolutions.net/802.11/PHY/G/workarounds/WRSSI_offset and
> >> the bcm43xx-mac80211 code.
> >>
> >> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> >> ---
> >>
> >> Index: wireless-mb/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
> >> ===
> >> --- wireless-mb.orig/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
> >> +++ wireless-mb/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
> >> @@ -961,12 +961,8 @@ static void bcm43xx_phy_setupg(struct bc
> >>if (phy->rev == 1) {
> >>for (i = 0; i < BCM43xx_TAB_RETARD_SIZE; i++)
> >>bcm43xx_ofdmtab_write32(dev, 0x2400, i,
> >> bcm43xx_tab_retard[i]);
> >> - for (i = 0; i < 4; i++) {
> >> - bcm43xx_ofdmtab_write16(dev, 0x5404, i, 0x0020);
> >> - bcm43xx_ofdmtab_write16(dev, 0x5408, i, 0x0020);
> >> - bcm43xx_ofdmtab_write16(dev, 0x540C, i, 0x0020);
> >> - bcm43xx_ofdmtab_write16(dev, 0x5410, i, 0x0020);
> >> - }
> >> + for (i = 4; i < 20; i++)
> >> + bcm43xx_ofdmtab_write16(dev, 0x5400, i, 0x0020);
> >>bcm43xx_phy_agcsetup(dev);
> >>
> >>if ((bus->boardinfo.vendor == SSB_BOARDVENDOR_BCM) &&
> >> @@ -977,7 +973,7 @@ static void bcm43xx_phy_setupg(struct bc
> >>bcm43xx_ofdmtab_write16(dev, 0x5001, 0, 0x0002);
> >>bcm43xx_ofdmtab_write16(dev, 0x5002, 0, 0x0001);
> >>} else {
> >> - for (i = 0; i <= 0x2F; i++)
> >> + for (i = 0; i < 0x20; i++)
> >>bcm43xx_ofdmtab_write16(dev, 0x1000, i, 0x0820);
> >>bcm43xx_phy_agcsetup(dev);
> >>bcm43xx_phy_read(dev, 0x0400); /* dummy read */
> >>
> >>
> >
> > Stefano's big patch is supposed to fix this. Though, it doesn't work, yet.
> > I'll give your patch a try and apply it, if it works fine. Did you test it?
> > On which devices?
>
> It has been tested on the BCM4311, where it didn't make much difference. I'll
> be testing it next on
> a phy->rev == 1 BCM4306.
I applied this, but please still test it on your rev1 4306.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.22-rc6, dhcp, promiscuous mode, and other things
On Wednesday 27 June 2007 06:12:08 Ehud Gavron wrote: > Ehud > PS Ok, I thought bcm43xx vs bcm43xx_mac80211 was "soft" because it used > softmac and bcm43xx_mac80211 used the old devicescape-stack which is > alternately the "non-soft" (or hard) stack. If there's a better > terminology, I look forward to being educated. Ehm... "soft" as in "software", not as in "soft pillow" ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.22-rc6, dhcp, promiscuous mode, and other things
On Wednesday 27 June 2007 15:17:31 Michael Buesch wrote: > On Wednesday 27 June 2007 06:12:08 Ehud Gavron wrote: > > Ehud > > PS Ok, I thought bcm43xx vs bcm43xx_mac80211 was "soft" because it used > > softmac and bcm43xx_mac80211 used the old devicescape-stack which is > > alternately the "non-soft" (or hard) stack. If there's a better > > terminology, I look forward to being educated. > > Ehm... "soft" as in "software", not as in "soft pillow" ;) I should probably explain it, though :) "softmac" is a general abbreviation for "Software-based Medium Access Control", Where the medium is the "air" (no, not the air, but the vacuum of the universe, but...). So it's a software based control layer for what's going on in the "air". In contrast to that there are wireless cards that implement a hardware-mac, so the kernel basically just sees the usual network packets, as they come from wired network, too. It's cheaper to create a softmac based card, as you have to do less in silicon or firmware. So it reduces the bare silicon and development costs of the device. The downside is that the CPU in the machine is a little bit busier when transmitting stuff. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Multicast RX and TX both broken
On Friday 13 July 2007 01:15:28 David Woodhouse wrote: > If I run 'tcpdump -p' to refrain from putting it in promiscuous mode, I > don't see the RA packet to 33:33:00:00:00:01. And IPv6 autoconfiguration > doesn't work. So, what if you run promisc? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: can I contribute to the project ?
On Sunday 15 July 2007 17:01:44 167 wrote: > Hello. i'm a programmer that owns an HP pavilion which has a bcm 4319 > wireless card . > Here is the output of lspci -n : > > 06:02.0 0280: 14e4:4319 (rev 02) > i see in the "status" page that the driver for this card is under > development. I've written some programs in c under linux and i took some > courses about digital electronics at the university ,so i was asking > myself if kernel programming in linux is that hard and if i can > contribute to the project and help fixing the driver or help reverse > engineering the specs . If so , where do i start ? do you know some > good (free) book on kernel programming ? I would be happy, if you'd join the reverse engineering team. Currently there's kind of a bottleneck, as our two active people are busy with other things. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
On Friday 20 July 2007 22:41, Larry Finger wrote: > John W. Linville wrote: > > > > ACK...fwiw, I like the "b43" name suggestion. I wonder if that is > > too prone to confusion w/ "b44"? Probably no worse than "ixgb" vs > > "cxgb3" or "e100" vs "e1000" I suppose. > > Today's discussion was very useful for me - I picked up two suggestions that > I have or will be > putting into the code. > > 1. The drivers that use V3 firmware will get a default fwpostfix value of > ".fw3". If the resulting > name fails, it will fallback to a blank value for fwpostfix. Of course, if a > value is supplied, it > will override the default. > > 2. Any b-only driver will contain an alternate PCI ID table that can be > selected by using the > appropriate module option (not yet named). If that option is selected, the > driver will load a > combined b/g table of ID's. This way, it will be easy to supply a work-around > for any user that > cannot get the default 802.11g driver to work. In addition, this fix will not > require mucking with > rc.local. No, don't go the way to make the PCI table selectable by a Kconfig or even worse a dynamic module option. That is _really_ confusing and I really hope everyone upstream rejects such patches. Either a driver does support some hardware, or it doesn't. There is no step inbetween. If bcm43xx-mac80211 for G is not ready for merge, yet, don't strip the IDs from bcm43xx. If bcm43xx-mac80211 for G is ready for production, remove them. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: A problem with shared interrupts
On Thursday 26 July 2007 22:13:54 Larry Finger wrote:
> Michael,
>
> When I try the -mb tree on my old i386 notebook, I get an "irq 11: nobody
> cared"
> message and interrupts for the bcm43xx-mac80211 device are not initialized.
> The
> code in Linville's tree works. The only difference that seems to be important
> is the code returned when a shared interrupt not intended for us is received.
> By making the changes shown below, both trees now work.
>
> I recall you having a discussion with someone over some aspect of shared
> IRQ's,
> but I don't remember the details and I'm too busy (lazy) to go back and look.
>
> Thanks,
>
> Larry
>
>
> Index: wireless-mb/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-mb.orig/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c
> +++ wireless-mb/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c
> @@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
> /* Interrupt handler top-half */
> static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
> {
> - irqreturn_t ret = IRQ_NONE;
> + irqreturn_t ret = IRQ_HANDLED;
> struct bcm43xx_wldev *dev = dev_id;
> u32 reason;
>
> @@ -1517,7 +1517,6 @@ static irqreturn_t bcm43xx_interrupt_han
> reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
> if (reason == 0x) /* shared IRQ */
> goto out;
> - ret = IRQ_HANDLED;
> reason &= bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
> if (!reason)
> goto out;
>
>
I neither think this is the correct solution, nor do I think that this
is the way bcm43xx-softmac does it. This would always return HANDLED, right?
regardless if the IRQ was for bcm43xx or not. I _do_ think that the bug is
in the driver sharing the IRQ with bcm43xx.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix specs typo for baseband attenuation
On Thursday 26 July 2007 20:03:04 Larry Finger wrote: > Michael Buesch wrote: > > > > Last time I checked this code it matched the specs. And that's not too > > long ago. > > Did the specs change? > > We had a complaint that a change in the V3 specs broke a BCM4306/rev 2 card > using bcm43xx - it > received but did not transmit. I verified the breakage and found that > reverting a patch fixed the > problem. I contacted Joseph, who found that he had mixed the branches when > doing the specs. > > This morning, I found that bcm43xx-mac80211 has the same problem. I have not > yet asked Joseph to > recheck the specs; however, the patch I submitted allows my phy->rev == 1 > card to work. Without it, > it does not. I think there is an error in the specs in that place. Ok, nice. I always like some nice explanation like this for this kind of patches. Because changing code based on "Specs changed, dunno why, so let's change this too" are always hairy and broke stuff in the past. :) I'll test and merge this as soon as you resubmitted it. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix specs typo for baseband attenuation
On Thursday 26 July 2007 21:26:01 John W. Linville wrote: > On Thu, Jul 26, 2007 at 01:49:58PM -0500, Larry Finger wrote: > > John W. Linville wrote: > > > > > >Hmmm...well, if you asked to revert it on bcm43xx, why is it appropriate > > >here? > > > > AFAIK, the V4 specs have always had the typo, thus there was no patch > > introducing this error - it is original. On the other hand, the V3 specs > > were modified fairly late in the process, which led to the bcm43xx patch > > that needed to be reverted. I suspect that the V3 changes may have been the > > result of making them match the V4 specs. If that is the case, it made both > > of them wrong. > > > > No matter, the change is needed to make some older cards work. Now I know > > why bcm43xx-mac80211 never worked on my BCM4306 until today. > > OK, I get it...I was looking at the patch dwmw2 slipped into F-7 and > then in my head reverting that (i.e. reversing the reverse patch) -- > my bad! > > Michael, unless you plan to push soon I'll just apply the new patch > to wireless-dev more-or-less immediately? Ok, please apply. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix specs typo for baseband attenuation
On Thursday 26 July 2007 18:33:01 Larry Finger wrote:
> A typo in the specs interchanges the branches in an if statement, which
> breaks operations for a BCM4306/rev 2 that has phy->analog == 1.
>
> Signed-off-by: Larry Finger<[EMAIL PROTECTED]>
> ---
>
> John and Michael,
>
> This patch is made for the wireless-dev tree after the bcm43xx-mac80211
> directory has been moved into drivers/net/wireless, but it needs to be
> applied to the wireless-mb tree as well.
>
> Larry
>
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> ===
> --- wireless-dev/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> @@ -1895,7 +1895,7 @@ void bcm43xx_phy_set_baseband_attenuatio
> bcm43xx_write16(dev, BCM43xx_MMIO_PHY0,
> (bcm43xx_read16(dev, BCM43xx_MMIO_PHY0)
>& 0xFFF0) | baseband_attenuation);
> - } else if (phy->analog == 1) {
> + } else if (phy->analog != 1) {
> bcm43xx_phy_write(dev, BCM43xx_PHY_DACCTL,
> (bcm43xx_phy_read(dev, BCM43xx_PHY_DACCTL)
> & 0xFFC3) | (baseband_attenuation << 2));
>
>
Last time I checked this code it matched the specs. And that's not too
long ago.
Did the specs change?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] [bcm43xx-mac80211] Fix pci flush in bcm43xx_mac_suspend
On Thursday 26 July 2007 07:17:04 Will Dyson wrote:
> Fix bcm43xx_mac_suspend to flush the status register that we wrote to,
> instead of the register where the result will appear. Improve the comment.
>
> I was getting many mac suspend failures, now it only happens occasionally.
>
> Signed-off-by: Will Dyson <[EMAIL PROTECTED]>
> ---
> .../net/wireless/bcm43xx-mac80211/bcm43xx_main.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> index eefc536..4cf671a 100644
> --- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> @@ -1875,7 +1875,8 @@ void bcm43xx_mac_suspend(struct bcm43xx_wldev *dev)
> bcm43xx_write32(dev, BCM43xx_MMIO_STATUS_BITFIELD,
> bcm43xx_read32(dev,
> BCM43xx_MMIO_STATUS_BITFIELD)
> & ~BCM43xx_SBF_MAC_ENABLED);
> - bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read
> */
> + /* force pci to flush the write */
> + bcm43xx_read32(dev, BCM43xx_MMIO_STATUS_BITFIELD);
> for (i = 1; i; i--) {
> tmp = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
> if (tmp & BCM43xx_IRQ_MAC_SUSPENDED)
merged, thanks.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix specs typo for baseband attenuation
On Friday 27 July 2007 11:18:52 David Woodhouse wrote: > I still get constant complaints of 'eth1: duplicate address detected' > due to the fact that it sees its own outgoing packets, and IPv6 doesn't > work. > > Then when unloading the module I get... > > bcm43xx_mac80211: Radio turned off > Freeing alive inet6 address c1cefc80 > unregister_netdevice: waiting for eth1 to become free. Usage count = 2 Sounds like mac80211 problems. Jiri, Michael? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 21:21:20 John W. Linville wrote: > On Fri, Jul 27, 2007 at 06:57:20PM +0200, Michael Buesch wrote: > > The Sonics Silicon Backplane is a mini-bus used on > > various Broadcom chips and embedded devices. > > Devices using the SSB include b44, bcm43xx and various > > Broadcom based wireless routers. > > A b44 and bcm43xx port and a SSB based OHCI driver is available. > > > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > At first glance it looks like there might be some tab/space issues > in some of the #define blocks toward the end of the patch, although > those might be intentional. They are intentional. It's something like this: #define SSB_REGISTER_XX 0xF88 #define SSB_VALUE_FOR_REGISTER_XX 0x0001 #define SSB_MASK_FOR_REGISTER_XX 0xFF00 #define SSB_REGISTER_YY 0xF99 ... > Aside from whatever other style issues that might be identified, I'll > state that this code has been carried in wireless-dev for months and > thereby also spent a lot of time in -mm as well as Fedora (rawhide > and F-7). The code has proven to be reasonably stable and reliable. And it's in the OpenWRT trunk since quite some time. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 21:03:18 Andrew Morton wrote:
> On Fri, 27 Jul 2007 18:57:20 +0200
> Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > The Sonics Silicon Backplane is a mini-bus used on
> > various Broadcom chips and embedded devices.
> > Devices using the SSB include b44, bcm43xx and various
> > Broadcom based wireless routers.
> > A b44 and bcm43xx port and a SSB based OHCI driver is available.
> >
>
> hm, slim pickings for me here. Nice looking code.
>
> checkpatch finds a few coding style glitches. Lots of 80-col violations
> which you might choose ignore (comments on #defines in headers are
> especially hard) but these guys:
I tried to fix most of the checkpatch warning, except these 80col
warnings.
I don't think it's worth the work to fix the 80col stuff, yet.
I develop kernel code in the real console, and I have no problems
with this. Though, I use a wider console than 80col.
Let's better fix the worst 80col violations over time and not now.
> ERROR: "foo * bar" should be "foo *bar"
> #4156: FILE: drivers/ssb/ssb_private.h:119:
> +extern struct ssb_bus * ssb_pci_dev_to_bus(struct pci_dev *pdev);
>
> are worth addressing.
Well, I intentionally wrote that this way, as in my opinion
it it easier to read. I only use this additional space for
functions returning a pointer.
struct foo * function(int a, int b);
vs:
struct foo *function(int a, int b);
But I can change that, if that's really an issue and a
style violation.
> > ...
> >
> > --- /dev/null
> > +++ b/drivers/ssb/driver_pcicore.c
> > @@ -0,0 +1,564 @@
> >
> > ...
> >
> > +u32 pci_iobase = 0x100;
> > +u32 pci_membase = SSB_PCI_DMA;
>
> These are quite poor names for global symbols.
Agreed. I will change this.
> > +static struct resource ssb_pcicore_mem_resource = {
> > + .name = "SSB PCIcore external memory",
> > + .start = SSB_PCI_DMA,
> > + .end= (u32)SSB_PCI_DMA + (u32)SSB_PCI_DMA_SZ - 1,
> > + .flags = IORESOURCE_MEM,
> > +};
>
> start and end here are resource_size_t. Forcing them to u32 seems
> inappropriate.
You're right. I'll fix that.
> > +void ssb_pcicore_init(struct ssb_pcicore *pc)
>
> Please check that all newly-added global symbols do indeed need global scope.
ok.
> > +static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
> > + u8 address, u16 data)
> > +{
> > + const u16 mdio_control = 0x128;
> > + const u16 mdio_data = 0x12C;
> > + u32 v;
> > + int i;
> > +
> > + v = 0x80; /* Enable Preamble Sequence */
> > + v |= 0x2; /* MDIO Clock Divisor */
> > + pcicore_write32(pc, mdio_control, v);
> > +
> > + v = (1 << 30); /* Start of Transaction */
> > + v |= (1 << 28); /* Write Transaction */
> > + v |= (1 << 17); /* Turnaround */
> > + v |= (u32)device << 22;
> > + v |= (u32)address << 18;
> > + v |= data;
> > + pcicore_write32(pc, mdio_data, v);
> > + udelay(10);
>
> mystery udelays are usually worth a comment.
Sure.
> > +static void ssb_buses_lock(void)
> > +{
> > + if (!ssb_is_early_boot)
> > + mutex_lock(&buses_mutex);
> > +}
> > +
> > +static void ssb_buses_unlock(void)
> > +{
> > + if (!ssb_is_early_boot)
> > + mutex_unlock(&buses_mutex);
> > +}
>
> Some comments are neeeded here to explain why we're jumping through this
> hoop.
I added a comment at the declaration of ssb_is_early_boot,
which tries to explain this in detail.
> It's normally OK to take a mutex early in boot, so one wonders
> what's happening.
Hm, I tried that. There were problems. I don't remember this in detail, though.
This is called _really_ early in boot.
> > +EXPORT_SYMBOL(ssb_clockspeed);
>
> Please check that all newly-added exports really need to be exported (I'm
> sure they do, but..)
>
> > +static int ssb_wait_bit(struct ssb_device *dev, u16 reg, u32 bitmask,
> > + int timeout, int set)
> > +{
> > + int i;
> > + u32 val;
> > +
> > + for (i = 0; i < timeout; i++) {
> > + val = ssb_read32(dev, reg);
> > + if (set) {
> > + if (val & bitmask)
> > + return 0;
> > + } else {
> > + if (!(val & bitmask))
> > + return 0;
> > + }
> > + udelay(10);
> > + }
> > + printk(KERN_ERR PFX "Timeout
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 21:38:53 Andrew Morton wrote:
> > > > +static ssize_t ssb_pci_attr_sprom_show(struct device *pcidev,
> > > > + struct device_attribute *attr,
> > > > + char *buf)
> > > > +{
> > > > + struct pci_dev *pdev = container_of(pcidev, struct pci_dev,
> > > > dev);
> > > > + struct ssb_bus *bus;
> > > > + u16 *sprom;
> > > > + int err = -ENODEV;
> > > > + ssize_t count = 0;
> > > > +
> > > > + bus = ssb_pci_dev_to_bus(pdev);
> > > > + if (!bus)
> > > > + goto out;
> > > > + err = -ENOMEM;
> > > > + sprom = kcalloc(SSB_SPROMSIZE_WORDS, sizeof(u16), GFP_KERNEL);
> > > > + if (!sprom)
> > > > + goto out;
> > > > +
> > > > + err = -ERESTARTSYS;
> > > > + if (mutex_lock_interruptible(&bus->pci_sprom_mutex))
> > > > + goto out_kfree;
> > > > + sprom_do_read(bus, sprom);
> > > > + mutex_unlock(&bus->pci_sprom_mutex);
> > > > +
> > > > + count = sprom2hex(sprom, buf, PAGE_SIZE);
> > > > + err = 0;
> > > > +
> > > > +out_kfree:
> > > > + kfree(sprom);
> > > > +out:
> > > > + return err ? err : count;
> > > > +}
> > >
> > > The mutex_lock_interruptible() looks fishy. Some commented explanation of
> > > what it's doing would be good here. It's quite unobvious to this reader.
> > > Cheesy deadlock avoidance? Hope not.
> >
> > No, it's simply to avoid writing the SPROM concurrently.
> > SPROM writing is hairy and we must make sure here that
> > we are the only one accessing the whole bus. We do that
> > by suspending all devices and taking a lock to protect
> > the SPROM from write concurrency.
>
> Sure, but why is the locking interruptible rather than plain old
> mutex_lock()?
Hm, well. We hold this mutex for several seconds, as writing takes
this long. So I simply thought it was worth allowing the waiter
to interrupt here. If you say that's not an issue, I'll be happy
to use mutex_lock() and reduce code complexity in this area.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 22:12:49 Andrew Morton wrote: > On Fri, 27 Jul 2007 21:43:59 +0200 > Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > Sure, but why is the locking interruptible rather than plain old > > > mutex_lock()? > > > > Hm, well. We hold this mutex for several seconds, as writing takes > > this long. So I simply thought it was worth allowing the waiter > > to interrupt here. If you say that's not an issue, I'll be happy > > to use mutex_lock() and reduce code complexity in this area. > > So.. is that what the _interruptible() is for? To allow an impatient user > to ^c > a read? Yeah, I thought so. > If so, that sounds reasonable. It's worth a comment explaining these > decisions > to future readers, because it is hard to work out this sort of thinking just > from the bare C code. Ok, no problem. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm43xx-mac80211: a fix for the shared interrupt problem
On Saturday 28 July 2007 05:36:04 Larry Finger wrote:
> Michael,
>
> I was in the right area with my previous fix to the "irq 11: nobody cared"
> message. I think for shared interrupts, skipping out if the status is not
> BCM43xx_STAT_STARTED is too severe. I added a message printing out the status
> whenever it skipped out, and found many thousands of interrupts with the
> status equal to BCM43xx_STAT_INITIALIZED. The patch below makes the necessary
> change and modifies a couple of asserts that depend on it.
>
> This patch has been tested on BCM4306 and BCM4318 with shared interrupts,
> and BCM4311 without.
>
> Thanks,
>
> Larry
>
>
>
> Index: wireless-mb/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> ===
> --- wireless-mb.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ wireless-mb/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> @@ -1374,7 +1374,7 @@ static void bcm43xx_interrupt_tasklet(st
>
> spin_lock_irqsave(&dev->wl->irq_lock, flags);
>
> - assert(bcm43xx_status(dev) == BCM43xx_STAT_STARTED);
> + assert(bcm43xx_status(dev) >= BCM43xx_STAT_INITIALIZED);
>
> reason = dev->irq_reason;
> for (i = 0; i < ARRAY_SIZE(dma_reason); i++) {
> @@ -1512,7 +1512,7 @@ static irqreturn_t bcm43xx_interrupt_han
>
> spin_lock(&dev->wl->irq_lock);
>
> - if (bcm43xx_status(dev) < BCM43xx_STAT_STARTED)
> + if (bcm43xx_status(dev) < BCM43xx_STAT_INITIALIZED)
> goto out;
> reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
> if (reason == 0x) /* shared IRQ */
> @@ -1522,7 +1522,7 @@ static irqreturn_t bcm43xx_interrupt_han
> if (!reason)
> goto out;
>
> - assert(bcm43xx_status(dev) == BCM43xx_STAT_STARTED);
> + assert(bcm43xx_status(dev) >= BCM43xx_STAT_INITIALIZED);
>
> dev->dma_reason[0] = bcm43xx_read32(dev, BCM43xx_MMIO_DMA0_REASON)
>& 0x0001DC00;
>
>
That's not the right bugfix.
If the interface is not STAT_STARTED, it should _not_ generate IRQs.
The bug is elsewhere in the init routines.
Please find out which IRQ bits are generated for these spurious IRQs.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm43xx-mac80211: a fix for the shared interrupt problem
On Saturday 28 July 2007 22:53:21 Larry Finger wrote: > Michael Buesch wrote: > > > > That's not the right bugfix. > > If the interface is not STAT_STARTED, it should _not_ generate IRQs. > > The bug is elsewhere in the init routines. > > Please find out which IRQ bits are generated for these spurious IRQs. > > > > I trapped those entries where the interface was not STAT_STARTED and got 2 > such interrupts, each > with the IRQ bits set to 0x0001 (READY). They occur between the "30-bit > DMA initialized" and the > "Wireless interface started" messages. Ok, seems like we are missing some dummy reads to drain this IRQ. I'll look at this tomorrow. Thanks for tracking this down. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm43xx-mac80211: a fix for the shared interrupt problem
On Sunday 29 July 2007 01:58, Larry Finger wrote: > Michael Buesch wrote: > > > > Ok, seems like we are missing some dummy reads to drain > > this IRQ. I'll look at this tomorrow. > > Thanks for tracking this down. > > As we shouldn't get any interrupts until STAT_STARTED is reached, I wondered > why interrupts were > enabled so early. As far as I can tell, none of the steps from where > interrupts are enabled to where > STAT_STARTED is set depend on having them enabled; therefore, I tried a patch > that delayed the > enabling of interrupts until after we had reached STAT_STARTED. It works for > all my systems. > > I'm beginning to think that the shared interrupts have nothing to do with the > problem, but it is > more likely caused by peculiarities in the PCMCIA bridge in my ancient laptop. > > Larry > > Index: wireless-mb/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > === > --- wireless-mb.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > +++ wireless-mb/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > @@ -3014,13 +3014,13 @@ static int bcm43xx_wireless_core_start(s > dev->dev->irq); > goto out; > } > - bcm43xx_interrupt_enable(dev, dev->irq_savedstate); > bcm43xx_mac_enable(dev); > > bcm43xx_periodic_tasks_setup(dev); > > ieee80211_start_queues(dev->wl->hw); > bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); > + bcm43xx_interrupt_enable(dev, dev->irq_savedstate); > bcmdbg(dev->wl, "Wireless interface started\n"); > out: > return err; > Yes, that seems to be the correct fix. Thanks. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ad-hoc / master mode support
On Sunday 29 July 2007 03:50, Fernando Toledo wrote: > Hi , is possible to get a ad-hoc or master mode today? > with softmac o mac80211 trees? With mac80211 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx: Replacement of TODO statements in keymac_write
On Tuesday 31 July 2007 17:06:04 Larry Finger wrote:
> Routine keymac_write in bcm43xx has two TODO statements that generate lots of
> useless log output for early chip versions. This patch replaces them with code
> to store the keys.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> Michael,
>
> Is this correct? The whole business of words versus bytes in shared memory
> is very confusing.
No, it's completely broken. It's broken like all the other
hwcrypto stuff in the softmac driver. :)
Please simply remove all that hwcrypto stuff and always force
swcrypto.
> Larry
>
> -
>
> bcm43xx.h |1 +
> bcm43xx_main.c | 21 +
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
> @@ -156,6 +156,7 @@
> /* MacFilter offsets. */
> #define BCM43xx_MACFILTER_SELF 0x
> #define BCM43xx_MACFILTER_ASSOC 0x0003
> +#define BCM43xx_MACFILTER_MAC0x0010
>
> /* Chipcommon registers. */
> #define BCM43xx_CHIPCOMMON_CAPABILITIES 0x04
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -378,6 +378,7 @@ static void bcm43xx_macfilter_clear(stru
> const u8 zero_addr[ETH_ALEN] = { 0 };
>
> bcm43xx_macfilter_set(bcm, offset, zero_addr);
> + bcm43xx_shm_write32(bcm, BCM43xx_SHM_SHARED, 0x003E, 0);
> }
>
> static void bcm43xx_write_mac_bssid_templates(struct bcm43xx_private *bcm)
> @@ -1108,12 +1109,24 @@ static void keymac_write(struct bcm43xx_
> (index * 2) + 1,
> cpu_to_be16(*((u16 *)(addr + 1;
> } else {
> - if (index < 8) {
> - TODO(); /* Put them in the macaddress filter */
> + if (index < 4) {
> + bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_MAC +
> + index * 6, (const u8 *)addr);
> } else {
> - TODO();
> /* Put them BCM43xx_SHM_SHARED, stating index 0x0120.
> -Keep in mind to update the count of keymacs in
> 0x003E as well! */
> +Update the count of keymacs in 0x003E as well */
> + bcm43xx_shm_write32(bcm,
> + BCM43xx_SHM_SHARED,
> + (index - 4) * 6 + 0x120,
> + cpu_to_be32(*addr));
> + bcm43xx_shm_write16(bcm,
> + BCM43xx_SHM_SHARED,
> + (index - 4) * 6 + 0x124,
> + cpu_to_be16(*((u16 *)(addr + 1;
> + bcm43xx_shm_write32(bcm,/* update count */
> + BCM43xx_SHM_SHARED, 0x003E,
> + bcm43xx_shm_read32(bcm,
> + BCM43xx_SHM_SHARED, 0x003E) + 1);
> }
> }
> }
>
>
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
On Wednesday 01 August 2007 01:18:46 Richard Jonsson wrote: > I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be needed. > IMHO it should be selected automatically when debug is selected. Whoops, no. This is a biiig bug and it should _not_ be SELECTed ;) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
On Wednesday 01 August 2007 01:29:36 Larry Finger wrote: > Michael Buesch wrote: > > On Wednesday 01 August 2007 01:18:46 Richard Jonsson wrote: > >> I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be > >> needed. > >> IMHO it should be selected automatically when debug is selected. > > > > Whoops, no. This is a biiig bug and it should _not_ be SELECTed ;) > > Why? My system has CONFIG_DEBUG_FS selected. With not SELECTed I mean the KConfig SELECT statement. That shouldn't be used here. He was talking about "selected automatically", which is what KConfig SELECT does. And I said that this was not desired here. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH FINAL] Merge the Sonics Silicon Backplane subsystem
On Wednesday 01 August 2007, Andrew Morton wrote: > On Sun, 29 Jul 2007 13:24:54 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > > The Sonics Silicon Backplane is a mini-bus used on > > various Broadcom chips and embedded devices. > > Sigh. > > s390: > > drivers/ssb/main.c: In function 'ssb_ssb_read16': > drivers/ssb/main.c:489: error: implicit declaration of function 'readw' > drivers/ssb/main.c: In function 'ssb_ssb_read32': > drivers/ssb/main.c:497: error: implicit declaration of function 'readl' > drivers/ssb/main.c: In function 'ssb_ssb_write16': > drivers/ssb/main.c:505: error: implicit declaration of function 'writew' > drivers/ssb/main.c: In function 'ssb_ssb_write32': > drivers/ssb/main.c:513: error: implicit declaration of function 'writel' > > > we shouldn't be compiling SSB on s390, because: > > config SSB > tristate "Sonics Silicon Backplane support" > depends on EXPERIMENTAL && HAS_IOMEM > > and > > akpm2:/usr/src/25> grep IOMEM .config > CONFIG_NO_IOMEM=y > akpm2:/usr/src/25> > > but > > akpm2:/usr/src/25> grep SSB .config > CONFIG_DCSSBLK=m > CONFIG_SSB=m > CONFIG_SSB_SILENT=y > > well, how did that come about? > > It _has_ to be `select'. It's _always_ `select'. > > yup, it's `select': > > Selected by: B44 && NETDEVICES && NET_ETHERNET || BCM43XX_MAC80211 && > NETDEVICES && !S390 && MAC80211 && WLAN_80211 && EXPERIMENTAL > > > Look. Kconfig's `select' Just. Does. Not. Work. If you find yourself > contemplating using it, please, don sackcloth, take a cold shower and > several analgesics, then have another go, OK? > > ho hum. Ah, yeah. Crap select not caring about dependencies... The problem is that people will kill me, if they don't find bcm43xx in the kconfig anymore, as they have to enable ssb before that. Ya know the flame with Uwe Bugla going crazy about that? :D Same goes for b44. It was always there in kconfig without additional deps, but now (when we merge the b44 port) we would need ssb selected before we see b44. Maybe default SSB to M? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Reason for power problem with bcm43xx
On Wednesday 01 August 2007, Larry Finger wrote: > Guys, > > Tonight I was looking at the output from TXpower debug as I moved my computer > away from the AP, and > began to wonder why the "desired power" was not changing as I did so. After > dumping the portion of > shared memory used in the calculation, I found that addresses 0x0058, 0x005A, > 0x0070 and 0x0072 > always contain 0x7F7F, which is supposed to be the indication that no > transmissions have been sent. > Somewhere we seem to have missed a signal to the firmware to update these > TSSI values, and the > desired power never changes. Suddenly, the low power and the lack of > adaptability with distance are > no longer a mystery. No, the desired power, is the power value we get from mac80211. So it hardly changes. The value from the SHM is the estimated current output power. And it correctly estimates it for me on the 4306. However it does not seem to work on the 4318. It always returns 20db there, which is bogus. I _think_ that on the 4318 the value is generated by one of the new lookup tables. So I think there's a bug in the lookup tables that are written for hwpctl devices. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
On Wednesday 01 August 2007 18:06:36 Larry Finger wrote: > Richard Jonsson wrote: > > I found the problem. I didn't have CONFIG_DEBUG_FS which seems to be needed. > > IMHO it should be selected automatically when debug is selected. > > With debug_fs enabled I can remove and insert the module, scan network and > > associate just fine. > > When 0-4 meters away from AP I get a steady rate of 18.5Mbps with iperf. > > When > > walking further away the transmission stops completely. This is when module > > is loaded and interface brought up next to the AP. I then get 54Mbit > > connection. > > > > When loading the module from 5 metres away I get 1Mbit connection which is > > not > > very stable, but still usable. > > > > Rate doesn't seem to change when signal drops. If it were I'm sure bcm4301 > > would be on par or better than the driver for that other os. > > > > I feel it's very close with this driver. I've never got more than 500kbit > > TX > > speed with the bcm43xx driver. > > I think there are two problems with the driver when walking away from the AP. > The first is that the > driver has not been telling mac80211 that it is time to consider cutting the > transfer rate. The > second is that we currently have no means of increasing the transmit power as > we move further from > the AP. > > A fix for problem #1 is attached. I think I have something for the second, > but it needs more testing. Hm, yes there might be a bug. But I'm not convinced the attached patch was right. I'm not sure what happens in the TX status reports for packets that don't get acked. But I think it would just return not-acked and a retry count of 1. So what we really want here is to check if the retry count is equal to maximum. Well, what is maximum. See the other fixme in that code there where we check the RTS retry count. The retry count is adjustable and currently we don't keep track of it. And there's even a difference between short and long packets. Look for short vs long retry limit. Not that easy to fix, actually. Anyway, I think we should configure the retry limits through cfg80211. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Report on BCM4318 under Fedora 7
On Wednesday 01 August 2007 18:19:59 Andrig T. Miller wrote: > I have been playing with the bcm43xx driver since the beginning, and I > thought I would post what I now see under Fedora 7. > > First, Fedora seems to only have the bcm43xx-mac80211 driver now, and so I > am using the v4 firmware from the link you guys have provided. > > The driver loads, and here is what I get in dmesg: > > 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: Switching to ChipCommon core, index 0 > ssb: Switching to PCI core, index 2 > ssb: Sonics Silicon Backplane found on PCI device :06:02.0 > bcm43xx-phy0: Broadcom 4318 WLAN found > ssb: Switching to IEEE 802.11 core, index 1 > bcm43xx-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 > bcm43xx-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 > bcm43xx-phy0 debug: Radio turned off > wmaster0: Selected rate control algorithm 'simple' > > ifconfig reports the following: > > wlan0 Link encap:Ethernet HWaddr 00:14:A5:B2:AF:40 > inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0 > inet6 addr: fe80::214:a5ff:feb2:af40/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1684 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1648 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:702701 (686.2 KiB) TX bytes:395884 (386.6 KiB) > > wmaster0 Link encap:UNSPEC HWaddr > 00-14-A5-B2-AF-40-00-00-00-00-00-00-00-00-00-00 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > iwconfig reports the following: > > wmaster0 no wireless extensions. > > wlan0 IEEE 802.11g ESSID:"NetGearAndrigAtHome" > Mode:Managed Frequency:2.462 GHz Access Point: > 00:09:5B:B8:BD:75 > Bit Rate=1 Mb/s > Retry min limit:7 RTS thr:off Fragment thr=2346 B > Encryption > key:C61C-1152-BB6D-7512-45B7-F4FA-0165-E96D-8D7B-5920-B634-7DA7-B8EA-991C-14C2-193F > [2] > Link Quality=106/100 Signal level=-38 dBm Noise level=-73 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > iwlist wlan0 scanning reports: > > Cell 02 - Address: 00:09:5B:B8:BD:75 > ESSID:"NetGearAndrigAtHome" > Mode:Master > Channel:11 > Frequency:2.462 GHz (Channel 11) > Quality=37/100 Signal level=-46 dBm Noise level=-72 > dBm > Encryption key:on > IE: WPA Version 1 > Group Cipher : TKIP > Pairwise Ciphers (1) : TKIP > Authentication Suites (1) : PSK > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s > 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s > 48 Mb/s; 54 Mb/s > Extra:tsf=0084cc27 > > I left out my neighbors access point, but this shows mine, and I am > successfully connnecting with WPA Personal. > > The performance is very poor, as it is only connecting at 1 Mb/s, and the > signal strength varies wildly between around 30% to 100% at times. Also, > NetworkManager reports that the driver is bcm43xx-pci, if you look at the > connection information. Not sure what that means, but lsmod reports the > following: > > lsmod | grep bcm > bcm43xx_mac80211 417697 0 > ssb43461 1 bcm43xx_mac80211 > mac80211 165705 2 rc80211_simple,bcm43xx_mac80211 > > So, in short the driver is working, but the bitrate is very low, and it > makes using it nearly impossible. If there is other information I can > provide that would be helpful in improving this, please let me know, and I > will carve out some time to collect it for you. > > By the way, thanks for all the hard work on the driver. It is really > getting better, and if I can get the performance issue solved, I would be > using it instead of my additional PCMCIA card with the Atheros chip set. That's a known bug and I am currently trying to find out why it fails to tune the power to higher levels. Even adjusting power manually doesn't have any effect. So it's not a bug in the power scaling algorithm, but deeper in the attenuation adjustment. Might be some broken table upload. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-
Re: Report on BCM4318 under Fedora 7
On Wednesday 01 August 2007 20:40:59 Larry Finger wrote: > Michael Buesch wrote: > > > > That's a known bug and I am currently trying to find out why it > > fails to tune the power to higher levels. > > Even adjusting power manually doesn't have any effect. So it's not > > a bug in the power scaling algorithm, but deeper in the attenuation > > adjustment. > > Might be some broken table upload. > > > > It is something in the PHY initialization. I don't get sparking performance > with a 4318 using the > new port from softmac to mac80211, but I do get usable performance of at > least 5 Mbs for all rates, > even at 15-20 m from the AP. One thing is that the signal level from iwconfig > is very low at -61 > dBm; whereas, the 4311 gives -37 at the same position relative to the AP. The > noise values are both > -72 dBm. Sure, you are absolutely right. If I define has_hardware_pctl() to always be 0, I get better performance. So we somewhere blow up the hwpctl init. I'm debugging this at the moment. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patch for bcm4301 driver (PHY and radio from bcm43xx, uses mac80211 as MAC layer)
On Wednesday 01 August 2007 20:34:21 Larry Finger wrote: > Michael Buesch wrote: > > > > Hm, yes there might be a bug. > > But I'm not convinced the attached patch was right. > > I'm not sure what happens in the TX status reports for packets that don't > > get acked. But I think it would just return not-acked and a retry count of > > 1. > > So what we really want here is to check if the retry count is equal to > > maximum. > > Well, what is maximum. See the other fixme in that code there where we check > > the RTS retry count. The retry count is adjustable and currently we don't > > keep > > track of it. And there's even a difference between short and long packets. > > Look for short vs long retry limit. > > Not that easy to fix, actually. > > Anyway, I think we should configure the retry limits through cfg80211. > > I thought the firmware did the retries without intervention and would only > come back when those were > exhausted. Why else would the retry count be stored in shared memory? The retry counts are not stored in SHM. They are stored in the TX status report. (The counts in SHM are just debugging stuff) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Report on BCM4318 under Fedora 7
On Wednesday 01 August 2007 20:54:47 Michael Buesch wrote: > On Wednesday 01 August 2007 20:40:59 Larry Finger wrote: > > Michael Buesch wrote: > > > > > > That's a known bug and I am currently trying to find out why it > > > fails to tune the power to higher levels. > > > Even adjusting power manually doesn't have any effect. So it's not > > > a bug in the power scaling algorithm, but deeper in the attenuation > > > adjustment. > > > Might be some broken table upload. > > > > > > > It is something in the PHY initialization. I don't get sparking performance > > with a 4318 using the > > new port from softmac to mac80211, but I do get usable performance of at > > least 5 Mbs for all rates, > > even at 15-20 m from the AP. One thing is that the signal level from > > iwconfig is very low at -61 > > dBm; whereas, the 4311 gives -37 at the same position relative to the AP. > > The noise values are both > > -72 dBm. > > Sure, you are absolutely right. If I define has_hardware_pctl() to > always be 0, I get better performance. So we somewhere blow up > the hwpctl init. I'm debugging this at the moment. No I don't. Hum. But today I get rather good performance (well compared to yesterday) from my tree. Seems to depend on the moonphase or something. I hate benchmarking. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
txpower adjustment bouncing
I analyzed the bouncing of the estimated TX power output versus the desired power. Here's the hacky script to parse dmesg. It takes a number as arg. It's the PHY number. It requires printk times to be enabled in kconfig. Looks pretty good. Though, it begins to bounce at the end. Not sure what happened there. -- Greetings Michael. txpower_on_4306.ods Description: application/vnd.oasis.opendocument.spreadsheet txpower2csv.sh Description: application/shellscript ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Report on BCM4318 under Fedora 7
On Wednesday 01 August 2007 22:16:33 Larry Finger wrote: > Michael Buesch wrote: > > > > No I don't. Hum. > > But today I get rather good performance (well compared to yesterday) > > from my tree. Seems to depend on the moonphase or something. > > > > I hate benchmarking. > > > > I know how you feel. Today, I dug out the frequency analyzer to see how the > power looked. The 4311, > which has the highest transfer numbers, has the lowest peak amplitude - about > -70 dBm. The 4306 has > amplitudes of -50 dBm, but the frequency spread is quite large and > asymmetric. Although it is set > for channel 1, there is a tail that extends to channel 7. The 4318 has even > higher power - it > saturates the detector as does the AP, which is at about the same distance as > the laptops. > > If I bump up the power from 6.75 to 8.75 dBm, the maximum throughput of the > 4311 reaches over 20 > Mbs, which is higher than Windows gets for the same setup. But not with my tree!? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx-mac80211: Provide information to allow transmission rate decreases
On Wednesday 01 August 2007 21:55:42 Larry Finger wrote:
> Michael,
>
> This version saves the long- and short-retry limits in the phy struct
> and only sets excessive retries when one or the other is reached.
>
> Larry
> ---
>
> In bcm43xx-mac80211, the mechanism for decreasing the transmit rate cannot
> be triggered. This may be shown by walking away from the AP with a laptop.
> At some distance, communications will be lost and never recovered because
> the rate decreasing mechanism of rc80211_simple needs to see excessive_retries
> set in the ieee80211_tx_status struct. With this patch, the transmit rate
> will decrease until communications restart.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> @@ -1284,6 +1284,7 @@ void bcm43xx_dma_handle_txstatus(struct
> struct bcm43xx_dmaring *ring;
> struct bcm43xx_dmadesc_generic *desc;
> struct bcm43xx_dmadesc_meta *meta;
> + struct bcm43xx_phy *phy = &dev->phy;
> int slot;
>
> ring = parse_cookie(dev, status->cookie, &slot);
> @@ -1311,6 +1312,10 @@ void bcm43xx_dma_handle_txstatus(struct
>*/
> if (status->acked)
> meta->txstat.flags |= IEEE80211_TX_STATUS_ACK;
> + else
> + if ((status->frame_count >= phy->lrlimit) ||
> + (status->frame_count >= phy->srlimit))
> + meta->txstat.excessive_retries = 1;
No, you need something like
if (is long frame)
if (cnt >= long_limit)
foo;
else
if (cnt >= short_limit)
foo;
And please use variable names like
short_retry_limit or something like that. It's more to type but
soo much easier to read :)
You could probably shorten that by short_retr_lim.
And I think we should store the stuff in struct bcm43xx_wldev, as it's
a mac attribute.
bcm43xx_phy is more about the actual PHY hardware calibration and stuff.
We tell the FW whether it's a long or short frame in the TXheader generation.
> meta->txstat.retry_count = status->frame_count - 1;
> ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb,
> &(meta->txstat));
> /* skb is freed by ieee80211_tx_status_irqsafe() */
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> @@ -562,6 +562,8 @@ struct bcm43xx_phy {
> u16 lofcal;
>
> u16 initval;//FIXME rename?
> + u8 srlimit;
> + u8 lrlimit;
> };
>
> /* Data structures for DMA transmission, per 80211 core. */
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> @@ -,10 +,12 @@ static int bcm43xx_wireless_core_init(st
> tmp = limit_value(modparam_short_retry, 0, 0xF);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SCRATCH,
> BCM43xx_SHM_SC_SRLIMIT, tmp);
> + phy->srlimit = tmp;
> tmp = limit_value(modparam_long_retry, 0, 0xF);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SCRATCH,
> BCM43xx_SHM_SC_LRLIMIT, tmp);
>
> + phy->lrlimit = tmp;
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SHARED,
> BCM43xx_SHM_SH_SFFBLIM, 3);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SHARED,
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC V2] bcm43xx-mac80211: Provide information to allow transmission rate decreases
On Wednesday 01 August 2007 22:56:07 Larry Finger wrote:
> Michael,
>
> I think I took care of your comments in the previous version.
>
> Larry
> ---
>
> In bcm43xx-mac80211, the mechanism for decreasing the transmit rate cannot
> be triggered. This may be shown by walking away from the AP with a laptop.
> At some distance, communications will be lost and never recovered because
> the rate decreasing mechanism of rc80211_simple needs to see excessive_retries
> set in the ieee80211_tx_status struct. With this patch, the transmit rate
> will decrease until communications restart.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> @@ -1311,6 +1311,16 @@ void bcm43xx_dma_handle_txstatus(struct
>*/
> if (status->acked)
> meta->txstat.flags |= IEEE80211_TX_STATUS_ACK;
> + else
> + if (dev->short_preamble) {
Short preamble is something different.
The thing I was talking about is
mac_ctl |= BCM43xx_TX4_MAC_LONGFRAME;
which we do in xmit.c:338.
We currently do it for frames sent with CTS or RTS.
Though, I have no idea how we can easily track the information for each
packet if it was sent with LONGFRAME bit or without.
It needs to be a per-frame-attribute.
I think the txstatus doesn't tell us (but I'm not sure).
> + if (status->frame_count >=
> + dev->short_retry_limit)
> + meta->txstat.excessive_retries
> = 1;
> + } else {
> + if (status->frame_count >=
> + dev->long_retry_limit)
> + meta->txstat.excessive_retries
> = 1;
> + }
> meta->txstat.retry_count = status->frame_count - 1;
> ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb,
> &(meta->txstat));
> /* skb is freed by ieee80211_tx_status_irqsafe() */
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> @@ -707,6 +707,8 @@ struct bcm43xx_wldev {
> bool short_preamble;/* TRUE, if short preamble is enabled.
> */
> bool short_slot;/* TRUE, if short slot timing is
> enabled. */
> bool radio_hw_enable; /* saved state of radio hardware
> enabled state */
> + u8 short_retry_limit;
> + u8 long_retry_limit;
>
> /* PHY/Radio device. */
> struct bcm43xx_phy phy;
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> @@ -,10 +,12 @@ static int bcm43xx_wireless_core_init(st
> tmp = limit_value(modparam_short_retry, 0, 0xF);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SCRATCH,
> BCM43xx_SHM_SC_SRLIMIT, tmp);
> + dev->short_retry_limit = tmp;
> tmp = limit_value(modparam_long_retry, 0, 0xF);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SCRATCH,
> BCM43xx_SHM_SC_LRLIMIT, tmp);
>
> + dev->long_retry_limit = tmp;
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SHARED,
> BCM43xx_SHM_SH_SFFBLIM, 3);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SHARED,
>
>
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC V2] bcm43xx-mac80211: Provide information to allow transmission rate decreases
On Thursday 02 August 2007 11:09:47 Johannes Berg wrote: > On Thu, 2007-08-02 at 00:14 +0200, Michael Buesch wrote: > > > Though, I have no idea how we can easily track the information for each > > packet if it was sent with LONGFRAME bit or without. > > It needs to be a per-frame-attribute. > > I think the txstatus doesn't tell us (but I'm not sure). > > Why do you need to know when you get a tx status? Oh I see. Hm. Well, > mac80211 tells you how much to retry now (Daniel made a patch); you can > select long/short based on that and on tx status simply compare with > that number from the tx control struct. We don't get a "I failed to transmit this" bit from the firmware, so we must work around this my comparing the retries count to the maximum possible retry count. Of course, that's not an ideal solution. Especially because I think When it succeed on the exact last retry, we take it as failure. Though, that's very unlikely it fails 7 times give or take and then suddenly succeeds. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC V2] bcm43xx-mac80211: Provide information to allow transmission rate decreases
On Thursday 02 August 2007 13:18:17 Johannes Berg wrote: > On Thu, 2007-08-02 at 13:11 +0200, Michael Buesch wrote: > > > We don't get a "I failed to transmit this" bit from the firmware, > > Well, if you expect the frame to be acked then you do get a bit 'this > frame was ever acked' Yep, the problem is for frames that don't get acked. If we just check the ack bit, rate control would throttle, just because we sent unacked frames. So if we didn't get an ack, we need to check if we failed, or if... Oh, acutally. Why not simply check the noack bit in the tx_control... :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC V2] bcm43xx-mac80211: Provide information to allow transmission rate decreases
On Thursday 02 August 2007 13:48:39 Johannes Berg wrote: > On Thu, 2007-08-02 at 13:37 +0200, Michael Buesch wrote: > > > If we just check the ack bit, rate control would throttle, just because > > we sent unacked frames. > > Ah but rate control shouldn't actually care about frames that we never > expected an ACK for since there's no way to know for those anyway. So > IMHO the rate control algorithm shouldn't even be called for those > frames. > > > So if we didn't get an ack, we need to check if we failed, or if... > > Oh, acutally. Why not simply check the noack bit in the tx_control... :) > > Works too, but it seems mac80211 should do that. So, what's the point of this "excessive retries" field anyway? We already have an "acked" bit. So if it's not set, but we expected an ack, what's the point of setting excessive retries in the driver? the rc algo sould know _anyway_, as it has the "acked" and the "we wanted to have an ack" bits. confused.. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Thursday 02 August 2007, Geert Uytterhoeven wrote: > On Fri, 27 Jul 2007, Michael Buesch wrote: > > The Sonics Silicon Backplane is a mini-bus used on > > various Broadcom chips and embedded devices. > > Devices using the SSB include b44, bcm43xx and various > > Broadcom based wireless routers. > > A b44 and bcm43xx port and a SSB based OHCI driver is available. > > > --- a/drivers/Kconfig > > +++ b/drivers/Kconfig > > @@ -58,6 +58,8 @@ source "drivers/power/Kconfig" > > > > source "drivers/hwmon/Kconfig" > > > > +source "drivers/ssb/Kconfig" > > + > > source "drivers/mfd/Kconfig" > > > > source "drivers/media/Kconfig" > > > --- /dev/null > > +++ b/drivers/ssb/Kconfig > > @@ -0,0 +1,92 @@ > > +menu "Sonics Silicon Backplane" > > + > > +config SSB > > + tristate "Sonics Silicon Backplane support" > > + depends on EXPERIMENTAL > > Hence this will show up on all platforms? So? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 1/4] bcm43xx-mac80211: Save attenuation values for later use.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c 2007-08-02 17:18:02.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c 2007-08-02 17:18:04.0 +0200 @@ -2118,9 +2118,13 @@ void bcm43xx_phy_xmitpower(struct bcm43x } } } + /* Save the control values */ phy->tx_control = tx_control; bcm43xx_put_attenuation_into_ranges(dev, &bbatt, &rfatt); + phy->rfatt.att = rfatt; + phy->bbatt.att = bbatt; + /* Adjust the hardware */ bcm43xx_phy_lock(dev, phylock_flags); bcm43xx_radio_lock(dev); bcm43xx_set_txpower_g(dev, &phy->bbatt, &phy->rfatt, phy->tx_control); -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 4/4] ssb-chipcommon: Align case statement with switch statement
From: Andrew Morton <[EMAIL PROTECTED]>
Align "case" with "switch"
Cc: Aurelien Jarno <[EMAIL PROTECTED]>
Cc: Felix Fietkau <[EMAIL PROTECTED]>
Cc: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/ssb/driver_chipcommon.c
===
--- wireless-dev.orig/drivers/ssb/driver_chipcommon.c 2007-08-02
17:18:37.0 +0200
+++ wireless-dev/drivers/ssb/driver_chipcommon.c2007-08-02
17:18:46.0 +0200
@@ -263,19 +263,19 @@ void ssb_chipco_get_clockcpu(struct ssb_
*n = chipco_read32(cc, SSB_CHIPCO_CLOCK_N);
*plltype = (cc->capabilities & SSB_CHIPCO_CAP_PLLT);
switch (*plltype) {
- case SSB_PLLTYPE_2:
- case SSB_PLLTYPE_4:
- case SSB_PLLTYPE_6:
- case SSB_PLLTYPE_7:
- *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_MIPS);
- break;
- case SSB_PLLTYPE_3:
- /* 5350 uses m2 to control mips */
- *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_M2);
- break;
- default:
- *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_SB);
- break;
+ case SSB_PLLTYPE_2:
+ case SSB_PLLTYPE_4:
+ case SSB_PLLTYPE_6:
+ case SSB_PLLTYPE_7:
+ *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_MIPS);
+ break;
+ case SSB_PLLTYPE_3:
+ /* 5350 uses m2 to control mips */
+ *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_M2);
+ break;
+ default:
+ *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_SB);
+ break;
}
}
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 0/4] New patch series for merge
Hi John, This patch series catches wireless-dev up to my current wireless-development patchset. Please merge this into wireless-dev. This is the first time I use my new patch managing scripts. So if there are any problems, please complain (patch format, etc...) In future I will drop my git tree and continue development through patch series That's hopefully easier to manage and you can rebase your tree whenever you want (well, you'd do that anyway :P) -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 3/4] ssb-chipcommon: Add function to get processor clock
From: Aurelien Jarno <[EMAIL PROTECTED]>
Add a new function to get the processor clock. It originally comes from
the OpenWrt patches.
Cc: Felix Fietkau <[EMAIL PROTECTED]>
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/ssb/driver_chipcommon.c
===
--- wireless-dev.orig/drivers/ssb/driver_chipcommon.c 2007-08-02
17:18:02.0 +0200
+++ wireless-dev/drivers/ssb/driver_chipcommon.c2007-08-02
17:18:37.0 +0200
@@ -256,6 +256,30 @@ void ssb_chipco_resume(struct ssb_chipco
ssb_chipco_set_clockmode(cc, SSB_CLKMODE_FAST);
}
+/* Get the processor clock */
+void ssb_chipco_get_clockcpu(struct ssb_chipcommon *cc,
+ u32 *plltype, u32 *n, u32 *m)
+{
+ *n = chipco_read32(cc, SSB_CHIPCO_CLOCK_N);
+ *plltype = (cc->capabilities & SSB_CHIPCO_CAP_PLLT);
+ switch (*plltype) {
+ case SSB_PLLTYPE_2:
+ case SSB_PLLTYPE_4:
+ case SSB_PLLTYPE_6:
+ case SSB_PLLTYPE_7:
+ *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_MIPS);
+ break;
+ case SSB_PLLTYPE_3:
+ /* 5350 uses m2 to control mips */
+ *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_M2);
+ break;
+ default:
+ *m = chipco_read32(cc, SSB_CHIPCO_CLOCK_SB);
+ break;
+ }
+}
+
+/* Get the bus clock */
void ssb_chipco_get_clockcontrol(struct ssb_chipcommon *cc,
u32 *plltype, u32 *n, u32 *m)
{
Index: wireless-dev/include/linux/ssb/ssb_driver_chipcommon.h
===
--- wireless-dev.orig/include/linux/ssb/ssb_driver_chipcommon.h 2007-08-02
17:18:02.0 +0200
+++ wireless-dev/include/linux/ssb/ssb_driver_chipcommon.h 2007-08-02
17:18:37.0 +0200
@@ -363,6 +363,8 @@ extern void ssb_chipcommon_init(struct s
extern void ssb_chipco_suspend(struct ssb_chipcommon *cc, pm_message_t state);
extern void ssb_chipco_resume(struct ssb_chipcommon *cc);
+extern void ssb_chipco_get_clockcpu(struct ssb_chipcommon *cc,
+u32 *plltype, u32 *n, u32 *m);
extern void ssb_chipco_get_clockcontrol(struct ssb_chipcommon *cc,
u32 *plltype, u32 *n, u32 *m);
extern void ssb_chipco_timing_init(struct ssb_chipcommon *cc,
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 2/4] ssb/main.c needs dma-mapping.h
From: Andrew Morton <[EMAIL PROTECTED]> drivers/ssb/main.c: In function 'ssb_dma_set_mask': drivers/ssb/main.c:982: error: implicit declaration of function 'dma_supported' Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/ssb/main.c === --- wireless-dev.orig/drivers/ssb/main.c2007-08-02 17:18:02.0 +0200 +++ wireless-dev/drivers/ssb/main.c 2007-08-02 17:18:25.0 +0200 @@ -13,7 +13,7 @@ #include #include #include - +#include #include #include -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC V3] bcm43xx-mac80211: Provide information to allow transmission rate decreases
On Thursday 02 August 2007, Larry Finger wrote:
> Michael,
>
> I couldn't find any long/short indication in the header, so I added a bool
> that
> is set when the frame is sent.
This is not going to work.
But we can do this differently.
You can do something like:
if (!status->acked && !tx_control->noack)
excessive_retries = 1;
So we don't need to care about the retry count.
Anyway. I don't know why we need excessive_retries _at_ _all_.
The rc algorithm does already know if the frame succeed or failed
anyway.
/me shrugs
> Larry
> ---
>
> In bcm43xx-mac80211, the mechanism for decreasing the transmit rate cannot
> be triggered. This may be shown by walking away from the AP with a laptop.
> At some distance, communications will be lost and never recovered because
> the rate decreasing mechanism of rc80211_simple needs to see excessive_retries
> set in the ieee80211_tx_status struct. With this patch, the transmit rate
> will decrease until communications restart.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
> @@ -1311,6 +1311,16 @@ void bcm43xx_dma_handle_txstatus(struct
>*/
> if (status->acked)
> meta->txstat.flags |= IEEE80211_TX_STATUS_ACK;
> + else
> + if (dev->last_frame_long) {
> + if (status->frame_count >=
> + dev->long_retry_limit)
> + meta->txstat.excessive_retries
> = 1;
> + } else {
> + if (status->frame_count >=
> + dev->short_retry_limit)
> + meta->txstat.excessive_retries
> = 1;
> + }
> meta->txstat.retry_count = status->frame_count - 1;
> ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb,
> &(meta->txstat));
> /* skb is freed by ieee80211_tx_status_irqsafe() */
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
> @@ -707,6 +707,9 @@ struct bcm43xx_wldev {
> bool short_preamble;/* TRUE, if short preamble is enabled.
> */
> bool short_slot;/* TRUE, if short slot timing is
> enabled. */
> bool radio_hw_enable; /* saved state of radio hardware
> enabled state */
> + bool last_frame_long; /* true is last frame was long */
> + u8 short_retry_limit;
> + u8 long_retry_limit;
>
> /* PHY/Radio device. */
> struct bcm43xx_phy phy;
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> @@ -,10 +,12 @@ static int bcm43xx_wireless_core_init(st
> tmp = limit_value(modparam_short_retry, 0, 0xF);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SCRATCH,
> BCM43xx_SHM_SC_SRLIMIT, tmp);
> + dev->short_retry_limit = tmp;
> tmp = limit_value(modparam_long_retry, 0, 0xF);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SCRATCH,
> BCM43xx_SHM_SC_LRLIMIT, tmp);
>
> + dev->long_retry_limit = tmp;
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SHARED,
> BCM43xx_SHM_SH_SFFBLIM, 3);
> bcm43xx_shm_write16(dev, BCM43xx_SHM_SHARED,
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c
> @@ -264,6 +264,7 @@ static void generate_txhdr_fw4(struct bc
>* is a 5Ghz packet.
>*/
> txhdr->chan_radio_code = phy->channel;
> + dev->last_frame_long = 0;
>
> /* PHY TX Control word */
> if (rate_ofdm)
> @@ -336,6 +337,7 @@ static void generate_txhdr_fw4(struct bc
> if (rts_rate_fb_ofdm)
> extra_ft |= BCM43xx_TX4_EFT_RTSFBOFDM;
> mac_ctl |= BCM43xx_TX4_MAC_LONGFRAME;
> + dev->last_frame_long = 1;
> }
>
> /* Magic cookie */
>
>
___
Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211
On Thursday 02 August 2007, Larry Finger wrote: > Driver bcm43xx is being ported from using SoftMAC to mac80211. For rewiew, > this series of patches is being prepared; however, the final patch will be > a single entity so that compilation during bisection will not break. > > The contents of the various pieces are as follows: > > 1. Kconfig, Makefile and the main header file. > 2. bcm43xx_debugfs.c and bcm43xx_debugfs.h > 3. bcm43xx_dma.c and bcm43xx_dma.h > 4. bcm43xx_ilt.c, bcm43xx_ilt.h, bcm43xx_leds.c and bcm43xx_leds.h > 5. bcm43xx_main.c and bcm43xx_main.h > 6. bcm43xx_phy.c and bcm43xx_phy.h > 7. bcm43xx_pio.c and bcm43xx_pio.h > 8. bcm43xx_radio.c and bcm43xx_radio.h > 9. bcm43xx_sysfs.c and bcm43xx_sysfs.h > 10: bcm43xx_xmit.c and bcm43xx_xmit.h > > In general, this port consists of taking the files bcm43xx_phy and > bcm43xx_radio from the softmac driver and converting them to work with > the files from the mac80211 version, which has been back-converted to > use V3 firmware. I don't really want to review 10 huge patches that replace X by Y. If the code works, fine. Go for it. You get my ACK, if it works on the hardware where it matters. ;) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Thursday 02 August 2007, Geert Uytterhoeven wrote: > On Thu, 2 Aug 2007, Michael Buesch wrote: > > On Thursday 02 August 2007, Geert Uytterhoeven wrote: > > > On Fri, 27 Jul 2007, Michael Buesch wrote: > > > > The Sonics Silicon Backplane is a mini-bus used on > > > > various Broadcom chips and embedded devices. > > > > Devices using the SSB include b44, bcm43xx and various > > > > Broadcom based wireless routers. > > > > A b44 and bcm43xx port and a SSB based OHCI driver is available. > > > > > > > --- a/drivers/Kconfig > > > > +++ b/drivers/Kconfig > > > > @@ -58,6 +58,8 @@ source "drivers/power/Kconfig" > > > > > > > > source "drivers/hwmon/Kconfig" > > > > > > > > +source "drivers/ssb/Kconfig" > > > > + > > > > source "drivers/mfd/Kconfig" > > > > > > > > source "drivers/media/Kconfig" > > > > > > > --- /dev/null > > > > +++ b/drivers/ssb/Kconfig > > > > @@ -0,0 +1,92 @@ > > > > +menu "Sonics Silicon Backplane" > > > > + > > > > +config SSB > > > > + tristate "Sonics Silicon Backplane support" > > > > + depends on EXPERIMENTAL > > > > > > Hence this will show up on all platforms? > > > > So? > > Shouldn't you add a dependency for platforms where it make sense to have SSB? Well, that's everything where you can stick a PCI, PCMCIA, PC-Card or CF-Card into, plus the MIPS platform, where we have the embedded SSB. That's basically everything, no? Except these strange !HAS_IOMEM platforms, which we already take care of in a followup patch. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC V3] bcm43xx-mac80211: Provide information to allow transmission rate decreases
On Thursday 02 August 2007, Larry Finger wrote: > Michael Buesch wrote: > > On Thursday 02 August 2007, Larry Finger wrote: > >> Michael, > >> > >> I couldn't find any long/short indication in the header, so I added a bool > >> that > >> is set when the frame is sent. > > > > This is not going to work. > > > > But we can do this differently. > > You can do something like: > > > > if (!status->acked && !tx_control->noack) > > excessive_retries = 1; > > > > So we don't need to care about the retry count. > > > > Anyway. I don't know why we need excessive_retries _at_ _all_. > > The rc algorithm does already know if the frame succeed or failed > > anyway. > > Is this what you had in mind? > > Larry > > > @@ -1311,6 +1311,9 @@ void bcm43xx_dma_handle_txstatus(struct > */ > if (status->acked) > meta->txstat.flags |= > IEEE80211_TX_STATUS_ACK; > + else > + if (!(meta->txstat.flags & > IEEE80211_TXCTL_NO_ACK)) > + meta->txstat.excessive_retries = 1; > meta->txstat.retry_count = status->frame_count - 1; > ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb, > &(meta->txstat)); > /* skb is freed by ieee80211_tx_status_irqsafe() */ Yeah, looks good. If you correctly diff that up, I'll queue it up for the next submission to John. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
I will switch to quilt based development
Hey guys, I will drop my git tree and switch to much more lightweight quilt based workflow. My latest patchsets will be published at http://bu3sch.de/patches/wireless-dev/ My scripts do upload the plain patchfiles (plus quilt series file) and additionally a .tar.bz2 file. Upstream submissions will be made by patchbombing John. The advantage of all this is _much_ more lightweight development. A lot more flexible workflow. And more review for patch submissions. If you have any suggestions or improvements, please tell me. --mb ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211
On Thursday 02 August 2007, David Woodhouse wrote: > On Thu, 2007-08-02 at 11:30 -0500, Larry Finger wrote: > > I was hoping this would be your response, but I had to make the > > effort. I'll wait for a couple of days to see if anyone else has any > > comments and send it on to Linville and hope it ends up in -mm fairly > > soon. It _DOES_ work on the hardware. > > My experience is that mac80211 is broken w.r.t IPv6 -- it receives its > own packets. It would be suboptimal for me if the softmac version of > bcm43xx were to go away before that got fixed. > We don't go _away_ from anything until there's no regression anymore. This is a patchset which adds a driver. It does not remove something. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Provide information to allow transmission rate decreases
Thanks, I fixed that and queued it up ;) http://bu3sch.de/patches/wireless-dev/20070803-1186092135/patches/bcm43xx-mac80211-provide-information-to-allow-transmission-rate-decreases.patch On Thursday 02 August 2007, Larry Finger wrote: > In bcm43xx-mac80211, the mechanism for decreasing the transmit rate cannot > be triggered. This may be shown by walking away from the AP with a laptop. > At some distance, communications will be lost and never recovered because > the rate decreasing mechanism of rc80211_simple needs to see excessive_retries > set in the ieee80211_tx_status struct. With this patch, the transmit rate > will decrease until communications restart. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > John and Michael, > > This is based on the wireless-dev tree. > > Larry > > bcm43xx_dma.c |3 +++ > 1 file changed, 3 insertions(+) > > Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c > === > --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c > +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c > @@ -1311,6 +1311,9 @@ void bcm43xx_dma_handle_txstatus(struct >*/ > if (status->acked) > meta->txstat.flags |= IEEE80211_TX_STATUS_ACK; > + else > + if (!(meta->txstat.flags & > IEEE80211_TXCTL_NO_ACK)) > + meta->txstat.excessive_retries = 1; > meta->txstat.retry_count = status->frame_count - 1; > ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb, > &(meta->txstat)); > /* skb is freed by ieee80211_tx_status_irqsafe() */ > > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I will switch to quilt based development
On Friday 03 August 2007, Pavel Roskin wrote: > Hello, Michael! > > On Thu, 2007-08-02 at 22:47 +0200, Michael Buesch wrote: > > Hey guys, > > > > I will drop my git tree and switch to much more > > lightweight quilt based workflow. > > My latest patchsets will be published at > > > > http://bu3sch.de/patches/wireless-dev/ > > > > My scripts do upload the plain patchfiles (plus quilt series file) > > and additionally a .tar.bz2 file. > > Please consider StGIT (http://www.procode.org/stgit/), which works on > top of git. > > I really like that StGIT makes it possible to go back to old patches and > adjust them. And it works with qgit. Patches can be exported and > published. > > It should be possible to make a build system that would compile SSB and > bcm43xx_mac80211 outside the kernel tree. The lightweight tree could > still use the usual path under drivers/ssb and drivers/net/wireless for > the drivers, so that the patches won't need to be adjusted. > > If you have any specific problems with git, it would be great if you > report them to the git mailing list. > No, I don't want git. It's too heavy. And it has major problems when John rebases his tree upstream. With quilt and my scripts I can easily push them upstream to linville, easily publish them on my server. All a matter of typing one command. Going back to old patches works perfect with quilt. And I am not going to maintain out of tree stuff anyway. :) Yes, I looked at stgit before writing my own set of scripts on top of quilt. And I found out that it doesn't quite fit my needs. But thanks for the suggestion, anyway. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Friday 03 August 2007, Daniel Drake wrote: > David Woodhouse wrote: > > My experience is that mac80211 is broken w.r.t IPv6 -- it receives its > > own packets. It would be suboptimal for me if the softmac version of > > bcm43xx were to go away before that got fixed. > > This may be a stack-level issue. This is one of the issues holding back > zd1211rw-mac80211 going into mainline: we have a report that > zd1211rw-softmac works fine with IPv6 but mac80211 only works > occasionally with the same device on the same system. > > Does anyone have any ideas? This is certainly an issue in the packet filtering of mac80211. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Reverse engineering of hwpctl table upload
Does someone have some time to reverse engineer the table upload functions (DC table, TSSI table and the other one I don't remember). They are uploaded in the hwpctl setup. I'm pretty sure there are bugs. If I omit this init on the 4318, I get halfway good looking values for the estimated power output. If I let the tables upload and init, I always get 20dbm, which is obviously wrong. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Reverse engineering of hwpctl table upload
On Friday 03 August 2007, Johannes Berg wrote: > On Fri, 2007-08-03 at 16:00 +0200, Michael Buesch wrote: > > Does someone have some time to reverse engineer the > > table upload functions (DC table, TSSI table and the other one > > I don't remember). They are uploaded in the hwpctl setup. > > I'm pretty sure there are bugs. If I omit this init on the > > 4318, I get halfway good looking values for the estimated > > power output. If I let the tables upload and init, I always > > get 20dbm, which is obviously wrong. > > Can you work without hwpctl for now? The original driver allows you to > switch off hardware power control so the other code *should* work too... What do I have to do? Switch off some hostflag? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC 2/10] Port of bcm43xx from softmac to mac80211
On Friday 03 August 2007, Stefano Brivio wrote:
> On Thu, 02 Aug 2007 10:53:17 -0500
> Larry Finger <[EMAIL PROTECTED]> wrote:
>
> > +static char big_buffer[1024*256];
>
> static char big_buffer[1024 * 256];
>
> > + bcmerr(dev->wl, "debugfs: Board not initialized.\n");
> > res = -EFAULT;
> > goto out_unlock;
> > }
> > - if (sscanf(buf, "%lli", &tsf) != 1) {
> > - printk(KERN_INFO PFX "debugfs: invalid values for
> > \"tsf\"\n");
> > + if (sscanf(buf, "%llu", (unsigned long long *)(&tsf)) != 1) {
> > + bcmerr(dev->wl, "debugfs: invalid values for \"tsf\"\n");
>
> "debugfs: Invalid values for TSF.\n"
>
> > + int i;
> > + int idx;
>
> int i, idx;
No, checkpatch complains about multiple variables per line.
> > +void bcm43xx_debugfs_add_device(struct bcm43xx_wldev *dev)
> > {
> > struct bcm43xx_dfsentry *e;
> > - char devdir[IFNAMSIZ];
> > + struct bcm43xx_txstatus_log *log;
> > + char devdir[16];
> >
> > - assert(bcm);
> > + BCM43xx_BUG_ON(!dev);
> > e = kzalloc(sizeof(*e), GFP_KERNEL);
> > if (!e) {
> > - printk(KERN_ERR PFX "out of memory\n");
> > + bcmerr(dev->wl, "debugfs: add device OOM\n");
>
> "debugfs: OOM while adding device.\n"
>
> > + bcmerr(dev->wl, "debugfs: add device txstatus OOM\n");
>
> "debugfs: OOM while adding device txstatus.\n"
>
> And the same for all the debugfs messages, please be consistent.
>
>
All your comments address code that's not written my larry, but me.
So if you want that fixed, please send patches.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I will switch to quilt based development
On Friday 03 August 2007 01:05:19 Pavel Roskin wrote: > On Fri, 2007-08-03 at 00:22 +0200, Michael Buesch wrote: > > > No, I don't want git. > > It's too heavy. And it has major problems when John rebases his > > tree upstream. > > I'm sure you can help git development if you post your observations to > the git list. It's not a problem with git itself. I use git for almost all of my projects and I'm so happy with this great tool. :) But just in this case; the linux wireless development; I think that patches work better, as there's not the issue of "rebasing" stuff. Rebasing a patchset is easy (quilt push -a; quilt pop -a). But rebasing something that has history in it (git) is more work. We are in a phase of big movement at the moment, where big chunks of code move to mainline. That's simply easier to handle with plain patches that don't carry any history. But I will consider stgit usage for other projects. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Set antenna gains if not in sprom
On Friday 03 August 2007 23:26:21 Larry Finger wrote: > In the sprom for bcm43xx devices, any unprogrammed values are set to all ones. > In the case of antenna gains, the specs indicate that a gain of 2 dBm should > be set if no value is stored. This patch implements that provision. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > === > --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > @@ -3805,6 +3805,12 @@ static void bcm43xx_sprom_fixup(struct s > bus->boardinfo.rev > 0x40) > bus->sprom.r1.boardflags_lo |= BCM43xx_BFL_PACTRL; > > + /* Handle case when gain is not set in sprom */ > + if (bus->sprom.r1.antenna_gain_a == 0xFF) > + bus->sprom.r1.antenna_gain_a = 2; > + if (bus->sprom.r1.antenna_gain_bg == 0xFF) > + bus->sprom.r1.antenna_gain_bg = 2; > + > /* Convert Antennagain values to Q5.2 */ > bus->sprom.r1.antenna_gain_a <<= 2; > bus->sprom.r1.antenna_gain_bg <<= 2; > - > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Queued, thanks! -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Saturday 04 August 2007, Larry Finger wrote: > Pavel Roskin wrote: > > On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote: > > > >> The size of LO array message is not fatal. > > > > I'll really appreciate if it's removed or at least the stack dump is > > suppressed. We know already that it's a problem, so why scare users > > more than they need to? We know where it happens, why show the stack? > > > > I don't think we want to make users ignore stack traces in the kernel > > logs, because we may not hear about unknown problems. > > > > IMHO there are better places for TODO notes than innocent users' kernel > > logs. > > I agree completely; however, I've had my "hands slapped" in the past for > removing that kind of > message. As a result, I leave them alone. Well, there are good reasons for not removing this. The resons include that this message is only shown for the debug build. So if you want it to shut up, don't compile a debug build. It's the task of a debug build to show problems. If you don't care about problems, disable it. This message is not fatal in the sense that is prevents the device from working, but it is very well fatal in the sense that the LO is not adjusted properly. Which means you are probably radiating frequencies that you are not licensed to. Yeah, I'd like to get rid of this message, too. But by fixing the bug and not by hiding it. So any suggestions on how to fix this? The problem is that I'm not sure why we calibrate the LO by these strange tables. Maybe we can fix this by dropping the tables and simply calibrate it for every possible attenuation. These tables have some relation to the hardware power control. So maybe we don't need to adjust the LO from the txpower routines at all, when using hwpctl? (Only on demand of the power vector). ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Saturday 04 August 2007, Will Dyson wrote:
> On 8/4/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > So any suggestions on how to fix this?
> > The problem is that I'm not sure why we calibrate the LO by these strange
> > tables. Maybe we can fix this by dropping the tables and simply
> > calibrate it for every possible attenuation.
> > These tables have some relation to the hardware power control.
> > So maybe we don't need to adjust the LO from the txpower routines
> > at all, when using hwpctl? (Only on demand of the power vector).
>
> I certainly can't claim to understand how the LO calibration is
> supposed to work. I'm especially having a hard time understanding how
> these LO tables (lo->with_padmix and lo->no_padmix) get built.
>
> With that in mind, why can't we just make the table large enough for
> an RFATT of 11?
>
> It seems to work for me on a 4306
>
> Gmail-mangled patch follows (just to show what I'm talking about)
>
> diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
> b/drivers/net/wireless/bcm43xx-mac80211/b
> index 377bda4..1d89fdd 100644
> --- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
> +++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
> @@ -26,7 +26,7 @@ struct bcm43xx_loctl {
> * Use bcm43xx_get_lo_g_ctl() to retrieve a value from the lists.
> */
> struct bcm43xx_txpower_lo_control {
> -#define BCM43xx_NR_BB 9
> +#define BCM43xx_NR_BB 12
> #define BCM43xx_NR_RF 16
> /* LO Control values, with PAD Mixer */
> struct bcm43xx_loctl with_padmix[ BCM43xx_NR_BB ][ BCM43xx_NR_RF ];
> diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> b/drivers/net/wireless/bcm43xx-mac80211/
> index 4db7c5c..8f35d33 100644
> --- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> +++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> @@ -181,12 +181,15 @@ static void generate_bbatt_list(struct bcm43xx_wldev
> *dev,
> { .att = 6, },
> { .att = 7, },
> { .att = 8, },
> + { .att = 9, },
> + { .att = 10, },
> + { .att = 11, },
> };
>
> list->list = bbatt_0;
> list->len = ARRAY_SIZE(bbatt_0);
> list->min_val = 0;
> - list->max_val = 8;
> + list->max_val = 11;
> }
>
> static void bcm43xx_shm_clear_tssi(struct bcm43xx_wldev *dev)
>
>
Well, that's exactly the part I don't understand either.
It's can't be the case that we must extend the tables to get proper operation.
Except there's the same bug in the original driver, too, of course.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Sunday 05 August 2007, Pavel Roskin wrote: > On Sat, 2007-08-04 at 18:47 +0200, Michael Buesch wrote: > > > Yeah, I'd like to get rid of this message, too. But by fixing the > > bug and not by hiding it. > > > > So any suggestions on how to fix this? > > I think you could try to write a detailed explanation of the problem, in > particular, what those tables do, where the numbers come from, what > hardware is affected, what the driver does now, what it should do, and > how to find out the right solution from reverse engineering data. If I knew all these things, I would fix it. > After all, there are working drivers for the chipset, and they can be > reverse engineered. It cannot be a problem with no solution. > > Chances are that you will have some ideas before you finish writing the > message. It happened to me many times. But even if it doesn't happen, > you will make it easy for others to suggest solutions. And you will > give the reverse engineering team some ideas what to look for. Well, it's not that easy. Current code just doesn't make any sense. I do not understand how hardware power control works exactly, so I can't write some detailed message or something. That's probably a chicken and egg problem ;) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] bcm43xx-mac80211: Rescale link quality output
On Sunday 05 August 2007, Larry Finger wrote: > The link quality output from wireless extensions is too small by the ratio > of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the > quantity on the proper scale. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > === > --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de > (phystat0 & > BCM43xx_RX_PHYST0_GAINCTL), > (phystat3 & > BCM43xx_RX_PHYST3_TRSTATE)); > status.noise = dev->stats.link_noise; > - status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ > + /* the next line looks wrong, but is what mac80211 wants */ > + status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; So signal is in percent? Where is this actually documented. I cannot find a hint on what the values of all these things are supposed to be. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] bcm43xx-mac80211: Rescale link quality output
On Sunday 05 August 2007, Larry Finger wrote: > Michael Buesch wrote: > > On Sunday 05 August 2007, Larry Finger wrote: > >> The link quality output from wireless extensions is too small by the ratio > >> of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the > >> quantity on the proper scale. > >> > >> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > >> --- > >> > >> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > >> === > >> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > >> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > >> @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de > >> (phystat0 & > >> BCM43xx_RX_PHYST0_GAINCTL), > >> (phystat3 & > >> BCM43xx_RX_PHYST3_TRSTATE)); > >>status.noise = dev->stats.link_noise; > >> - status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ > >> + /* the next line looks wrong, but is what mac80211 wants */ > >> + status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; > > > > So signal is in percent? > > Where is this actually documented. I cannot find a hint on what > > the values of all these things are supposed to be. > > Yes, it is clear as mud, with the additional complications of mac80211 mixing > the definitions of > signal and rssi (as far as I'm concerned). The scale is set by the following > code snippet in > bcm43xx_wireless_init. > > hw->max_signal = 100; > hw->max_rssi = -110; > hw->max_noise = -110; > > In this code, "signal" is put on a scale of 0 to 100, and rssi and noise on a > scale of -110 to 0 and > are assumed to be dBm. Of course, rssi should be a positive number and signal > should be in dBm, but > my renaming of signal => quality and rssi => signal was shot down, so we are > stuck. > > An alternative to the patch above would be to set hw->max_signal = > BCM43xx_RX_MAX_SSI. In that case, > the line of iwconfig output that reads "Link Quality=83/100 Signal level=-34 > dBm Noise level=-71 > dBm" would have a "Link Quality" of 50/60 instead of 83/100. > > The bottom line is that it is an arbitrary quantity on an arbitrary scale. Is > it better for it to be > XX/100 than YY/60? I think so, but YMMV. Ah, I see. Kind of confusing. :) Well, I would like to do hw->max_signal = MAX_RSSI but it seems to be an unwritten rule that signal scales to 100. At least I never saw a different scale in a driver, yet. So I think I will apply your patch. Thanks! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: Fix regression in interrupt handling
On Monday 06 August 2007, Larry Finger wrote: > Since commit 85a83d26697dd2203ac4e5f33022951f2c3e6e33, "bcm43xx-mac80211: > Rewrite and simplify handling of the initialization status", some PCI > adapters have problems due to interrupts happening before the device status > reaches BCM43xx_STARTED. This patch delays the initial interrupt enable until > after the device status is set. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > John, > > This patch fixes a regression since 2.6.23-rc1. Michael and I have discussed > this > and he has agreed that this is the proper fix. > > Larry > > bcm43xx_main.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > === > --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c > @@ -3014,13 +3014,13 @@ static int bcm43xx_wireless_core_start(s > dev->dev->irq); > goto out; > } > - bcm43xx_interrupt_enable(dev, dev->irq_savedstate); > bcm43xx_mac_enable(dev); > > bcm43xx_periodic_tasks_setup(dev); > > ieee80211_start_queues(dev->wl->hw); > bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); > + bcm43xx_interrupt_enable(dev, dev->irq_savedstate); > bcmdbg(dev->wl, "Wireless interface started\n"); > out: > return err; Queued into my patch series, thanks. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] bcm43xx-mac80211: Rescale link quality output
On Sunday 05 August 2007, Larry Finger wrote: > The link quality output from wireless extensions is too small by the ratio > of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the > quantity on the proper scale. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > === > --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de > (phystat0 & > BCM43xx_RX_PHYST0_GAINCTL), > (phystat3 & > BCM43xx_RX_PHYST3_TRSTATE)); > status.noise = dev->stats.link_noise; > - status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ > + /* the next line looks wrong, but is what mac80211 wants */ > + status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; > if (phystat0 & BCM43xx_RX_PHYST0_OFDM) > status.rate = bcm43xx_plcp_get_bitrate_ofdm(plcp); > else > > Queued into my patch series, thanks. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 4/5] bcm43xx-mac80211: Fix regression in interrupt handling
From: Larry Finger <[EMAIL PROTECTED]> Since commit 85a83d26697dd2203ac4e5f33022951f2c3e6e33, "bcm43xx-mac80211: Rewrite and simplify handling of the initialization status", some PCI adapters have problems due to interrupts happening before the device status reaches BCM43xx_STARTED. This patch delays the initial interrupt enable until after the device status is set. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-03 23:37:34.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-06 14:04:45.0 +0200 @@ -3014,13 +3014,13 @@ static int bcm43xx_wireless_core_start(s dev->dev->irq); goto out; } - bcm43xx_interrupt_enable(dev, dev->irq_savedstate); bcm43xx_mac_enable(dev); bcm43xx_periodic_tasks_setup(dev); ieee80211_start_queues(dev->wl->hw); bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); + bcm43xx_interrupt_enable(dev, dev->irq_savedstate); bcmdbg(dev->wl, "Wireless interface started\n"); out: return err; -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 5/5] bcm43xx-mac80211: Rescale link quality output
From: Larry Finger <[EMAIL PROTECTED]> The link quality output from wireless extensions is too small by the ratio of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the quantity on the proper scale. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c 2007-08-02 16:47:33.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c 2007-08-06 14:09:22.0 +0200 @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de (phystat0 & BCM43xx_RX_PHYST0_GAINCTL), (phystat3 & BCM43xx_RX_PHYST3_TRSTATE)); status.noise = dev->stats.link_noise; - status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ + /* the next line looks wrong, but is what mac80211 wants */ + status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; if (phystat0 & BCM43xx_RX_PHYST0_OFDM) status.rate = bcm43xx_plcp_get_bitrate_ofdm(plcp); else -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 3/5] bcm43xx-mac80211: Set antenna gains if not in sprom
From: Larry Finger <[EMAIL PROTECTED]> In the sprom for bcm43xx devices, any unprogrammed values are set to all ones. In the case of antenna gains, the specs indicate that a gain of 2 dBm should be set if no value is stored. This patch implements that provision. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-02 16:47:33.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-03 23:37:34.0 +0200 @@ -3805,6 +3805,12 @@ static void bcm43xx_sprom_fixup(struct s bus->boardinfo.rev > 0x40) bus->sprom.r1.boardflags_lo |= BCM43xx_BFL_PACTRL; + /* Handle case when gain is not set in sprom */ + if (bus->sprom.r1.antenna_gain_a == 0xFF) + bus->sprom.r1.antenna_gain_a = 2; + if (bus->sprom.r1.antenna_gain_bg == 0xFF) + bus->sprom.r1.antenna_gain_bg = 2; + /* Convert Antennagain values to Q5.2 */ bus->sprom.r1.antenna_gain_a <<= 2; bus->sprom.r1.antenna_gain_bg <<= 2; -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 0/5] New patch series for merge
Hi John, This patch series catches wireless-dev up to my current wireless-development patchset. Please merge this into wireless-dev. -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 1/5] bcm43xx-mac80211: Provide information to allow transmission rate decreases
From: Larry Finger <[EMAIL PROTECTED]>
Fixed-by: Michael Buesch <[EMAIL PROTECTED]>
In bcm43xx-mac80211, the mechanism for decreasing the transmit rate cannot
be triggered. This may be shown by walking away from the AP with a laptop.
At some distance, communications will be lost and never recovered because
the rate decreasing mechanism of rc80211_simple needs to see excessive_retries
set in the ieee80211_tx_status struct. With this patch, the transmit rate
will decrease until communications restart.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-02 23:31:33.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-02 23:39:35.0 +0200
@@ -1309,8 +1309,12 @@ void bcm43xx_dma_handle_txstatus(struct
* status of the transmission.
* Some fields of txstat are already filled in dma_tx().
*/
- if (status->acked)
+ if (status->acked) {
meta->txstat.flags |= IEEE80211_TX_STATUS_ACK;
+ } else {
+ if (!(meta->txstat.control.flags &
IEEE80211_TXCTL_NO_ACK))
+ meta->txstat.excessive_retries = 1;
+ }
meta->txstat.retry_count = status->frame_count - 1;
ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb,
&(meta->txstat));
/* skb is freed by ieee80211_tx_status_irqsafe() */
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-02 16:47:33.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-02 23:39:56.0 +0200
@@ -487,8 +487,12 @@ void bcm43xx_pio_handle_txstatus(struct
queue->tx_devq_packets--;
queue->tx_devq_used -= (packet->skb->len + sizeof(struct
bcm43xx_txhdr_fw4));
- if (status->acked)
+ if (status->acked) {
packet->txstat.flags |= IEEE80211_TX_STATUS_ACK;
+ } else {
+ if (!(packet->txstat.control.flags & IEEE80211_TXCTL_NO_ACK))
+ packet->txstat.excessive_retries = 1;
+ }
packet->txstat.retry_count = status->frame_count - 1;
ieee80211_tx_status_irqsafe(dev->wl->hw, packet->skb,
&(packet->txstat));
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 2/5] Always use dev_kfree_skb_any()
This will always work.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-03 23:35:31.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-03 23:35:33.0 +0200
@@ -441,14 +441,10 @@ void sync_descbuffer_for_device(struct b
static inline
void free_descriptor_buffer(struct bcm43xx_dmaring *ring,
- struct bcm43xx_dmadesc_meta *meta,
- int irq_context)
+ struct bcm43xx_dmadesc_meta *meta)
{
if (meta->skb) {
- if (irq_context)
- dev_kfree_skb_irq(meta->skb);
- else
- dev_kfree_skb(meta->skb);
+ dev_kfree_skb_any(meta->skb);
meta->skb = NULL;
}
}
@@ -777,7 +773,7 @@ static void free_all_descbuffers(struct
unmap_descbuffer(ring, meta->dmaaddr,
ring->rx_buffersize, 0);
}
- free_descriptor_buffer(ring, meta, 0);
+ free_descriptor_buffer(ring, meta);
}
}
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-03 23:35:31.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-03 23:35:33.0 +0200
@@ -208,17 +208,12 @@ static void pio_tx_write_fragment(struct
tx_complete(queue, skb);
}
-static void free_txpacket(struct bcm43xx_pio_txpacket *packet,
- int irq_context)
+static void free_txpacket(struct bcm43xx_pio_txpacket *packet)
{
struct bcm43xx_pioqueue *queue = packet->queue;
- if (packet->skb) {
- if (irq_context)
- dev_kfree_skb_irq(packet->skb);
- else
- dev_kfree_skb(packet->skb);
- }
+ if (packet->skb)
+ dev_kfree_skb_any(packet->skb);
list_move(&packet->list, &queue->txfree);
queue->nr_txfree++;
}
@@ -234,7 +229,7 @@ static int pio_tx_packet(struct bcm43xx_
bcmwarn(queue->dev->wl, "PIO queue too small. "
"Dropping packet.\n");
/* Drop it silently (return success) */
- free_txpacket(packet, 1);
+ free_txpacket(packet);
return 0;
}
assert(queue->tx_devq_packets <= BCM43xx_PIO_MAXTXDEVQPACKETS);
@@ -371,9 +366,9 @@ static void cancel_transfers(struct bcm4
tasklet_disable(&queue->txtask);
list_for_each_entry_safe(packet, tmp_packet, &queue->txrunning, list)
- free_txpacket(packet, 0);
+ free_txpacket(packet);
list_for_each_entry_safe(packet, tmp_packet, &queue->txqueue, list)
- free_txpacket(packet, 0);
+ free_txpacket(packet);
}
static void bcm43xx_destroy_pioqueue(struct bcm43xx_pioqueue *queue)
@@ -498,7 +493,7 @@ void bcm43xx_pio_handle_txstatus(struct
&(packet->txstat));
packet->skb = NULL;
- free_txpacket(packet, 1);
+ free_txpacket(packet);
/* If there are packets on the txqueue, poke the tasklet
* to transmit them.
*/
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Monday 06 August 2007, Pavel Roskin wrote: > On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote: > > > Well, it's not that easy. Current code just doesn't make any sense. > > I do not understand how hardware power control works exactly, so I > > can't write some detailed message or something. > > That's probably a chicken and egg problem ;) > > OK, the existing code complains that one number is larger than another. > You don't want to hide that message, but when I ask you to explain, you > say that the code makes no sense to you. So? > Somehow, it doesn't sound right. Nobody knows the code better than you. > I think communication is essential for development. I know that this is broken (So we don't hide the bug by removing the message), but I don't know how to fix it. Is that such an unusual condition? I simply don't understand how the hardware works. Sure, we can simply hide the bug by changing the code so that it doesn't complain anymore. That's not the issue here. The problem is, that I don't know how to fix this _correctly_. So, that said, I'm not sure which lack of communication you are talking about. I do _not_ know how that stuff works. So, if you want to try understanding it, read the code and specs and try to make sense out of it. I am working on this stuff. I have limited time and I'm not Merlin the magician. So I have to try understanding this stuff. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
On Monday 06 August 2007, John W. Linville wrote: > On Sat, Aug 04, 2007 at 06:47:29PM +0200, Michael Buesch wrote: > > On Saturday 04 August 2007, Larry Finger wrote: > > > Pavel Roskin wrote: > > > > On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote: > > > > > > > >> The size of LO array message is not fatal. > > > > > > > > I'll really appreciate if it's removed or at least the stack dump is > > > > suppressed. We know already that it's a problem, so why scare users > > > > more than they need to? We know where it happens, why show the stack? > > > > > > > > I don't think we want to make users ignore stack traces in the kernel > > > > logs, because we may not hear about unknown problems. > > > > > > > > IMHO there are better places for TODO notes than innocent users' kernel > > > > logs. > > > > > > I agree completely; however, I've had my "hands slapped" in the past for > > > removing that kind of > > > message. As a result, I leave them alone. > > > > Well, there are good reasons for not removing this. > > The resons include that this message is only shown for the debug build. > > So if you want it to shut up, don't compile a debug build. > > Is there a real need for the call to dump_stack on err? Isn't the > printk (bcmdbg) good enough? Well, without a stacktrace you don't know who caused the error. We can remove that. But I still don't know what we gain from removing useful debug messages. If you don't care about bcm43xx bugs, simply disable bcm43xx debugging. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
On Monday 06 August 2007, Larry Finger wrote: > Michael Buesch wrote: > > > > Well, without a stacktrace you don't know who caused the error. > > We can remove that. But I still don't know what we gain from > > removing useful debug messages. If you don't care about bcm43xx bugs, simply > > disable bcm43xx debugging. > > Michael, I agree with you in general, but in this case we know that the line > "bbatt.att = 11" in > bcm43xx_phy_init_pctl leads to this error message. Why don't we change it to > 'bbatt.att = 8' to > eliminate this particular error message? That way the debugging info can stay > in without polluting > everyone's log. Because that would simply be plain wrong. The specs says we have to write 11. So we write 11 and not something else to workaround bugs in other parts of the code. I don't feel comfortable with introducing bugs to hide other bugs. Someone must reverse engineer all that stuff again. But currently we have nobody with enough time to do this. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx-mac80211: Add TX power set file to debugfs
On Monday 06 August 2007 22:22:14 Larry Finger wrote:
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> @@ -2762,12 +2762,11 @@ static int bcm43xx_dev_config(struct iee
> }
>
> /* Adjust the desired TX power level. */
> - if (conf->power_level != 0) {
> - if (conf->power_level != phy->power_level) {
> - phy->power_level = conf->power_level;
> - bcm43xx_phy_xmitpower(dev);
> - }
> - }
> + if (conf->power_level != 0 && phy->power_level == 0) {
> + phy->power_level = conf->power_level;
> + } else
> + phy->power_level = 10;
> + bcm43xx_phy_xmitpower(dev);
No, what's that? I disagree with that.
This breaks power adjustment.
>
> /* Hide/Show the SSID (AP mode only). */
> if (conf->flags & IEEE80211_CONF_SSID_HIDDEN) {
>
>
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx-mac80211: Add TX power set file to debugfs
On Monday 06 August 2007 22:36:49 Larry Finger wrote:
> Michael Buesch wrote:
> > On Monday 06 August 2007 22:22:14 Larry Finger wrote:
> >> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> >> ===
> >> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> >> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
> >> @@ -2762,12 +2762,11 @@ static int bcm43xx_dev_config(struct iee
> >>}
> >>
> >>/* Adjust the desired TX power level. */
> >> - if (conf->power_level != 0) {
> >> - if (conf->power_level != phy->power_level) {
> >> - phy->power_level = conf->power_level;
> >> - bcm43xx_phy_xmitpower(dev);
> >> - }
> >> - }
> >> + if (conf->power_level != 0 && phy->power_level == 0) {
> >> + phy->power_level = conf->power_level;
> >> + } else
> >> + phy->power_level = 10;
> >> + bcm43xx_phy_xmitpower(dev);
> >
> > No, what's that? I disagree with that.
> > This breaks power adjustment.
> >
>
> I just discovered that it fails. When I find the problem, I'll resubmit. Is
> the debugfs part right?
I think so.
Although, (I think you know that), it does not immediately
reconfigure the power, but waits for the next pwork with enough
tssi information.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC V2] bcm43xx-mac80211: Add TX power set file to debugfs
On Monday 06 August 2007 22:55:30 Larry Finger wrote:
> For testing purposes, this patch adds a file named "power_level" to the
> debugfs for bcm43xx-mac80211. If this file is read, it returns the current
> setting for the "Desired power level". Writing a number between 5 and 18
> will set that value as the new value for the desired power setting.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> Michael,
>
> The error before is fixed in this version.
>
> Larry
>
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
> @@ -151,6 +151,74 @@ out_unlock_bb:
> return res;
> }
>
> +static ssize_t power_read_file(struct file *file, char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct bcm43xx_wldev *dev = file->private_data;
> + const size_t len = ARRAY_SIZE(big_buffer);
> + char *buf = big_buffer;
> + size_t pos = 0;
> + ssize_t res;
> + unsigned long flags;
> +
> + mutex_lock(&big_buffer_mutex);
> + mutex_lock(&dev->wl->mutex);
> + spin_lock_irqsave(&dev->wl->irq_lock, flags);
> + if (bcm43xx_status(dev) < BCM43xx_STAT_STARTED) {
> + fappend("Board not initialized.\n");
> + goto out;
> + }
> + fappend("%d dBm\n",dev->phy.power_level);
> +
> +out:
> + spin_unlock_irqrestore(&dev->wl->irq_lock, flags);
> + mutex_unlock(&dev->wl->mutex);
> + res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
> + mutex_unlock(&big_buffer_mutex);
> +
> + return res;
> +}
> +
> +static ssize_t power_write_file(struct file *file, const char __user
> *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct bcm43xx_wldev *dev = file->private_data;
> + char *buf = big_buffer;
> + ssize_t buf_size;
> + ssize_t res;
> + unsigned long flags;
> + int power;
> +
> + mutex_lock(&big_buffer_mutex);
> + buf_size = min(count, ARRAY_SIZE(big_buffer) - 1);
> + if (copy_from_user(buf, user_buf, buf_size)) {
> + res = -EFAULT;
> + goto out_unlock_bb;
> + }
> + mutex_lock(&dev->wl->mutex);
> + spin_lock_irqsave(&dev->wl->irq_lock, flags);
> + if (bcm43xx_status(dev) < BCM43xx_STAT_STARTED) {
> + bcmerr(dev->wl, "debugfs: Board not initialized.\n");
> + res = -EFAULT;
> + goto out_unlock;
> + }
> + if ((sscanf(buf, "%d", &power) != 1) || (power > 18 || power < 5)) {
> + bcmerr(dev->wl, "debugfs: Invalid values for power level\n");
> + res = -EINVAL;
> + goto out_unlock;
> + }
> + dev->phy.power_level = power;
> + res = buf_size;
> +
> +out_unlock:
> + spin_unlock_irqrestore(&dev->wl->irq_lock, flags);
> + mutex_unlock(&dev->wl->mutex);
> +out_unlock_bb:
> + mutex_unlock(&big_buffer_mutex);
> +
> + return res;
> +}
> +
> static ssize_t txstat_read_file(struct file *file, char __user *userbuf,
> size_t count, loff_t *ppos)
> {
> @@ -405,6 +473,12 @@ static struct file_operations restart_fo
> .open = open_file_generic,
> };
>
> +static struct file_operations power_fops = {
> + .read = power_read_file,
> + .write = power_write_file,
> + .open = open_file_generic,
> +};
> +
>
> int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
> {
> @@ -495,6 +569,11 @@ void bcm43xx_debugfs_add_device(struct b
> if (IS_ERR(e->dentry_restart))
> e->dentry_restart = NULL;
>
> + e->dentry_power = debugfs_create_file("power_level", 0600, e->subdir,
> + dev, &power_fops);
> + if (IS_ERR(e->dentry_power))
> + e->dentry_power = NULL;
> +
> bcm43xx_add_dynamic_debug(dev);
> }
>
> @@ -512,6 +591,7 @@ void bcm43xx_debugfs_remove_device(struc
> debugfs_remove(e->dentry_txstat);
> debugfs_remove(e->dentry_restart);
> debugfs_remove(e->dentry_txpower_g);
> + debugfs_remove(e->dentry_power);
> debugfs_remove(e->subdir);
> kfree(e->txstatlog.log);
> kfree(e);
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
> ===
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
> @@ -35,6 +35,7 @@ struct bcm43xx_dfsentry {
> struct dentry *dentry_txstat;
> struct dentry *dentry_txpower_g;
> struct dentry *dentry_restart;
> + struct dentry *dentry_power;
>
> struct bcm43xx_wldev *dev;
>
> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm4
