Re: RFC: A workaround for BCM43XX devices with no on-board SPROM

2010-03-19 Thread John W. Linville
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

2010-02-15 Thread John W. Linville
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

2010-01-27 Thread John W. Linville
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)

2010-01-25 Thread John W. Linville
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

2010-01-22 Thread John W. Linville
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

2010-01-22 Thread John W. Linville
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

2010-01-19 Thread John W. Linville
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

2009-12-23 Thread John W. Linville
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

2009-12-23 Thread John W. Linville
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

2009-11-23 Thread John W. Linville
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

2009-11-20 Thread John W. Linville
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

2009-10-16 Thread John W. Linville
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

2009-10-06 Thread John W. Linville
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

2009-08-31 Thread John W. Linville
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

2009-08-26 Thread John W. Linville
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

2009-08-24 Thread John W. Linville
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

2009-08-20 Thread John W. Linville
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

2009-08-20 Thread John W. Linville
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: LP-PHY: Fix reading old mode in the set TX power control routine

2009-08-17 Thread John W. Linville
On Mon, Aug 17, 2009 at 09:33:06PM +0200, Gábor Stefanik wrote:
 2009/8/14 Gábor Stefanik netrolller...@gmail.com:
  Check the mode the hardware is in, not the mode we used the last time.
 
  Signed-off-by: Gábor Stefanik netrolller...@gmail.com
  ---
  Mark, please test if this fixes the TX power control WARN_ON you were
  seeing.
 
  drivers/net/wireless/b43/phy_lp.c |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/net/wireless/b43/phy_lp.c
  b/drivers/net/wireless/b43/phy_lp.c
  index 292ee51..76457f7 100644
  --- a/drivers/net/wireless/b43/phy_lp.c
  +++ b/drivers/net/wireless/b43/phy_lp.c
  @@ -1015,9 +1015,9 @@ static void lpphy_set_tx_power_control(struct
  b43_wldev *dev,
         struct b43_phy_lp *lpphy = dev-phy.lp;
         enum b43_lpphy_txpctl_mode oldmode;
 
  -       oldmode = lpphy-txpctl_mode;
         lpphy_read_tx_pctl_mode_from_hardware(dev);
  -       if (lpphy-txpctl_mode == mode)
  +       oldmode = lpphy-txpctl_mode;
  +       if (oldmode == mode)
                 return;
         lpphy-txpctl_mode = mode;
 
  --
  1.6.2.4
 
 
 John, any news on this one? I can't see it in wireless testing.

Larry said It does not fix it here. I'll take a look at the specs...

-- 
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

2009-08-07 Thread John W. Linville
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

2009-08-04 Thread John W. Linville
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

2009-07-14 Thread John W. Linville
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

2009-01-14 Thread John W. Linville
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

2009-01-14 Thread John W. Linville
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

2009-01-12 Thread John W. Linville
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

2009-01-09 Thread John W. Linville
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

2008-12-17 Thread John W. Linville
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...

2008-10-22 Thread John W. Linville
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

2008-09-18 Thread John W. Linville
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

2008-09-17 Thread John W. Linville
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

2008-09-10 Thread John W. Linville
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

2008-09-08 Thread John W. Linville
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

2008-09-06 Thread John W. Linville
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

2008-06-14 Thread John W. Linville
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

2008-06-14 Thread John W. Linville
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

2008-06-09 Thread John W. Linville
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

2008-05-28 Thread John W. Linville
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

2008-05-15 Thread John W. Linville
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

2008-05-08 Thread John W. Linville
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

2008-05-01 Thread John W. Linville
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

2008-04-01 Thread John W. Linville
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: Asus WL-138G V2 (BCM4318 non-E rev02) scans but doesn't associate using b43 driver, works with bcm43xx

2008-03-15 Thread John W. Linville
On Sat, Mar 15, 2008 at 02:19:44PM +0100, Stefanik Gábor wrote:
 Wait, are you Hungarian too? Looks like b43 specifically hates 4318/02s
 designed for the EU (13 channel versions). Someone from the USA should
 confirm, this looks more and more like a mac80211 bug. (Note: my AP is on
 channel 1, so it's not in the EU-only range.) Also, are there any records of
 an EU 4318/02 user getting b43 to work? Japan might also be of interest.
 Someone should also try loading mac80211 (or cfg80211 on the
 wireless-testing tree) with ieee80211_regdom=64 to see if that helps. (I
 can't, as my OpenSUSE box died.)

Hmmm...that is an interesting thought.  I'll have to give that a try.

BTW, with the wireless-testing tree it is:

options cfg80211 ieee80211_regdom=JP

whereas the older trees had it as:

options mac80211 ieee80211_regdom=64

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: bcm4311 + 2.6.24 + patch gives blinking wireless LED

2008-03-14 Thread John W. Linville
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

2008-03-14 Thread John W. Linville
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

2008-02-16 Thread John W. Linville
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

2008-01-10 Thread John W. Linville
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

2008-01-06 Thread John W. Linville
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

2008-01-06 Thread John W. Linville
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

2008-01-06 Thread John W. Linville
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

2008-01-06 Thread John W. Linville
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?

2007-12-18 Thread John W. Linville
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

2007-12-15 Thread John W. Linville
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

2007-12-14 Thread John W. Linville
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

2007-12-13 Thread John W. Linville
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

2007-11-22 Thread John W. Linville
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

2007-11-21 Thread John W. Linville
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

2007-11-21 Thread John W. Linville
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

2007-11-21 Thread John W. Linville
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

2007-11-16 Thread John W. Linville
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

2007-11-10 Thread John W. Linville
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

2007-11-09 Thread John W. Linville
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

2007-11-07 Thread John W. Linville
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.

2007-10-19 Thread John W. Linville
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

2007-10-19 Thread John W. Linville
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

2007-10-16 Thread John W. Linville
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

2007-10-10 Thread John W. Linville
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

2007-10-03 Thread John W. Linville
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

2007-09-17 Thread John W. Linville
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

2007-09-17 Thread John W. Linville
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

2007-08-29 Thread John W. Linville
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

2007-08-27 Thread John W. Linville
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

2007-08-23 Thread John W. Linville
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

2007-08-22 Thread John W. Linville
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

2007-08-22 Thread John W. Linville
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

2007-08-21 Thread John W. Linville
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

2007-08-17 Thread John W. Linville
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?

2007-08-17 Thread John W. Linville
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

2007-08-14 Thread John W. Linville
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

2007-08-09 Thread John W. Linville
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

2007-08-06 Thread John W. Linville
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

2007-08-02 Thread John W. Linville
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

2007-07-27 Thread John W. Linville
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

2007-07-26 Thread John W. Linville
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

2007-07-26 Thread John W. Linville
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

2007-07-20 Thread John W. Linville
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

2007-07-20 Thread John W. Linville
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

2007-07-19 Thread John W. Linville
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

2007-06-03 Thread John W. Linville
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

2007-05-06 Thread John W. Linville
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

2007-05-05 Thread John W. Linville
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?

2007-05-03 Thread John W. Linville
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

2007-04-17 Thread John W. Linville
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

2007-04-17 Thread John W. Linville
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

2007-04-12 Thread John W. Linville
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

2007-04-12 Thread John W. Linville
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

2007-03-25 Thread John W. Linville
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

2007-03-25 Thread John W. Linville
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

2007-03-21 Thread John W. Linville
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

2007-03-14 Thread John W. Linville
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

2007-03-12 Thread John W. Linville
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


  1   2   >