Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On Thu, Mar 18, 2010 at 08:31:24PM +0100, Michael Buesch wrote: On Thursday 18 March 2010 18:46:35 Larry Finger wrote: It it reasonable to keep the vendor portion of the MAC and only replace the serial number, or would it be better to randomize all 6 octants? I think it doesn't really matter. It might be a good idea to set the LAA bit...? -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 01/11] b43: N-PHY: add some registers and structs definitions
On Wed, Feb 10, 2010 at 12:02:11AM +0100, Michael Buesch wrote: On Tuesday 09 February 2010 21:04:33 Rafał Miłecki wrote: +#define B43_MMIO_PSM_PHY_HDR 0x492 /* programmable state machine */ The comment doesn't make a lot of sense. In case you don't know, the PSM is the part of the hardware that executes the firmware. Rafał, Are you going to repost this series and/or respond to Michael's comments? I tried to apply some of the ones Michael didn't comment upon, but they seem to depend on the ones in question. Thanks, John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: N PHY: Fix compilation after removal of typdef b43_c32
On Tue, Jan 26, 2010 at 04:42:02PM -0600, Larry Finger wrote: In the conversion between typedef and struct, two places that needed a struct were missed. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- John, Without these, compilation fails. Larry Larry, thanks for fixing this! Sorry I missed those bits. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 2/4] b43: make cordic common (LP-PHY and N-PHY need it)
On Mon, Jan 25, 2010 at 07:53:19PM +0100, Michael Buesch wrote:
On Monday 25 January 2010 19:36:27 Rafał Miłecki wrote:
W dniu 25 stycznia 2010 19:35 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
2010/1/25 Michael Buesch m...@bu3sch.de:
On Monday 25 January 2010 18:59:59 Rafał Miłecki wrote:
+/* Complex number using 2 32-bit signed integers */
+typedef struct { s32 i, q; } b43_c32;
No typedef. ever.
Well, I just copied (Gabor's?) code here. But of course I can fix this
by the way, no problem :)
Yeah, I saw that. We can fix it while we're at it. ;)
Just read about typedef in Linux Kernel Coding Style, didn't know
about this earlier. Thanks for pointing.
Is this OK to fix this in separated patch? Or should I modify this set
of patches?
Well, as you touch any reference to the typedef anyway (you renamed it),
you can just put the keyword struct in front of the references and no
separate patch is needed.
It won't even grow your current patch in the number of changed lines.
I took care of these modifications to the original patch...
John
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 0/5] b43: more N-PHY stuff
On Fri, Jan 22, 2010 at 01:53:11AM +0100, Rafał Miłecki wrote: John, I hope to have patch submission fixed, please let me know if there is anything wrong still. This batch applied with no problems -- thanks, Rafał! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 0/5] b43: more N-PHY stuff
On Fri, Jan 22, 2010 at 11:33:40PM +0100, Michael Buesch wrote: So while we are at it, I'd really like to migrate away from the berlios list. It's really just annoying. Does somebody have a good reliable mailinglist service we could migrate to? Does vger offer lists to driver projects? Probably -- I think davem is the person to ask? Infradead is probably another option (dwmw2). John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 5/5 V2] b43: N-PHY: silence warnings, add missing call
On Mon, Jan 18, 2010 at 12:21:49AM +0100, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- New patch I didn't include earlier. Rafał, I just applied this 5-patch series and the preceding 7-patch series, and I had to fixup every single one manually due to the apparently busted mailer you are using. User-Agent: Opera Mail/10.10 (Linux) The only reason I went to this trouble is because a) I want the N-phy stuff and b) you sent small, manageable patches. But don't misunderstand -- I have no intention of continuing to fix these manually. Learn to use git send-email or find some other mailer to send your patches -- I recommend Mutt. In any case, do not expect your patches to get merged unless in the future unless you can rectify this situation at your end. I just don't have the bandwidth for dealing with crap like this. Thanks, John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH][resend with linux-wireless] b43: N-PHY: clean table init, check PHY rev
On Wed, Dec 23, 2009 at 04:10:35PM +0100, Rafał Miłecki wrote: W dniu 23 grudnia 2009 15:52 użytkownik John W. Linville If you decide to agree to commit this patch and you want to me resend this with correct white spaces, please ping me about. For future mails I'll use some native mailer. I'm fine with the patch -- at least it demonstrates that something else is needed for rev 3+. -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH][resend with linux-wireless] b43: N-PHY: clean table init, check PHY rev
On Wed, Dec 23, 2009 at 01:01:58PM +0100, Rafał Miłecki wrote: It's just compilation-tested as I don't own N-PHY device yet (should receive one for Christmas). Of course I enabled N-PHY in Kconfig. I already sent this to bcm43xx-dev but didn't get any review. Michael told me to send it to you John and to linux-wireless. Is there anyone how could review/ack my patch? From 6800722c2fda0e302d7c759a5f2a993503b6581a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= zaj...@gmail.com Date: Tue, 22 Dec 2009 02:27:21 +0100 Subject: [PATCH] b43: N-PHY: clean table init, check PHY rev MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Move table init to tables_nphy.c, detect newer PHY which use different init Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/wireless/b43/phy_n.c | 43 drivers/net/wireless/b43/tables_nphy.c | 48 drivers/net/wireless/b43/tables_nphy.h |4 ++- 3 files changed, 58 insertions(+), 37 deletions(-) Well, the patch is fairly clearly whitespace-damaged. Perhaps that is a product of how you forwarded it to linux-wireless? Other than that, it looks like you are mostly just moving code around. That's fine, but there doesn't seem to be a lot of point in it unless the rev 3+ stuff is coming soon? It probably doesn't harm much either way... John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: Fix regression from Bug #14538
On Mon, Nov 23, 2009 at 01:55:06PM -0600, Larry Finger wrote:
The routine b43_is_hw_radio_enabled() has long been a problem.
For PPC architecture with PHY Revision 3, a read of the register
B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43_status()
returns a value of 2 (B43_STAT_STARTED) (BUG 14181). Fixing that
results in Bug 14538 in which the driver is unable to reassociate
after resuming from hibernation because b43_status() returns 0.
The correct fix would be to determine why the status is 0; however,
I have not yet found why that happens. The correct value is found for
my device, which has PHY revision = 3.
Returning TRUE when the PHY revision 3 and b43_status() returns 0 fixes
the regression for 2.6.32.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Tested-by: Christian Casteyde casteyde.christ...@free.fr
---
Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
+++ wireless-testing/drivers/net/wireless/b43/rfkill.c
@@ -33,9 +33,16 @@ bool b43_is_hw_radio_enabled(struct b43_
B43_MMIO_RADIO_HWENABLED_HI_MASK))
return 1;
} else {
- if (b43_status(dev) = B43_STAT_STARTED
- b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
- B43_MMIO_RADIO_HWENABLED_LO_MASK)
+ /* To prevent CPU fault on PPC, do not read a register
+ * unless the interface is started; however, on resume
+ * for hibernation, this routine is entered early. When
+ * that happens, unconditionally return TRUE.
+ */
+ if (b43_status(dev) = B43_STAT_STARTED) {
+ if (b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
+ B43_MMIO_RADIO_HWENABLED_LO_MASK)
+ return 1;
+ } else
return 1;
}
return 0;
Maybe just me, but I think this version is easier to read (and especially to
see the difference):
diff --git a/drivers/net/wireless/b43/rfkill.c
b/drivers/net/wireless/b43/rfkill.c
index ffdce6f..ddc3c93 100644
--- a/drivers/net/wireless/b43/rfkill.c
+++ b/drivers/net/wireless/b43/rfkill.c
@@ -33,8 +33,14 @@ bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
B43_MMIO_RADIO_HWENABLED_HI_MASK))
return 1;
} else {
- if (b43_status(dev) = B43_STAT_STARTED
- b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
+ /* To prevent CPU fault on PPC, do not read a register
+* unless the interface is started; however, on resume
+* for hibernation, this routine is entered early. When
+* that happens, unconditionally return TRUE.
+*/
+ if (b43_status(dev) B43_STAT_STARTED)
+ return 1;
+ if (b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
B43_MMIO_RADIO_HWENABLED_LO_MASK)
return 1;
}
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Enforce DMA descriptor memory constraints
On Thu, Nov 19, 2009 at 05:55:07PM -0600, Larry Finger wrote: On 11/18/2009 11:21 PM, William Bourque wrote: Also, just saying, but it seems Larry's pm_qos_update_requirement patch had some good effects; I can hardly get any connectivity without it. With the patch, the wireless seems to be stable for a few minutes before generating DMA errors... without the patch the error start piling up as soon the interface get up. If the pm_qos patch has some positive benefits, I'll push it; however, I think this is just a band aid, not a real fix. It also has the bad side effect of keeping the CPU from going into deep sleep, which increases the power usage with reduced battery life. John: Any thoughts on this matter? Missing deep sleep is bad. At the very least you need to limit that to devices that truly need it, as Michael suggested. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix Bugzilla #14181 without introducing a new problem
On Fri, Oct 16, 2009 at 08:42:08AM -0500, Larry Finger wrote: On 10/14/2009 03:06 AM, Michael Buesch wrote: On Wednesday 14 October 2009 03:25:30 Larry Finger wrote: Commit 93bad2b757586fb153ef73b028953a8dcaccde77 entitled b43: Fix PPC crash in rfkill polling on unload fixed the bug reported in Bugzilla No. 14181; however, it introduced a new bug. Whenever the radio switch was turned off, it was necessary to unload and reload the driver for it to recognize the switch again. I believe this patch fixes the original problem without introducing any new problems. Signed-off-by: Larry Finger larry.fin...@lwfinger.net --- As Michael correctly points out, this patch substitutes one bug for another. The current bug affects every bcm43xx device with an rfkill switch except BCM4306/3, and the new bug only affects BCM4306/3 users with a kill switch. As the latter group may be the empty set, I think the trade-off is worth it. An additional complication is that I do not have the hardware to test the PPC faults. The OP of Bugzilla #14181 has been helpful; however, if it takes several tries to get a fix, we might miss the 2.6.32 release, which would introduce a significant regression. For the above reasons, I am suggesting that this patch be accepted and pushed to mainline even though it has faults. Well, hmmm...ok, we have two or three problems here... :-) One is whether or not to take this patch. Normally it is against policy or whatnot to trade one bug for another. In this case, it seems we would fix a real bug in exchange for a theorhetical bug that we believe no one actually has. Is that the case? If so, that might be acceptable. The other problem is a work/patch flow issue. I have occasionally (some would say too often) snagged a patch directly from this list. But in general I have waited for Michael to repost the patches to linux-wireless before merging them. As such, I'm unaccustomed to collecting patches from here. In any event, most patches should be posted to linux-wireless for wider review before merging. That would normally be the maintainer's job, but we are effectively without one for b43 now. I don't suppose anyone wants to stand-up? The third problem (related to the second) is that I missed the original post, so if you don't mind I'd like you to resend it (to linux-wireless)! :-) Thanks, John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: do not stack-allocate pio rx/tx header buffers
On Tue, Oct 06, 2009 at 10:52:15PM +0200, Michael Buesch wrote: On Tuesday 06 October 2009 18:20:43 Albert Herranz wrote: The DMA-API debugging facility complains about b43 mapping memory from stack for SDIO-based cards, as can be seen in the following two stack traces. snip Indeed, b43 currently allocates the PIO RX and TX header buffers from stack. The solution here is to use heap-allocated buffers instead. Signed-off-by: Albert Herranz albert_herr...@yahoo.es snip Just embed it into struct b43_wl (surround it by #ifdef CONFIG_B43_PIO). No need to kzalloc then and it saves some memory. You also need to alloc 4 bytes for the tail buffer (that currently is on the stack, too). Please make the changes Michael requested and resubmit -- I'll happily make the adjustments to wireless-testing, etc. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v2] b43: LP-PHY: Begin implementing calibration software RFKILL support
On Sun, Aug 30, 2009 at 05:55:40PM +0200, Michael Buesch wrote:
On Sunday 30 August 2009 17:10:23 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 30 August 2009 02:15:55 Gábor Stefanik wrote:
static void lpphy_pr41573_workaround(struct b43_wldev *dev)
{
struct b43_phy_lp *lpphy = dev-phy.lp;
@@ -1357,28 +1488,440 @@ static void lpphy_pr41573_workaround(struct
b43_wldev *dev)
b43_lptab_read_bulk(dev, B43_LPTAB32(7, 0x140),
saved_tab_size, saved_tab);
}
+b43_put_phy_into_reset(dev);
Are you sure you really want this?
This function completely disables the PHY on the backplane and keeps the
physical
PHY reset pin asserted (even after return from the function).
So the PHY will physically be powered down from this point on. The
following
PHY accesses could even hang the machine, because the PHY won't respond to
register accesses anymore.
We currently only use this function on A/G Multi-PHY devices to
permanently
hard-disable the PHY that's not used.
The PHY reset routine in
http://bcm-v4.sipsolutions.net/802.11/PHY/Reset, which I just updated
for the latest N PHY changes, appears to be a different routine than
b43_put_phy_into_reset(). The names are confusing.
b43_put_phy_into_reset() is opencoded in the specifications in various init
routines. There's no separate specs page for that function.
But I think the code is straightforward and easy to understand.
So is this patch right or not? Should I hold onto it for 2.6.33
(i.e. after the 2.6.32 merge window)?
John
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix and update LP-PHY code
On Wed, Aug 26, 2009 at 10:47:12PM +0200, Gábor Stefanik wrote: 2009/8/26 Michael Buesch m...@bu3sch.de: And, everything in its own patch, please. I don't see a reason for patching unrelated things in one big patch. Well, this patch is already in wireless-testing, so doing that would now involve reverting this patch, applying a version without the channel change, and applying the channel change - certainly more confusing than the status quo. But it is not in net-next-2.6. Please submit the patches as Michael requested and I'll take care of the reorganization. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCHv4] b43 add harware tkip
On Fri, Aug 21, 2009 at 11:43:55PM +0200, gregor kowski wrote: This add hardware tkip for b43. This can help to reduce the load a low powered router and make higher throughput. To enable it, you need to set hwtkip module param. Signed-off-by: Gregor Kowski gregor.kow...@gmail.com Acked-by: Michael Buesch m...@bu3sch.de An earlier version was already merged. What is different here? Please submit a new patch with just the differences. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: LP-PHY: Implement spec updates and remove resolved FIXMEs
On Thu, Aug 20, 2009 at 12:14:13AM +0200, Gábor Stefanik wrote: Seeing that this is still not in wireless-testing - this patch should be applied, the previously mentioned regressions were false alerts (Larry tested without this patch and with v478 firmware, which worked; while Mark applied this patch and used v410 firmware, which didn't work - when Mark upgraded to v478 firmware, his card too came to life.) So, please apply. You posted the above slightly more than 7 hours after the false alert message below. Date: Wed, 19 Aug 2009 16:57:37 +0200 From: Gábor Stefanik netrolller...@gmail.com To: John Linville linvi...@tuxdriver.com, Michael Buesch m...@bu3sch.de, Larry Finger larry.fin...@lwfinger.net Cc: Mark Huijgen m...@huijgen.tk, Broadcom Wireless bcm43xx-dev@lists.berlios.de, linux-wireless linux-wirel...@vger.kernel.org Subject: Re: [PATCH] b43: LP-PHY: Implement spec updates and remove resolved FIXMEs False alert, sorry. Feel free to apply. The regression apparently resulted from the use of an incorrect firmware image - when Mark switched to the same firmware as Larry, his card started working again. It seems that you think I am a little gnome that sustains itself on email and git, but I assure you that I am not. I have other things to do. I am truly glad that you have taken-up the cause of LP-PHY support for b43. Nevertheless, being heckled by you does nothing to make me want to merge your patches any faster. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RESEND] [PATCH] b43 : remove old kidx API
On Mon, Jul 27, 2009 at 10:43:36PM +0200, gregor kowski wrote: Remove old kidx API. This simplify the code, and fix a potential key overflow. Signed-off-by: Gregor Kowski gregor.kow...@gmail.com Is this patch still relevant? If so, could you repost a version that isn't whitespace damaged and that actually applies? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix hardware key index handling
On Thu, Aug 06, 2009 at 10:36:50AM +0200, Michael Buesch wrote: This fixes the hardware encryption keys index and array size handling. Thanks to Gregor Kowski for reporting this issue. Signed-off-by: Michael Buesch m...@bu3sch.de --- This should probably go as a bugfix. (Does this actually fix the PHY transmission errors? I don't see them anymore... Note that you need to enable debugging to see them.) It's getting a bit late in the cycle, especially for a patch so large and (at least to me) non-obvious. What is the actual bug being fixed? What is the effect of leaving it for 2.6.32? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] remove wrong probe_resp_plcp write
On Fri, Jul 31, 2009 at 10:38:14PM +0200, Michael Buesch wrote: On Friday 31 July 2009 22:35:49 gregor kowski wrote: The tkip hw support uncovered a bug in b43_write_probe_resp_template : it is writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK zone. This patch comments these writes. Signed-off-by: Gregor Kowski gregor.kow...@gmail.com Signed-off-by: Michael Buesch m...@bu3sch.de CC [M] drivers/net/wireless/b43/main.o drivers/net/wireless/b43/main.c:1432: warning: ‘b43_write_probe_resp_plcp’ defined but not used Comment it out too? Or are you going to fix the block that has been commented-out here? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ¡Viva Honduras Libre! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Off Subject Question
On Mon, Jul 13, 2009 at 12:48:29PM -0700, Luis R. Rodriguez wrote: On Mon, Jul 13, 2009 at 12:41 PM, Michael Bueschm...@bu3sch.de wrote: On Monday 13 July 2009 21:37:39 Clyde McPherson wrote: Does anyone know when or if the Wireless Summit will be in Portland? There currently is no plan to do a summit in Portland. The last summit recently was on the Linux Tag in Berlin. Actually there is one but its currently invite-only. Indeed...space is tight, but please feel free to nominate oneself or someone else if you are interested. It is in Portland on the weekend before LinuxCon. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ¡Viva Honduras Libre! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Wed, Jan 14, 2009 at 04:30:47PM +0100, Lorenzo Nava wrote: Hello everybody, we completed the 1st version of initvals. They are available at http://www.ing.unibs.it/openfwwf . Currently only binary version is available: don't worry, we will publish source code as soon as possible!! This first version is a test version: please try it and let us know if everythink is ok... Today we have also tested a new firmware version that works with WPA2- personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested on 4306 and 4318 PCI device). If anybody was interested please try new firmware with encryption and let us know if it works correctly, thanks! Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf Awesome...awesome...awesome!!! -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Wed, Jan 14, 2009 at 09:45:22PM +0100, Johannes Berg wrote: Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf I suggest that before this is packaged, we change it so b43 can recognise it and automatically disable qos and hwcrypto. That's a good idea. Is that simply a driver patch? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote: Hello everybody, today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with Broadcom 4306 chipset: BCM94306 802.11g (rev 03) PHY: Analog 2, Type 2, Revision 2 Radio: Manuf 0x17F, Version 0x2050, Revision 2 I did some tests and everything seems to work fine. I remember, once again, that OpenFWWF needs v480 initvals to work properly, and was tested on 2.6.27-rc5 kernel. Any chance on getting a set of initvals packaged with the open source firmware? That would allow distros like Fedora to package this... John -- John W. LinvilleLinux should be at the core linvi...@tuxdriver.com of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware
On Fri, Jan 09, 2009 at 09:21:52AM +0100, Francesco Gringoli wrote: we have been involved in the past few months in testing modifications to the standard 802.11 MAC for research purposes. During this time we did some tests with Broadcom 802.11b/g boards and we wrote down a simple 802.11 compliant firmware that we used as a starting point for the modified MAC algorithms. snip The firmware along with the instructions to build it from the assembly code using the tools developed by the b43 community can be found here http://www.ing.unibs.it/openfwwf In the firmware website you can find more information about the fw algorithm, its interaction with Broadcom hardware and other information that we discovered as we were writing it. I hereby declare this to be Fully Awesome! (TM) John -- John W. LinvilleLinux should be at the core linvi...@tuxdriver.com of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Thu, Dec 11, 2008 at 10:28:19PM -0600, Larry Finger wrote: Matthew Garrett wrote: I've reworked the rfkill code in b43. This ought to be more consistent with the other drivers and it seems to work on the machines I've tested it on here, but it'd be good to get some feedback. snip How does this look to people? All this discussion about hard vs soft rfkill makes my head hurt and I have stopped reading those posts. Correction to my earlier post. If the system is booted with the RF switch off, the LED is on, whereas it should be off. The original code works correctly. Based on the above, I'm dropping this patch. Please submit a non-regressing version! :-) John -- John W. LinvilleLinux should be at the core linvi...@tuxdriver.com of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 STILL randomly and silently dropping connections...
I've seen this message a couple of times -- I'm a bit surprised that you haven't been getting a response. I am Cc'ing Michael and the bcm43xx mailing list just in case they haven't noticed this message. John On Wed, Oct 22, 2008 at 06:48:55AM -0400, Jerry McBride wrote: The story is... I've moved from 2.6.25.x using BCM43XX with a Broadcom 4306 (rev3) 802.11 chipset to 2.6.26.6 using the B43 and appropriate firmware. This on a COMPAQ Presario R3000 P4 and a gig of memory and ATI graphics. I followed the install (upgrade) directions at linuxwireless.org. Piece of cake! However... I find that I've gone from bulletproof BCM43XX wifi connections to bullethole connections with B43. Under the old BCM43XX the handshake and connections were flawless and unfaltering. Now with the new B43, handshakes with AP's are perfect, but the connections randomly and silently fail. There are no debug messages, no complaints what-so-ever in /var/log/messages... To gt wireless back, I have to reinitialize the connection. I've gotten so good at it, that I can recite by heart the appropriate commands... It's killling me! I've got to get this ironed out... it's not just my laptop, it's happening quite regularly with people I know with similar chips and laptops. Trying 2.6.27-rc's and now 2.6.27 and the situation is no better. So I ask... Who is the B43/B43LEGACY maintainer and would you be interested in debugging this mess? I'll bend over backward to help you... Email me direct... I'm very willing. SHORT STORY: -- Kernel 2.6.25.x with BCM43XX, firmware 4.80.53.0.. just perfect. -- Kernels 2.6.26 or higher with B43 and firware 4.150.10.5 good negotiations, but fragile connections that drop randomly and without complaint. B43LEGACY does nothing. Any help would be appreciated. I'd really like to get this ironed out. I highly desire to use current kernels. Feel free to email me direct. -- * From the desk of: Jerome D. McBride 19:17:28 up 15 days, 23:35, 5 users, load average: 0.33, 0.11, 0.03 * -- 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 -- John W. LinvilleLinux should be at the core [EMAIL PROTECTED] of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Can't connect to AP with hidden essid with 2.6.27-rc6
On Thu, Sep 18, 2008 at 07:26:57AM -0500, Larry Finger wrote: $ bin/iw dev wmaster0 info Band 1: Frequencies: * 2412 MHz (passive scanning, no IBSS) * 2417 MHz (passive scanning, no IBSS) * 2422 MHz (passive scanning, no IBSS) * 2427 MHz (passive scanning, no IBSS) * 2432 MHz (passive scanning, no IBSS) * 2437 MHz (passive scanning, no IBSS) * 2442 MHz (passive scanning, no IBSS) * 2447 MHz (passive scanning, no IBSS) * 2452 MHz (passive scanning, no IBSS) * 2457 MHz (passive scanning, no IBSS) * 2462 MHz (passive scanning, no IBSS) It is the passive scanning that is killing you. For hidden essid, you need an active scan. You need to implement the CRDA (http://linuxwireless.org/en/developers/Regulatory/CRDA), which will get your system to provide active scanning. Hmmm...does the user have CONFIG_WIRELESS_OLD_REGULATORY=y? That is supposed to enable identical behavior to what we had before w/o requiring CRDA. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f
On Tue, Sep 16, 2008 at 09:52:12PM -0500, Larry Finger wrote: I admit that I never tested any of the RFKILL patches as they went in. One of the reasons is that the development process seemed rather untidy to an outsider, and I wasn't sure that any of the code would ever be in the kernel. As such, it snuck up on me. I'll not let that happen again. After the reversion, I will again test any suggested code changes, but do not expect me to work out any of the changes. I have enough to do. FWIW, Henrique has been very persistant with driving rfkill. He has posted and reposted his patch series many times. I'm sorry that it snuck-up on you but it was on the list for quite a while. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
On Wed, Sep 10, 2008 at 12:40:44AM -0600, Otto Solares wrote: On Mon, Sep 08, 2008 at 04:54:59PM -0400, John W. Linville wrote: On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote: Greg KH wrote: Bug fixes, not new features, it's pretty simple :) Just bug fixes, or does it have to be a regression? As I understand it, the rule is more like bug fixes that are committed in the linux-2.6 tree. Since Linus has become more strict about requiring regressions only after the merge window, that effectively enforces the regressions only rule on the -stable trees as well. In this case that rule is harming, is not idiotic to not accept bug fixes early or later? I'm just the messenger...FWIW the argument is that even a fix can introduce a new bug somewhere else, often quite unexpectedly. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote: Greg KH wrote: Bug fixes, not new features, it's pretty simple :) Just bug fixes, or does it have to be a regression? As I understand it, the rule is more like bug fixes that are committed in the linux-2.6 tree. Since Linus has become more strict about requiring regressions only after the merge window, that effectively enforces the regressions only rule on the -stable trees as well. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, Sep 06, 2008 at 08:41:05PM +0200, Michael Buesch wrote: On Saturday 06 September 2008 20:34:02 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Does version3 firmware have a different bitlayout for the status? Although this is not strictly a regression, it is a bug. I hope it can be sent to 2.6.27. The new rules don't allow us to fix bugs after the merge window. Only regressions. I imagine the powers that be would claim it isn't a new rule, but it is a new enforcement policy... John ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH stable] b43: Fix noise calculation WARN_ON
On Sat, Jun 14, 2008 at 11:00:14PM +0200, Michael Buesch wrote: This removes a WARN_ON that is responsible for the following koops: http://www.kerneloops.org/searchweek.php?search=b43_generate_noise_sample The comment in the patch describes why it's safe to simply remove the check. This patch is upstream in John Linville's wireless-testing.git tree as commit 86ef1ae07289c9f0aa1aa310d43653e513e6f124 ...and will probably be 98a3b2fe435ae76170936c14f5c9e6a87548e3ef in linux-2.6.git. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH stable] b43: Fix possible NULL pointer dereference in DMA code
On Sat, Jun 14, 2008 at 10:57:55PM +0200, Michael Buesch wrote: This fixes a possible NULL pointer dereference in an error path of the DMA allocation error checking code. In case the DMA allocation address is invalid, the dev pointer is dereferenced for unmapping of the buffer. This is a cut-down version of 3ab4b64c46784ed83f213bf4e1b51d9c55858600 which is upstream in John Linville's wireless-testing.git tree. ...which will probably be 028118a5f09a9c807e6b43e2231efdff9f224c74 in linux-2.6.git John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [stable] [PATCH stable] b43: Fix controller restart crash
On Fri, Jun 06, 2008 at 07:55:27PM +0200, Michael Buesch wrote: On Friday 06 June 2008 19:32:23 Chris Wright wrote: * Michael Buesch ([EMAIL PROTECTED]) wrote: This fixes a kernel crash on rmmod, in the case where the controller was restarted before doing the rmmod. Upstream commit is 4735f5022c97f6624ced2ec5056c61c4b437d53b This is not in Linus' tree. Where is this upstream commit? John Linville's wireless tree. That's upstream from my point of view. :P :-) The commit ID may have gotten shuffled when Dave M. rebased net-2.6. It is in 2.6.26-rc5 as commit 3bf0a32e22fedc0b46443699db2d61ac2a883ac4. Hth! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix controller restart crash
On Thu, May 22, 2008 at 05:06:36PM +0200, Michael Buesch wrote: This fixes a kernel crash on rmmod, in the case where the controller was restarted before doing the rmmod. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- Stefano, this is untested. Please test by doing echo -n 1 /debug/b43legacy/phy*/restart rmmod b43legacy It should not crash anymore at the rmmod (actually the restart should also hang in b43legacy, as it has a deadlock, which this patch also fixes). Anyone get a chance to test this one? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix typo in firmware file name for 802.11 cores with rev 13
On Thu, May 15, 2008 at 02:07:36PM -0500, [EMAIL PROTECTED] wrote: When the patch for the BCM4311 rev 2 was prepared, I misread the specs and coded the wrong file name for the initvals firmware. Signed-off-by: Larry Finger [EMAIL PROTECTED] --- John, This is 2.6.27 material. Although it is a bug in 2.6.25 and .26, it seems to have zero effect on the performance of the device and can be delayed. Would you prefer to have it in 2.6.26 just in case? Or might that cause a problem somehow? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [patch 11/16] b43: Fix some TX/RX locking issues
On Thu, May 08, 2008 at 10:42:21AM -0700, Greg KH wrote: 2.6.25-stable review patch. If anyone has any objections, please let us know. -- From: Michael Buesch [EMAIL PROTECTED] commit 21a75d7788f4e29b6c6d28e08f9f0310c4de828d upstream. This fixes some TX/RX related locking issues. With this patch applied, some of the PHY transmission errors are fixed. ACK -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix some TX/RX locking issues
On Thu, May 01, 2008 at 12:08:10PM +0200, Michael Buesch wrote: John, did you drop this patch? I can't see it in git and your latest push, while a patch submitted later is in there. No, I'm sorry. I fat-fingered my patches. I've still got it, and it will go in the next round. John On Friday 25 April 2008, Michael Buesch wrote: This fixes some TX/RX related locking issues. With this patch applied, some of the PHY transmission errors are fixed. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- John, this is for 2.6.26. -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb-pcmcia: IRQ and DMA related fixes
On Fri, Mar 28, 2008 at 10:34:55AM +0100, Michael Buesch wrote: Here come some IRQ and DMA related fixes for the ssb PCMCIA-host code. Not much to say, actually. I think the patch explains itself. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- For 2.6.25 This seems to build upon these two patches: commit e7ec2e3230633a858af1b0b359f6c4670dbeb997 Author: Michael Buesch [EMAIL PROTECTED] Date: Mon Mar 10 17:26:32 2008 +0100 ssb: Add SPROM/invariants support for PCMCIA devices This adds support for reading/writing the SPROM invariants for PCMCIA based devices. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Signed-off-by: John W. Linville [EMAIL PROTECTED] commit ffc7689ddae5cbe12bde437ae0f2b386d568b5cd Author: Michael Buesch [EMAIL PROTECTED] Date: Wed Feb 20 19:08:10 2008 +0100 ssb: Add support for 8bit register access This adds support for 8bit wide register reads/writes. This is needed in order to support the gigabit ethernet core. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Signed-off-by: John W. Linville [EMAIL PROTECTED] Those are not in 2.6.25. Is 2.6.26 OK for this one? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4311 + 2.6.24 + patch gives blinking wireless LED
On Fri, Mar 14, 2008 at 05:26:57PM +0530, Abhijit Hoskeri wrote: [EMAIL PROTECTED]:~/src/wireless-testing$ git checkout --track -b everything origin/everything git checkout: updating paths is incompatible with switching branches/forcing Did you intend to checkout 'origin/everything' which can not be resolved as commit? This was the old practice from before the latest tree organization (mid-February). I am sorry, I do not know enough about git yet to guess what the correct incantation should be. Anyway I just did a git-pull and got 2.6.25-rc5-wl. I have built it but not had opportunity to test it yet. Is this new enough to work? This is exactly what you want. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4311 + 2.6.24 + patch gives blinking wireless LED
On Fri, Mar 14, 2008 at 07:49:02AM -0700, Larry Finger wrote: John W. Linville wrote: On Fri, Mar 14, 2008 at 05:26:57PM +0530, Abhijit Hoskeri wrote: [EMAIL PROTECTED]:~/src/wireless-testing$ git checkout --track -b everything origin/everything git checkout: updating paths is incompatible with switching branches/forcing Did you intend to checkout 'origin/everything' which can not be resolved as commit? This was the old practice from before the latest tree organization (mid-February). What is current practice? While I have been on the road, I unsubscribed from wireless and probably missed any appropriate messages. Does the master branch of wireless-2.6.git now have what used to be in everything? No, but the master branch of wireless-testing.git does. Please use that for general development. Check the News page here: http://www.linuxwireless.org/ Hth! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: iwlist shows one AP few times
Extra:tsf=00c4357e0181 Cell 03 - Address: 00:18:39:DD:EE:78 ESSID: Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=65/100 Signal level=-50 dBm Noise level=-72 dBm Encryption key:on IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK Preauthentication Supported Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=001447c32e34 Cell 04 - Address: 00:18:39:DD:EE:78 ESSID: Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=65/100 Signal level=-50 dBm Noise level=-72 dBm Encryption key:on IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : CCMP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK Preauthentication Supported Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=001447c239ef -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Remove PIO support
On Wed, Jan 09, 2008 at 06:58:12PM +0100, Johannes Berg wrote: John, On Wed, 2007-12-26 at 14:41 +0100, Michael Buesch wrote: Remove b43 PIO support. DMA works well on all supported devices. There's no reason to use PIO. Additionally, new devices don't support PIO in hardware anymore. b43 PIO support is dead and unused code. You merged this patch, but After applying this patch please do git rm drivers/net/wireless/b43/pio.h git rm drivers/net/wireless/b43/pio.c to remove the main PIO support code. forgot this. You're right -- thanks for the reminder! -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sun, Jan 06, 2008 at 06:02:38PM +0100, Michael Buesch wrote: This is needed in order to add support for new devices (N-PHY). Broadcom changed the ABI of the firmware, so we are forced to also change the ABI of the driver. Do we have reasonable confidence that the newer firmware will run on all the devices currently supported by b43? Or are we looking at another b43legacy type of situation? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sun, Jan 06, 2008 at 09:58:22PM +0100, Michael Buesch wrote: On Sunday 06 January 2008 21:05:23 Hendrik Sattler wrote: Do these firmware files go to a different directory then? I would like to run my current kernel (b43 from git or 2.6.24) and the new one without having to exchange files every time I boot another kernel version. And yes, WLAN is my _only_ connection to the internet. see fwpostfix module parameter Ugh...that works but is a bit ugly. Is there any way we can version these firmware ABIs? I guess it might be as simple as simply setting a default fwpostfix value... John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote: On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? Go and complain at Broadcom please. Broadcom doesn't really have this problem, since they are free to include the binary firmware in their Windows/Mac/whatever drivers. If the driver needs different firmware, why not have it ask for different filenames? As I suggested elsewhere, this could be as simple as setting a default value for fwpostfix... John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Mon, Jan 07, 2008 at 12:02:11AM +0100, Michael Buesch wrote: The _just_ wanted to tell people about a serious change _before_ it happens. I'm not sure why this results in all kinds of complaints. Don't be so inhuman... :-) (For those just joining us, that is an inside joke...) Please don't confuse suggestions (intended to be helpful) with complaints. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Lost wireless device?
On Mon, Dec 17, 2007 at 10:39:45PM -0600, John Pierce wrote: Larry, I know I am waking up an old thread, but I have a development I thought was interesting and I need some guidance. This device: 03:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01) quit showing up in fedora 7 and never appeared in fedora 8, however, I just installed opensuse 10.3 on the second drive and it has reappeared. I did the standard update after the initial install and it disappeared again. If the device does not show-up for lspci then it is probably not a driver issue. I would suspect a changed BIOS setting but you didn't mention the BIOS in between your various kernels so that seems unlikely. The only thing that leaves that I can conjur at the moment is an ACPI problem -- probably bad ACPI code in your BIOS but possibly a bug in the Linux ACPI interpreter. If you boot with acpi=off on the kernel command line, does the device either always show-up or never show-up between the various kernels? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: Either distributions have to install it automatically or people simply have to read one or two lines of documentation. That's just what I wanted to say. It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. Given a functioning udev configuration, the persistent naming even works so that your device stays as 'eth1' when switching to and fro bcm43xx. I really think everyone is overstating the problem. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote: * Michael Buesch [EMAIL PROTECTED] wrote: Oh come on. b43 is more than a year old now. How long should we wait? Two or three? Forever? possibly forever, if you dont get obvious regressions like my wlan does not work (reported in this very thread), resolved. Pushing the blame to udev (in a rather unfriendly way) wont give users a working system and wont get you many new testers for the new driver either. It is true that Michael can be a little unpleasant at times. The colloquialism that comes to mind is that he does not suffer fools lightly. Hopefully he will take your counseling to heart and learn to be a bit more moderate in his tone. FWIW, he is still young. :-) That said, it is also true that the b43[legacy] driver[s] do a more than adequate job of replacing the old bcm43xx driver provided that one (re-)installs the proper firmware. And I know of no other driver that goes to more trouble to tell you how to get the proper firmware installed than this one. The bcm43xx driver will be added to the feature removal schedule in 2.6.25. Proper judgment will be used in deciding the actual date of its removal. In the meantime hopefully every distribution will have or obtain a working udev configuration. If things don't work out as planned then we will re-evaluate. Let's stop this now please. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: My Laptop
On Wed, Dec 12, 2007 at 11:12:58PM -0500, Matthew Saltzman wrote: On Wed, 2007-12-12 at 17:00 -0500, Stuart D. Gathman wrote: On Wed, 12 Dec 2007, Larry Finger wrote: Stuart D. Gathman wrote: , but I got kernel exceptions, DMA exception, and eventually the system froze. I would say it is not ready for prime time. (I will be looking for where to helpfully report the exceptions for those trying to debug the thing. I suspect donations of relevant hardware are most useful.) No problems with the zd1211 driver and USB key. I'm sorry that you had troubles with the BCM94311MCG in your laptop, but I think most of your problems are fixed in driver b43 in any of the 2.6.24-rcX kernels. In any case, the place to report such problems is [EMAIL PROTECTED] FC8 has 2.6.23. I suppose FC9 might do the trick. Or maybe they'll backport some fixes. Fedora generally releases kernel updates fairly quickly to track upstream (though they have patches to port forward before they are ready). There's no 2.6.24 in updates-testing yet, however. kernel-2.6.23.9-85 is there. Are you looking for wireless patches? At this moment there are no wireless bits in wireless-2.6 that are not in the latest Fedora kernels in Koji. The last one I built is here: http://koji.fedoraproject.org/koji/buildinfo?buildID=27585 Hth! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
On Thu, Nov 22, 2007 at 02:05:52PM +0100, Johannes Berg wrote: Note that the same happens if I let Debian manage the card. An excerpt from my /etc/network/interfaces shows: That sucks, I guess debian's scripts need to be fixed. As it stands, setting the SSID is the closest thing we have to an associate now trigger. I would have to advise distros and users to always set it last in the wireless init, just before running dhclient or whatever. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
schedule bcm43xx removal for 2.6.26 -- Re: [PATCH v3] remove bcm43xx
On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote: On Tuesday, 20 of November 2007, Michael Buesch wrote: It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to replace bcm43xx. And we already do a parrallel release cycle with both drivers included so people can switch. What else do you want? _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more. Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be dropped anyway after some time - when no one uses it any more. Still, it need not be (and IMHO it shouldn't be) your decision to drop it. It is probably true that we haven't communicated this very well outside the wireless team. We probably should have added bcm43xx to the feature removal schedule before the 2.6.24 merge window closed. How about if we mark bcm43xx as Obsolete in MAINTAINERS and add an entry to Documentation/feature-removal-schedule.txt with a When of 2.6.26? I think that should give everyone sufficient notice...? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] bcm43xx: mark as obsolete and schedule for removal
Signed-off-by: John W. Linville [EMAIL PROTECTED] --- Documentation/feature-removal-schedule.txt |9 + MAINTAINERS|2 +- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 20c4c8b..c057e36 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -333,3 +333,12 @@ Why: This driver has been marked obsolete for many years. Who: Stephen Hemminger [EMAIL PROTECTED] --- + +What: bcm43xx wireless network driver +When: 2.6.26 +Files: drivers/net/wireless/bcm43xx +Why: This driver's functionality has been replaced by the + mac80211-based b43 and b43legacy drivers. +Who: John W. Linville [EMAIL PROTECTED] + +--- diff --git a/MAINTAINERS b/MAINTAINERS index 18b7c8e..2bfc23f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -828,7 +828,7 @@ P: Stefano Brivio M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://bcm43xx.berlios.de/ -S: Maintained +S: Obsolete BEFS FILE SYSTEM P: Sergey S. Kostyliov -- 1.5.3.3 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH v2] bcm43xx: mark as obsolete and schedule for removal
Signed-off-by: John W. Linville [EMAIL PROTECTED] --- Amended based on suggestions from Stefano... Documentation/feature-removal-schedule.txt |9 + MAINTAINERS|2 +- drivers/net/wireless/bcm43xx/Kconfig |9 ++--- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 20c4c8b..c057e36 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -333,3 +333,12 @@ Why: This driver has been marked obsolete for many years. Who: Stephen Hemminger [EMAIL PROTECTED] --- + +What: bcm43xx wireless network driver +When: 2.6.26 +Files: drivers/net/wireless/bcm43xx +Why: This driver's functionality has been replaced by the + mac80211-based b43 and b43legacy drivers. +Who: John W. Linville [EMAIL PROTECTED] + +--- diff --git a/MAINTAINERS b/MAINTAINERS index 18b7c8e..2bfc23f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -828,7 +828,7 @@ P: Stefano Brivio M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://bcm43xx.berlios.de/ -S: Maintained +S: Obsolete BEFS FILE SYSTEM P: Sergey S. Kostyliov diff --git a/drivers/net/wireless/bcm43xx/Kconfig b/drivers/net/wireless/bcm43xx/Kconfig index ce397e4..0159701 100644 --- a/drivers/net/wireless/bcm43xx/Kconfig +++ b/drivers/net/wireless/bcm43xx/Kconfig @@ -1,12 +1,15 @@ config BCM43XX - tristate Broadcom BCM43xx wireless support + tristate Broadcom BCM43xx wireless support (DEPRECATED) depends on PCI IEEE80211 IEEE80211_SOFTMAC WLAN_80211 EXPERIMENTAL select WIRELESS_EXT select FW_LOADER select HW_RANDOM ---help--- - This is an experimental driver for the Broadcom 43xx wireless chip, - found in the Apple Airport Extreme and various other devices. + This is an experimental driver for the Broadcom 43xx wireless + chip, found in the Apple Airport Extreme and various other + devices. This driver is deprecated and will be removed + from the kernel in the near future. It has been replaced + by the b43 and b43legacy drivers. config BCM43XX_DEBUG bool Broadcom BCM43xx debugging (RECOMMENDED) -- 1.5.3.3 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix compilation errors in ssb
On Fri, Nov 16, 2007 at 08:21:43AM -0600, Larry Finger wrote: Michael Buesch wrote: On Friday 16 November 2007 07:48:23 Larry Finger wrote: Recent changes in ssb sprom handling break compilation. These two patches fix the problem. are your sprom r4 changes already applied? I didn't test that in the b44, yet. I did a git pull yesterday and the sprom r3 and r4 changes were in wireless-2.6/everything. And now, so is this one. I'll probably roll it into the main ssb sprom patch before actually sending it to Jeff. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: silence a bogus gcc warning
On Sat, Nov 10, 2007 at 04:14:03PM +0100, Michael Buesch wrote: From: Frank Lichtenheld [EMAIL PROTECTED] inititalise ret to 0 to avoid the following bogus warning: CC [M] drivers/net/wireless/b43/debugfs.o drivers/net/wireless/b43/debugfs.c: In function ‘b43_debugfs_read’: drivers/net/wireless/b43/debugfs.c:355: warning: ‘ret’ may be used uninitialized in this function Signed-off-by: Frank Lichtenheld [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Isn't this what uninitialized_var() is for? -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Help with wireless on Fedora 8
On Fri, Nov 09, 2007 at 04:39:56PM -0600, Larry Finger wrote: I need some Fedora help. This new b43 user is having problems making a connection. He has a b-only AP of unspecified make with no encryption. He is using F8 with the default kernel (I think). He has done the following: Ruggiero wrote: i used system-adminstrationNetwork and i configurated everything from there...and the clicking on activate wlan0 for a while my access point communicate and in the log i see that it's connected... here are outputs: if i use NetworkManager i see it's connecting...but after a while i get the message disconnected Tail of dmesg: wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:0c:41:19:2d:c1 wlan0: authenticate with AP 00:0c:41:19:2d:c1 wlan0: authenticate with AP 00:0c:41:19:2d:c1 wlan0: authentication with AP 00:0c:41:19:2d:c1 timed out wlan0: authentication frame received from 00:0c:41:19:2d:c1, but not in authenticate state - ignored wlan0: RX disassociation from 00:0c:41:19:2d:c1 (reason=4) All the b43 messages are normal. He sees the AP with a scan, but never authenticates. Any suggestions? FWIW, the F8 install kernel has wireless bits that are a month or so old. You may want to have him try these kernels: http://koji.fedoraproject.org/koji/buildinfo?buildID=23734 Those at least have wireless bits that are up-to-date w/ wireless-2.6. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43, b43legacy questions
On Wed, Nov 07, 2007 at 05:29:12PM -0700, Ehud Gavron wrote: dmesg | grep b43 The version with F7 wants the v4 microcode files with the *old* names (bcm43xx_*) instead of the new ones. Just to clarify, all this means is that for F7 you should continue to use bcm43xx-fwcutter instead of b43-fwcutter. Gene, FWIW if b43 is getting loaded then that is almost certainly the right driver. The one in F7 is a bit behind, so if it isn't working you might want to try an F8 kernel. I think you should be able to run an F8 kernel on F7 w/o any trouble. Hopefully that will drive your 4318 -- it works for both of mine. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH #3] b43: Fix sparse warnings.
On Fri, Oct 19, 2007 at 03:47:13PM +0200, Michael Buesch wrote: On Thursday 18 October 2007 21:53:22 John W. Linville wrote: On Wed, Oct 17, 2007 at 06:34:03PM +0200, Michael Buesch wrote: The remaining warning in phy.c will be fixed later. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- John, this is the third time I submit this. Is something wrong with this patch or did you simply forget to apply it? Where are you looking? It is in Linus' tree. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a09404a2338163f181d170c7abdc2242b6c6f03 John Uhm, it still applies to wireless-2.6#everything. I imagine that it won't when that gets rebased, probably after 2.6.24-rc1. :-) Seriously, either I must have neglected to add it to everything and merged-upstream. I'll look into it. The important thing is that Linus has it. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24 patches for b43legacy
On Fri, Oct 19, 2007 at 12:41:21PM -0500, Larry Finger wrote: Are the following patches queued for Linus's tree? [PATCH V2] b43legacy: LED triggers support - sent 10/12/07 [PATCH] b43legacy: RF-kill support - sent 10/10/07 [PATCH] b43legacy: Use input-polldev for the rfkill switch - sent 10/10/07 [PATCH] b43legacy: Rewrite pwork locking - sent 10/10/07 [PATCH] b43legacy: Fix potential return of uninitialized variable - sent 10/14/07 [PATCH] b43legacy: Fix namespace pollution and sparse warnings - sent 10/17/07 I have them all, but they did not make the cut-off for 2.6.24. I sent the next-to-last one to Jeff last night as a fix. The rest will be sent to Jeff after 2.6.24-rc1 is released, in anticipation of inclusion into 2.6.25. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix regression in 2.6.23-git3 due to change in calling add_uevent_var
On Sat, Oct 13, 2007 at 11:46:47PM -0500, Larry Finger wrote: In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence for add_uevent_var was changed, but the ssb driver was not modified, which leads to a Unable to handle kernel paging request oops. This patch fixes the problem. Sorry, Al Viro got a patch merged before I got to yours! Thanks anyway! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311: trouble with Fedora 8 Test 3
On Wed, Oct 10, 2007 at 12:08:08PM -0400, sean darcy wrote: Nothing at all about the 4311 card in dmesg. Made sure NetworkManager was working. Restarted it. I can see the icon. No connection. If I connect the wire it starts up the wired connection. Please post the output of this command: cat /sys/bus/ssb/devices/ssb0\:0/uevent I suspect that your device's core is too new to be supported. dmesg does show this error: ssb: rev 6000 WARNING: at drivers/ssb/main.c:889 ssb_tmslow_reject_bitmask() (Not tainted) Technically a warning, not an error. :-) John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Leds spinlock SMP compilefix
I'll just roll this into the b43: LED triggers support patch. Thanks, John On Sun, Sep 30, 2007 at 12:04:36AM +0200, Michael Buesch wrote: This was missing an address operator. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-2.6/drivers/net/wireless/b43/leds.c === --- wireless-2.6.orig/drivers/net/wireless/b43/leds.c 2007-09-29 12:44:08.0 +0200 +++ wireless-2.6/drivers/net/wireless/b43/leds.c 2007-09-30 00:02:18.0 +0200 @@ -37,14 +37,14 @@ static void b43_led_turn_on(struct b43_w unsigned long flags; u16 ctl; - spin_lock_irqsave(wl-leds_lock, flags); + spin_lock_irqsave(wl-leds_lock, flags); ctl = b43_read16(dev, B43_MMIO_GPIO_CONTROL); if (activelow) ctl = ~(1 led_index); else ctl |= (1 led_index); b43_write16(dev, B43_MMIO_GPIO_CONTROL, ctl); - spin_unlock_irqrestore(wl-leds_lock, flags); + spin_unlock_irqrestore(wl-leds_lock, flags); } static void b43_led_turn_off(struct b43_wldev *dev, u8 led_index, @@ -54,14 +54,14 @@ static void b43_led_turn_off(struct b43_ unsigned long flags; u16 ctl; - spin_lock_irqsave(wl-leds_lock, flags); + spin_lock_irqsave(wl-leds_lock, flags); ctl = b43_read16(dev, B43_MMIO_GPIO_CONTROL); if (activelow) ctl |= (1 led_index); else ctl = ~(1 led_index); b43_write16(dev, B43_MMIO_GPIO_CONTROL, ctl); - spin_unlock_irqrestore(wl-leds_lock, flags); + spin_unlock_irqrestore(wl-leds_lock, flags); } /* Callback from the LED subsystem. */ -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
Is this the correct patch? The first hunk conflicts with an earlier patch (b43legacy: Fix cancellation of work queues). John On Mon, Sep 10, 2007 at 11:59:20AM -0500, Larry Finger wrote: From: Michael Buesch [EMAIL PROTECTED] The wq must be canceled later on rmmod. It's nonfatal, if the wq runs on a device that's not started or down. It will handle these cases. But syncing in wireless_core_exit() will cause a deadlock with the restart_work. (restart work cancels itself) Signed-off-by: Michael Buesch [EMAIL PROTECTED] Signed-off-by: Larry Finger [EMAIL PROTECTED] --- John, Sorry, but I sent the bare patch in the first version. Larry drivers/net/wireless/b43legacy/main.c |2 ++ 1 file changed, 2 insertions(+) Index: wireless-dev/drivers/net/wireless/b43legacy/main.c === --- wireless-dev.orig/drivers/net/wireless/b43legacy/main.c +++ wireless-dev/drivers/net/wireless/b43legacy/main.c @@ -3021,6 +3021,7 @@ static void b43legacy_wireless_core_exit B43legacy_WARN_ON(b43legacy_status(dev) B43legacy_STAT_INITIALIZED); if (b43legacy_status(dev) != B43legacy_STAT_INITIALIZED) return; + b43legacy_set_status(dev, B43legacy_STAT_UNINIT); b43legacy_rng_exit(dev-wl); b43legacy_pio_free(dev); @@ -3520,6 +3521,7 @@ static void b43legacy_one_core_detach(st wldev = ssb_get_drvdata(dev); wl = wldev-wl; + cancel_work_sync(wldev-restart_work); b43legacy_debugfs_remove_device(wldev); b43legacy_wireless_core_detach(wldev); list_del(wldev-list); - 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 -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
On Mon, Sep 17, 2007 at 12:05:36PM -0500, Larry Finger wrote: John W. Linville wrote: Is this the correct patch? The first hunk conflicts with an earlier patch (b43legacy: Fix cancellation of work queues). John Yes, this one is correct. The first one was without a commit message, and had an error. H, not that one. There was another patch that (looking closer) you sent me and cc'ed bcm43xx-dev on or about 30 August. I guess I'll drop that one and use this one instead. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: fetching wireless dev
On Wed, Aug 29, 2007 at 07:34:58PM +0200, Richard Jonsson wrote: I can't figure out how to keep up to date with the wireless dev tree. I've set up as told by John W. Linville in a post here and use the everything branch. When browsing the tree at kernel.org I see changes from 24'th of august, but my local copy is from 15'th (when I first fetched) even after git fetch. What command am I supposed to use? I think 'git pull' is what you want. But be warned that wireless-dev will be rebased from time to time, and pulling won't work across rebases. What is the best practice to apply patches not yet in Linvilles tree? My purpose is to test patches from the list and will probably not do patches myself. The best practice would be to keep an up-to-date copy of Linus' tree (i.e. linux-2.6) using 'git pull'. Then when you want to experiment w/ wireless-dev, you can create a lightweight clone (my terminology) using a command like this: git clone --reference linux-2.6 git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git wireless-dev Then create a working branch for yourself: git checkout -b work origin/everything Then you can apply patch emails for testing. Save the patch email in mbox format, then use this command: git applymbox patch.mbox Then, build-test-patch-repeat... :-) Hth! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Updated Status on b43 driver and Fedora 7
On Fri, Aug 24, 2007 at 05:50:12PM -0500, Larry Finger wrote: If your V4 firmware is still in /lib/firmware, then the Fedora kernel is a little behind the wireless-dev tree. Once the code that uses the new naming scheme hits their kernel, your wireless will probably stop working. Be prepared. FWIW, this isn't quite true -- at least not in F7. It is true in rawhide, and I'm a bit surprised that no one has complained yet... :-) In F7 I am carrying a patch to reverse the change to the new firmware format. I want to keep F7 near wireless-dev's head, but I didn't want to break a bunch of existing configurations. I haven't quite figured-out how long I'm going to carry this in F7. It will not be in F8. Just curious, what was the motivation for the new firmware format? Can the new format be quickly described in high level terms? I'm wondering if a tool could easily convert the old firmware format to the new, so that we might add it as an upgrade tool for F8. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43, b43legacy: Fix inconsistency between branches 'b43' and 'everything' in wireless-dev
On Thu, Aug 23, 2007 at 06:05:40PM -0500, Larry Finger wrote: I'm not sure how to handle this. In it's present state, branch 'b43' cannot be used to generate a working version of b43 or b43legacy. In addition, the Kconfig and Makefile from b43legacy are not included, thus it is not possible to build b43legacy in that branch. I had neglected to pull the mac80211 updates into the branches that depend on them (now most of the driver branches). I have done that now, and pushed the results. Hth! John P.S. FWIW, b43legacy seems to have Kconfig and Makefile in my tree. I was able to build it just fine. Yes, I checked to make sure I had included them in git. :-) -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ALERT: firmware change for b43
On Sun, Aug 19, 2007 at 02:37:21PM -0500, Larry Finger wrote: Just in case you missed the details, the latest set of changes to b43 queued by Michael will require a new version of fwcutter, now called b43-fwcutter, and a new extraction of your firmware. Is there a tarball available for download, as with bcm43xx-fwcutter? It would be handy for packaging. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc3-mm1: fix b43 compilation
On Wed, Aug 22, 2007 at 11:56:43PM +0200, Michael Buesch wrote: On Wednesday 22 August 2007 18:33:58 Rafael J. Wysocki wrote: On Wednesday, 22 August 2007 11:06, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ - git-ixgbe.patch got dropped - git-net.patch destroyed it - then git-net got dropped as it doesn't work Apparently, the b43 driver is expecting another version of mac80211. This patch fixes the compilation, but I'm not sure what about the functionality. ;-) There seems to be a screwup somehow. These mac80211 API functions were recently changed to include the additional parameter. So it seems you carry an old version of mac80211. I think what happened is because Andrew dropped Dave M.'s net tree. Since mac80211 has been getting merged through Dave M., crucial bits are missing which then break the bits from wireless-dev. Andrew, if you find that you need to drop git-net again then I'll be happy to provide you with a wireless-dev patch that does not depend on Dave's tree. The mm-master branch in wireless-dev has dropped those patches which have gone to Dave M. in the hopes of avoiding conflicts. Dependencies are another matter... :-) John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [patch 6/6] b43: New firmware file format
On Tue, Aug 21, 2007 at 05:46:40PM +0200, Johannes Berg wrote:
On Sun, 2007-08-19 at 01:48 +0200, Michael Buesch wrote:
@@ -1598,8 +1601,29 @@ static int do_request_fw(struct b43_wlde
b43err(dev-wl, Firmware file \%s\ not found
or load failed.\n, path);
+ return err;
}
+ if ((*fw)-size sizeof(struct b43_fw_header))
+ goto err_format;
otherwise it oopses when the file can't be loaded.
ACK...here is a patch, in case you are lazy... :-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index dcf7edc..d8693cf 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -1600,6 +1600,7 @@ static int do_request_fw(struct b43_wldev *dev,
if (err) {
b43err(dev-wl, Firmware file \%s\ not found
or load failed.\n, path);
+ return err;
}
if ((*fw)-size sizeof(struct b43_fw_header))
goto err_format;
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Fri, Aug 17, 2007 at 02:52:56AM +0200, Johannes Berg wrote:
On Mon, 2007-08-06 at 13:05 -0400, John W. Linville wrote:
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
memcpy(dst, hdr-addr1, ETH_ALEN);
memcpy(src, hdr-addr3, ETH_ALEN);
- if (sdata-type != IEEE80211_IF_TYPE_STA) {
+ if (sdata-type != IEEE80211_IF_TYPE_STA ||
+ (is_multicast_ether_addr(dst)
+!compare_ether_addr(src, dev-dev_addr)))
return TXRX_DROP;
I can confirm that this works (applies if you s/ieee80211.c/rx.c/) for
IPv6 link local addresses, and it's definitely the right thing to do
here.
Yes, seems so. FWIW, this patch is in later Fedora kernels.
Unfortunately (due to the ieee80211.c - rx.c issue you mentioned)
applying this to 2.6.23 conflicts with patches already queued for
2.6.24. Since my experiments show that git doesn't help much in this
instance, I'll need to work something out with Dave M. if we are to
get this into 2.6.23.
If nothing else, I suppose we can just wait for 2.6.23 and send this
patch to -stable. Would that burn anyone's biscuits?
John
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Does auto-loading of b43 work for you?
On Thu, Aug 16, 2007 at 06:40:23PM -0500, Larry Finger wrote: Has anyone used the new driver variation known as b43 from that branch of wireless-dev and gotten auto-loading at bootup of the b43 module on i386 or x86_64 platforms. It still doesn't work here even after upgrading to the latest version of udev. Before I post to LKML regarding this problem, I would like to get an idea if is restricted to my system, or if it is a general problem with x86 architectures. We know it works on PPC platforms. If your system is also failing, I would like to know your distro. Seems to work fine for me w/ latest wireless-dev built w/ mostly-stock (had to change BCM43XX-MAC80211 to B43) F-7 kernel config on T41 w/ F-7. Don't even have the %X patch. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
wireless-dev rebased, new rebasing policies
Greetings! Some of you have already noticed that the wireless-dev tree has been rebased. I adopted the mac80211 work of Jiri Benc as a base, then re-imported all of the mac80211 drivers (and the SSB stuff) from wireless-dev into individual branches. There is also an 'everything' branch into which all the other branches get pulled, and an 'mm-master' branch which has the sole purpose of feeding patches to akpm while minimizing conflicts with the other networking trees. The master branch is a direct pull of something relatively recent from Linus, usually an -rc or release tag. Recent versions of git seem to hide remote branches by default when cloning a tree, so by default you will just get my master branch. Since this isn't very interesting for wireless development, you will want to recreate one or more of my branches to work from as a base. At a minimum, everyone from early adopter users to driver maintainers will want the 'everything' branch, so I will illustrate recreating that below. Other branches are done similarly. /home/linville/git/wireless-dev [linville-t43.mobile]: git branch * master /home/linville/git/wireless-dev [linville-t43.mobile]: git branch -r origin/HEAD origin/adm8211 origin/b43 origin/everything origin/iwlwifi origin/mac80211 origin/master origin/merged-upstream origin/mm-master origin/p54 origin/rt2x00 origin/ssb origin/zd1211rw /home/linville/git/wireless-dev [linville-t43.mobile]: git checkout -b everything origin/everything Switched to a new branch everything /home/linville/git/wireless-dev [linville-t43.mobile]: git branch * everything master Unlike the way wireless-dev was used in the past, I make no promises about rebasing. I intend to rebase most/all of the branches at least as often as Linus produces an -rc or release tag, and I reserve the right to rebase more often as I deem necessary. I'm sorry, but as you can see I have to manage a lot of patches. Keeping them based off a recent head is helpful to me. I will entertain suggestions for how to minimize rebasing pain for anyone following this tree. However, the best suggestion I have for anyone tracking wireless-dev is for them to get their favorite driver(s) merged upstream. Barring that, I understand that quilt can be a good tool for tracking stacks of patches in development. The git-format-patch, git-applymbox, and git-rebase commands are handy as well. Those simply following the tree should learn about the --reference option to git-clone, and should use it often. Keeping a backup of previous git trees with any work in progress wouldn't hurt either. Questions? Complaints? Comments? Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301 - bcm43xx-legacy
On Thu, Aug 09, 2007 at 08:33:52PM +0200, Martin Langer wrote: I wouldn't call it b43. Please add some letters here. BCM is still developing their bcm43xx platform. So it's possible that we will find another point in the future where we have to split b43 again. b43 is more a common name in my eyes and b43something would be better. Premature optimization -- if something new shows-up, let it have the longer name... John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Fri, Aug 03, 2007 at 01:02:12AM -0700, Michael Wu wrote:
This doesn't seem quite right. I think ieee80211_rx_h_data is a safer place
for this check (inside the IEEE80211_FCTL_FROMDS case), and allows various
statistics to be updated. ieee80211_rx_h_sta_process is another function that
might work though that would probably involve more code to add all the right
checks.
The patch below seems to work for me w/ an otherwise stock F-7 kernel
w/ iwl3945. Thoughts?
From: John W. Linville [EMAIL PROTECTED]
[PATCH] mac80211: filter locally-originated multicast frames
In STA mode, the AP will echo our traffic. This includes multicast
traffice.
Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.
Signed-off-by: John W. Linville [EMAIL PROTECTED]
---
net/mac80211/ieee80211.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index a42e70e..0097b0a 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
memcpy(dst, hdr-addr1, ETH_ALEN);
memcpy(src, hdr-addr3, ETH_ALEN);
- if (sdata-type != IEEE80211_IF_TYPE_STA) {
+ if (sdata-type != IEEE80211_IF_TYPE_STA ||
+ (is_multicast_ether_addr(dst)
+!compare_ether_addr(src, dev-dev_addr)))
return TXRX_DROP;
- }
break;
case 0:
/* DA SA BSSID */
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Thu, Aug 02, 2007 at 11:46:18PM +0100, David Woodhouse wrote:
On Thu, 2007-08-02 at 18:30 -0400, Daniel Drake wrote:
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?
It receives its own neighbour solicitation (multicast) packets when the
AP sends them back out again. These packets...
23:41:56.046939 00:0a:95:f3:99:92 33:33:ff:f3:99:92, ethertype IPv6
(0x86dd), length 78: :: ff02::1:fff3:9992: ICMP6, neighbor
solicitation, who has fe80::20a:95ff:fef3:9992, length 24
You should be able to see this without _any_ IPv6 infrastructure -- and
you'll see the link-local IPv6 address remains 'tentative'.
Once you've fixed that, setting up a local route advertisement dæmon
(radvd) to give you site-local addresses is fairly trivial too -- and
then you can also check that Ethernet multicast is working properly.
I hacked-up the (untested) patch below -- thoughts?
---
From: John W. Linville [EMAIL PROTECTED]
[PATCH] mac80211: filter locally-originated multicast frames
In STA mode, the AP will echo our traffic. This includes multicast
traffice.
Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.
Signed-off-by: John W. Linville [EMAIL PROTECTED]
---
net/mac80211/ieee80211.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index a42e70e..6dc6451 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4263,11 +4263,14 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct
sk_buff *skb,
rx.u.rx.ra_match = 0;
} else if (!multicast
compare_ether_addr(sdata-dev-dev_addr,
- hdr-addr1) != 0)
{
+ hdr-addr1)) {
if (!sdata-promisc)
continue;
rx.u.rx.ra_match = 0;
- }
+ } else if (multicast
+
!compare_ether_addr(sdata-dev-dev_addr,
+ hdr-addr3))
+ rx.u.rx.ra_match = 0;
break;
case IEEE80211_IF_TYPE_IBSS:
if (!bssid)
--
John W. Linville
[EMAIL PROTECTED]
___
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 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. 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. Acked-by: John W. Linville [EMAIL PROTECTED] -- John W. Linville [EMAIL PROTECTED] ___ 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 Thu, Jul 26, 2007 at 12:56:20PM -0500, Larry Finger wrote:
John W. Linville wrote:
On Thu, Jul 26, 2007 at 11:33:01AM -0500, 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.
@@ -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));
Larry,
How does this relate to the bcm43xx patch you asked me to revert
(and has been reverted in F-7)? That one change == to , while
this one changes == to !=. Instead of reverting the other,
should it do the same thing as this?
It really doesn't matter whether one uses or != here. The number in
question is = 0 and the test for for zero occurs earlier in the routine
and ends with a return. Now that you mention it, it would be best to make
bcm43xx nad bcm43xx-mac80211 look the same. I'll modify and resubmit the
patch.
Hmmm...well, if you asked to revert it on bcm43xx, why is it appropriate here?
John
--
John W. Linville
[EMAIL PROTECTED]
___
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 Thu, Jul 26, 2007 at 11:33:01AM -0500, 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.
@@ -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));
Larry,
How does this relate to the bcm43xx patch you asked me to revert
(and has been reverted in F-7)? That one change == to , while
this one changes == to !=. Instead of reverting the other,
should it do the same thing as this?
John
--
John W. Linville
[EMAIL PROTECTED]
___
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 Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote: On Thu, 2007-07-19 at 20:38 -0500, Larry Finger wrote: 4. Once bcm43xx-mac80211 gets merged to mainline, then Michael's driver should become bcm43xx and my driver gets its PCI IDs stripped to the 802.11b-only devices and once again becomes bcm4301. This name change for Michael's driver would cause some disruption for current users as their firmware would have the wrong name/version. That might be too much of a problem. Actually, the common practice is that the new driver that doesn't supplant the old driver immediately and for the whole range of hardware gets a new name. Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100. Yes, this preserves stability for happy bcm43xx users. Still taking suggestions for the new name for bcm43xx-mac80211... :-) Also, we could introduce a kernel option to enable support for new devices in your driver. Yes, this is probably worthwhile for those wishing to avoid PCI ID conflicts between the drivers. I have also been speculating that perhaps we need an option for a secondary PCI ID table, so that a driver could support a large range of PCI IDs but then gracefully bow-out if another driver had a certain ID in its primary table. Does that make any sense? It would seem to be applicable to a number of drivers in the kernel. I would also consider the option to use different names for v3 and v4 firmware. I have a file /etc/modprobe.d/bcm43xx that reads options bcm43xx fwpostfix=.3 options bcm43xx_mac80211 fwpostfix=.4 but we cannot expect every distro (let alone every user) to take care of the naming conflict. Users don't expect the need to rename firmware, and we shouldn't create a problem for them. Yes, we should probably start using a default value for fwpostfix. As dwmw2 suggested, it would also be nice to fall back to an empty fwpostfix if the firmware is not found w/ the default extension. John -- John W. Linville [EMAIL PROTECTED] ___ 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 Fri, Jul 20, 2007 at 01:57:48PM -0400, Pavel Roskin wrote: On Fri, 2007-07-20 at 09:33 -0700, Ehud Gavron wrote: The driver should have a name that reflects its use and capabilities. Not necessarily. End users should be shielded from such details by distributions. Do you know the name of the Windows driver for your network card? Does it reflect its use and capabilities? Now, if we are talking about power users, who can occasionally recompile the kernel or install a program not from the distribution, they would be helped by reasonable names of the drivers. Also, distribution maintainers would feel better if the drivers are not renamed, so that /etc/modprobe.d/ doesn't need to be scanned for the old names on kernel upgrade. 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. John -- John W. Linville [EMAIL PROTECTED] ___ 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 Thu, Jul 12, 2007 at 09:34:55AM -0500, Larry Finger wrote: My plan is to clean up the code, check it with my BCM4306 and BCM4318 devices, and then make it available as a patch against the mainline source for more general testing. At the same time, I will publish the results of my performance testing of all 3 models. Once it is shown to be reliable, a decision can be made regarding its inclusion in mainline and if it should support B and G devices, or be restricted to B-only devices. The A-PHY code has been stripped out. This sounds great. Perhaps this can be the migration vehicle for current bcm43xx users to come to mac80211? Especially for those with hardware not supported by the current bcm43xx-mac80211 driver. Are you proposing to add a third driver and deprecate the softmac driver? Or can we treat this as a port of the existing driver to mac80211? I think that might be better for users and distros, and might let us get rid of the softmac component that much sooner. As for the name, if we treat this as a port of the current driver to mac80211 then perhaps we should just continue using the bcm43xx name? If so, we need a new name for the v4-based driver -- bcm43xxtoo? :-) Regarding hardware support, I have begun to lean towards having the v3 driver continue to support all the hardware it does now. I'm certainly prepared to hear the downside of that position. :-) What exactly do we gain from using the v4 firmware? Anyway, I'm glad to hear we are making progress on this front. Good job, Larry! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4318 in an HP dv5120us lappy
On Sat, Jun 02, 2007 at 01:39:25PM -0500, Larry Finger wrote: I can only guess at why FC 7 uses the mac80211 driver. To wean people off of softmac's teat... -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Merging SSB upstream
On Sun, May 06, 2007 at 11:44:27AM +0200, Michael Buesch wrote: On Sunday 06 May 2007 04:00:51 John W. Linville wrote: I had to remove the b44 ssb changes from fedora because a) users reported problems; Which problems were that? The 2 compile issues? Trivial to fix if that's the only issue. ;) I knew you would ask that... :-) I don't think there was a bugzilla, but Dave Jones forwarded an email to me from MASAO TAKAHASHI in late February. Takahashi-san (forgive me if I did that wrong) was complaining about tx timeouts after I had added the full wireless-dev patchset to rawhide. Removing the b44 bits of the patch seemed to remove the problem. That's all the info I have. Perhaps Dave or Takahashi-san can add to the description? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Merging SSB upstream
On Sun, May 06, 2007 at 03:03:17AM +0200, Michael Buesch wrote: So, now that mac80211 is merged upstream, I think it's time to merge SSB and the b44-ssb port upstream. Note that bcm43xx-mac80211 is _not_ ready for upstream, yet. ACK, unfortunately. What do you think? I'd like to merge ssb as-is, although the embedded-device parts are not quite finished, yet. But they don't interfere with the non-embedded parts used by b44 and the bcm43xx PCI cards. How much testing have you (and others) done w/ b44? I had to remove the b44 ssb changes from fedora because a) users reported problems; and b) I was more worried about wireless than b44+ssb. (sorry!) So, has anyone been using b44 in -mm? So we _could_ remove the ssb-mips code, but I don't like to do that for better maintainability. It doesn't hurt anyone IMO. I guess I don't see a problem w/ merging the mips part, as long as the b44 part has been thoroughly tested. I wonder if Ralf has an opinion? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Is mac80211 generally available for use with bcm43xx?
On Thu, May 03, 2007 at 05:22:08PM -0400, Pavel Roskin wrote: On Thu, 2007-05-03 at 13:53 -0600, Oscar A. Valdez wrote: Is the mac80211 module generally available for use with bcm43xx? If so, how? I've researched the matter, but haven't figured it out. Yes, the module is present in the wireless-dev git repository. It's not yet in any released version of Linux. FWIW, it should be available in Fedora 7 (due at the end of the month). John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ieee80211-crypt: Make some TKIP and CCMP error logging conditional on IEEE80211_DEBUG_DROP
On Tue, Apr 17, 2007 at 10:25:08AM -0400, Dan Williams wrote: On Tue, 2007-04-17 at 09:12 -0400, John W. Linville wrote: On Mon, Apr 16, 2007 at 07:24:14PM -0500, Larry Finger wrote: Michael Buesch wrote: On Monday 16 April 2007 20:50, Larry Finger wrote: @@ -229,6 +229,7 @@ void free_ieee80211(struct net_device *d static int debug = 0; u32 ieee80211_debug_level = 0; +EXPORT_SYMBOL_GPL(ieee80211_debug_level); We don't use the _GPL suffix in mac80211. Upon inspection, neither does most of ieee80211. It is now changed. You are strongly encouraged to use the _GPL version for new symbol exports, especially those which are fundamentally internal to in-kernel subsystems and/or have no reasonable usage by drivers. FWIW, this symbol would seem to fulfill both of those criteria. If you do not object, I would prefer the _GPL version of the patch. What's the rationale for mac80211 _not_ using _GPL exports? I thought most new exports were pretty much required to be _GPL (otherwise somebody would NAK it) unless it was really, really necessary that they weren't. An argument against _GPL exports for mac80211 might be leaving the exports alone as a token of gratitude or respect towards Devicescape for having seeded the development of mac80211 with a big chunk of code. While I do thank Devicescape for their support, I'm not sure that this argument would be truly compelling. A more presuasive argument in favor of this pragmatism is that it would be counter-productive to discourage driver availability. At this point regulatory issues are still enough of a spectre that some vendors will want the option of offering non-GPL drivers. Such drivers would clearly not be redistributable, but there are arguments that allow for such drivers (i.e. the user installed the driver -- not us, etc like Nvidia video drivers). Of course, no one likes enabling this kind of bad behaviour. Probably the best reason in favor of leaving them as-is is that they were written that way by their original author(s). Should I ask for opinionated discussion on the matter? :-) John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ieee80211-crypt: Make some TKIP and CCMP error logging conditional on IEEE80211_DEBUG_DROP
On Mon, Apr 16, 2007 at 07:24:14PM -0500, Larry Finger wrote: Michael Buesch wrote: On Monday 16 April 2007 20:50, Larry Finger wrote: @@ -229,6 +229,7 @@ void free_ieee80211(struct net_device *d static int debug = 0; u32 ieee80211_debug_level = 0; +EXPORT_SYMBOL_GPL(ieee80211_debug_level); We don't use the _GPL suffix in mac80211. Upon inspection, neither does most of ieee80211. It is now changed. You are strongly encouraged to use the _GPL version for new symbol exports, especially those which are fundamentally internal to in-kernel subsystems and/or have no reasonable usage by drivers. FWIW, this symbol would seem to fulfill both of those criteria. If you do not object, I would prefer the _GPL version of the patch. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
BCM43xx_LOCALE_USA_CANADA_ANZ correct? -- Re: Please pull 'upstream-fixes' branch of wireless-2.6
BCM43xx_LOCALE_USA_CANADA_ANZ a correct grouping?
John
- Forwarded message from stevie.glass [EMAIL PROTECTED] -
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
b=b/L4/k3Vj3gsfNabz0EfEE6pG2gAFJyPx+52Mcx3IuMfpM7cFY2sv/jbixkmWSJQcARwPoiHFNmv8mC4k8cwgpd/pxeHDznfl+sRmG0EH2Od3cSc9wFXkvZE2CyLJwUj88acjE3W8JODmYDO8ha7p0fA0ySae3ExOQyzuSZ+xZA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
b=c13rHvw5Z5QAZnP6CrA3+XeeF4D8Zdi7GRjiZK3vAoqYZ78O8yNQ6bkAzpi1pKGhbffVx3bGd44Ok057V3PWVhsMjncGr5jMKiiAEQJRpDpKIB++oimQXCPHjGCxUQwesBr2V/yvL06CcBZKsupeD7hHAvo2CeVCLWCuSmcwiGM=
Date: Wed, 11 Apr 2007 08:16:59 +1000
From: stevie.glass [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
User-Agent: Icedove 1.5.0.10 (X11/20070329)
To: John W. Linville [EMAIL PROTECTED]
Subject: Re: Please pull 'upstream-fixes' branch of wireless-2.6
In-Reply-To: [EMAIL PROTECTED]
X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00,SPF_HELO_PASS,
SPF_PASS autolearn=unavailable version=3.1.8-gr0
X-Spam-Checker-Version: SpamAssassin 3.1.8-gr0 (2007-02-13) on
ra.tuxdriver.com
Hi John,
Apols for unsolicted email but I was looking through your patch and this
caught my eye:
+/* set the maximum channel based on locale set in sprom or witle locale
option */
+ switch (bcm-sprom.locale) {
+ case BCM43xx_LOCALE_THAILAND:
+ case BCM43xx_LOCALE_ISRAEL:
+ case BCM43xx_LOCALE_JORDAN:
+ case BCM43xx_LOCALE_USA_CANADA_ANZ:
+ case BCM43xx_LOCALE_USA_LOW:
+ max_bg_channel = 11;
+ break;
+ case BCM43xx_LOCALE_JAPAN:
+ case BCM43xx_LOCALE_JAPAN_HIGH:
+ max_bg_channel = 14;
+ break;
+ default:
+ max_bg_channel = 13;
+ }
+
Specifically BCM43xx_LOCALE_USA_CANADA_ANZ. A/NZ is certainly not the
same as USA/Canada - in Australia we get 13 channels not 11 of US/Canada.
I'm sure this is because I don't know your driver but just in case you
do need to split out an ANZ definition I thought I'd shout up.
Steve
- End forwarded message -
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM43xx_LOCALE_USA_CANADA_ANZ correct? -- Re: Please pull 'upstream-fixes' branch of wireless-2.6
On Thu, Apr 12, 2007 at 09:52:17AM -0500, Larry Finger wrote: John W. Linville wrote: BCM43xx_LOCALE_USA_CANADA_ANZ a correct grouping? Those categories were copied from the data in the SPROM on the BCM43xx chips, which are obviously out of date. That said, it is likely that the code will do the right thing in Australia and New Zealand as most of the cards have a 0 in the locale field of the SPROM, which falls through to the default case of the switch. Cool, thanks... -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
On Thu, Mar 22, 2007 at 05:02:45PM -0400, Pavel Roskin wrote: On Thu, 2007-03-22 at 15:36 -0500, Larry Finger wrote: I think softmac and bcm43xx-sm should be in one tarball and should be built together with one make invocation. Just melt the codebases together. :) That's another problem with symbols if softmac is enabled in the kernel. Unless softmac is changing quickly or has major bugs in the recent kernels, I suggest leaving it in the kernel. Both the old driver and softmac are likely to remain in the kernel for some period of time (however short that might be). When the drivers come out, softmac comes out too. It certainly will not be left in the kernel to support an out of kernel driver. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
On Thu, Mar 22, 2007 at 02:35:14PM -0500, Larry Finger wrote: Developing a V3 firmware driver for 802.11b devices doesn't seem to be viable. From what I see in the latest versions of the specifications, support for 802.11b devices is disappearing from the Broadcom drivers. Thus, I think a standalone bcm43xx-softmac solution would be best. I'm not sure I follow the reasoning here. Won't the softmac driver still need v3 firmware? Is converting the softmac driver to mac80211 (as bcm43xx-old or somesuch) really a bigger job than trying to maintain out-of-tree code for both the driver and the softmac component from now on? You are also imposing upon distros a choice between shipping out-of-kernel drivers or just not supporting certain hardware. Both choices suck -- I can elaborate if it isn't clear why. I'd much rather see two drivers, one for v3 firmware and one for later firmware. Why is this such a problem? Afterall, at one time the mac80211 (then d80211) driver supported v3 firmware. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.21-rc4-mm1
On Wed, Mar 21, 2007 at 01:14:55PM -0500, Larry Finger wrote: Andrew Morton wrote: On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ First impressions: Several of the same bugs as rc3-mm*: * Freezes immediately if I touch the wlan0 device after loading the new Broadcom wireless driver. The version of the ssb driver in 2.6.21-rc4-mm1 has a bug that causes a kernel oops if the bcm43xx chip contains a USB (dangling) core. This bug has been fixed in Michael Buesch's tree, but apparently not yet in Linville's wireless-dev tree. The patch is as follows: FWIW, that patch is in my tree as of yesterday. Presumably it should be in the next -mm. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] Eliminate some 'G Mode Enable' magic numbers
On Wed, Mar 14, 2007 at 11:18:28AM -0500, Larry Finger wrote: In code manipulating the TM State Low register of 802.11 cores, two different magic numbers are used to reference the 'G Mode Enable' bit. One of these, 0x2000, is clear, but the other, (0x800 18), is not. This patch replaces both types with a defined constant. In addition, two bits in the TM State High registers are given definitions to help in following the code. Looks reasonable to me -- not sure why this is an RFC? Does anyone object? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix typo in B5PHY init specifications
On Mon, Mar 12, 2007 at 09:23:30AM -0400, Joseph Jezak wrote: David Woodhouse wrote: On Fri, 2007-03-02 at 11:30 -0600, Larry Finger wrote: There was an error in the B5PHY init specifications. This patch doesn't fix the machine check in bcm43xx_phy_initb5 which Pavel Roskin and I reported a couple of weeks ago. To get rid of that crash, I still have to revert an earlier 'spec update' patch (740ac4fb08866d702be90f167665d03759bd27d0). Yeah, the issue is that the Rev1 cards have to be init'd with g mode off. I'm not sure anyone has picked up this fix yet. The relevant spec fix is here: http://bcm-v4.sipsolutions.net/802.11/PHY/calinit FWIW, by inspection it looks like the mac80211-based driver is (trying?) to implement this change. David, have you tried the mac80211 version? Does it still have the same crash? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix typo in B5PHY init specifications
On Mon, Mar 12, 2007 at 12:42:18PM -0500, Larry Finger wrote: David Woodhouse wrote: On Mon, 2007-03-12 at 10:53 -0400, John W. Linville wrote: FWIW, by inspection it looks like the mac80211-based driver is (trying?) to implement this change. David, have you tried the mac80211 version? Does it still have the same crash? Should the one in 2.6.20-1.2982.fc7 be OK? I can try that relatively easily; anything else might need to wait till I get home. I don't think it will improve anything. I don't currently have a copy of wireless-dev, but the code in the mb tree is identical with that of wireless-2.6. I'm currently trying to figure out the spec at http://bcm-v4.sipsolutions.net/802.11/PHY/calinit and what we need to change. Huh? Are you looking in drivers/net/wireless/mac80211/bcm43xx? It certainly seems to differ quite a bit from what is in drivers/net/wireless/bcm43xx (i.e. no the softmac-based version). John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix typo in B5PHY init specifications
On Mon, Mar 12, 2007 at 04:16:34PM +0100, David Woodhouse wrote: On Mon, 2007-03-12 at 10:53 -0400, John W. Linville wrote: FWIW, by inspection it looks like the mac80211-based driver is (trying?) to implement this change. David, have you tried the mac80211 version? Does it still have the same crash? Should the one in 2.6.20-1.2982.fc7 be OK? I can try that relatively easily; anything else might need to wait till I get home. Yes, I think that will do. It certainly looks to be up-to-date. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
