Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
On Thu, Mar 18, 2010 at 08:31:24PM +0100, Michael Buesch wrote: > On Thursday 18 March 2010 18:46:35 Larry Finger wrote: > > It it reasonable to keep the vendor portion of the MAC and only replace the > > "serial number", or would it be better to randomize all 6 octants? > > I think it doesn't really matter. It might be a good idea to set the LAA bit...? -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 01/11] b43: N-PHY: add some registers and structs definitions
On Wed, Feb 10, 2010 at 12:02:11AM +0100, Michael Buesch wrote: > On Tuesday 09 February 2010 21:04:33 Rafał Miłecki wrote: > > +#define B43_MMIO_PSM_PHY_HDR 0x492 /* programmable state > > machine */ > > The comment doesn't make a lot of sense. > In case you don't know, the PSM is the part of the hardware > that executes the firmware. Rafał, Are you going to repost this series and/or respond to Michael's comments? I tried to apply some of the ones Michael didn't comment upon, but they seem to depend on the ones in question. Thanks, John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: N PHY: Fix compilation after removal of typdef b43_c32
On Tue, Jan 26, 2010 at 04:42:02PM -0600, Larry Finger wrote: > In the conversion between typedef and struct, two places that needed a > "struct" > were missed. > > Signed-off-by: Larry Finger > --- > > John, > > Without these, compilation fails. > > Larry Larry, thanks for fixing this! Sorry I missed those bits. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 2/4] b43: make cordic common (LP-PHY and N-PHY need it)
On Mon, Jan 25, 2010 at 07:53:19PM +0100, Michael Buesch wrote:
> On Monday 25 January 2010 19:36:27 Rafał Miłecki wrote:
> > W dniu 25 stycznia 2010 19:35 użytkownik Rafał Miłecki
> > napisał:
> > > 2010/1/25 Michael Buesch :
> > >> On Monday 25 January 2010 18:59:59 Rafał Miłecki wrote:
> > >>> +/* Complex number using 2 32-bit signed integers */
> > >>> +typedef struct { s32 i, q; } b43_c32;
> > >>
> > >> No typedef. ever.
> > >
> > > Well, I just copied (Gabor's?) code here. But of course I can fix this
> > > by the way, no problem :)
>
> Yeah, I saw that. We can fix it while we're at it. ;)
>
> > > Just read about typedef in Linux Kernel Coding Style, didn't know
> > > about this earlier. Thanks for pointing.
> >
> > Is this OK to fix this in separated patch? Or should I modify this set
> > of patches?
>
> Well, as you touch any reference to the typedef anyway (you renamed it),
> you can just put the keyword "struct" in front of the references and no
> separate patch is needed.
> It won't even grow your current patch in the number of changed lines.
I took care of these modifications to the original patch...
John
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 0/5] b43: more N-PHY stuff
On Fri, Jan 22, 2010 at 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 0/5] b43: more N-PHY stuff
On Fri, Jan 22, 2010 at 01:53:11AM +0100, Rafał Miłecki wrote: > John, I hope to have patch submission fixed, please let me know if there > is anything wrong still. This batch applied with no problems -- thanks, Rafał! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 5/5 V2] b43: N-PHY: silence warnings, add missing call
On Mon, Jan 18, 2010 at 12:21:49AM +0100, Rafał Miłecki wrote: > Signed-off-by: Rafał Miłecki > --- > New patch I didn't include earlier. Rafał, I just applied this 5-patch series and the preceding 7-patch series, and I had to fixup every single one manually due to the apparently busted mailer you are using. User-Agent: Opera Mail/10.10 (Linux) The only reason I went to this trouble is because a) I want the N-phy stuff and b) you sent small, manageable patches. But don't misunderstand -- I have no intention of continuing to fix these manually. Learn to use "git send-email" or find some other mailer to send your patches -- I recommend Mutt. In any case, do not expect your patches to get merged unless in the future unless you can rectify this situation at your end. I just don't have the bandwidth for dealing with crap like this. Thanks, John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH][resend with linux-wireless] b43: N-PHY: clean table init, check PHY rev
On Wed, Dec 23, 2009 at 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?= > 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 > --- > 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: [PATCH][resend with linux-wireless] b43: N-PHY: clean table init, check PHY rev
On Wed, Dec 23, 2009 at 04:10:35PM +0100, Rafał Miłecki wrote: > W dniu 23 grudnia 2009 15:52 użytkownik John W. Linville > If you decide to agree to commit this patch and you want to me resend > this with correct white spaces, please ping me about. For future mails > I'll use some native mailer. I'm fine with the patch -- at least it demonstrates that something else is needed for rev 3+. -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: N-PHY: clean table init, check PHY rev
On Wed, Dec 23, 2009 at 12:02:25PM +0100, Michael Buesch wrote: > On Wednesday 23 December 2009 11:34:39 Rafał Miłecki wrote: > > W dniu 22 grudnia 2009 02:40 użytkownik Rafał Miłecki > > napisał: > > > It's just compilation-tested as I don't own N-PHY device yet (should > > > receive > > > one for Christmas). Not sure if we even support SSB used for N-PHY cards. > > > > Is posting on this ML enough to get patch in testing and mainline > > later? If it just needs some time, *I am completely fine with it*. > > > > I ask because maybe I'm waiting for something that won't happen due to > > my (some) mistake. Should I do anything else to get this patch > > reviewed & up? > > Send it to John Linville and the linux wireless list. Also CCing this list is > a good idea. Was there a non-whitespace-damaged version of the patch posted? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: Fix regression from Bug #14538
On Mon, Nov 23, 2009 at 01:55:06PM -0600, Larry Finger wrote:
> The routine b43_is_hw_radio_enabled() has long been a problem.
> For PPC architecture with PHY Revision < 3, a read of the register
> B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43_status()
> returns a value of 2 (B43_STAT_STARTED) (BUG 14181). Fixing that
> results in Bug 14538 in which the driver is unable to reassociate
> after resuming from hibernation because b43_status() returns 0.
>
> The correct fix would be to determine why the status is 0; however,
> I have not yet found why that happens. The correct value is found for
> my device, which has PHY revision >= 3.
>
> Returning TRUE when the PHY revision < 3 and b43_status() returns 0 fixes
> the regression for 2.6.32.
>
> Signed-off-by: Larry Finger
> Tested-by: Christian Casteyde
> ---
>
> Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
> ===
> --- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
> +++ wireless-testing/drivers/net/wireless/b43/rfkill.c
> @@ -33,9 +33,16 @@ bool b43_is_hw_radio_enabled(struct b43_
> & B43_MMIO_RADIO_HWENABLED_HI_MASK))
> return 1;
> } else {
> - if (b43_status(dev) >= B43_STAT_STARTED &&
> - b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
> - & B43_MMIO_RADIO_HWENABLED_LO_MASK)
> + /* To prevent CPU fault on PPC, do not read a register
> + * unless the interface is started; however, on resume
> + * for hibernation, this routine is entered early. When
> + * that happens, unconditionally return TRUE.
> + */
> + if (b43_status(dev) >= B43_STAT_STARTED) {
> + if (b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
> + & B43_MMIO_RADIO_HWENABLED_LO_MASK)
> + return 1;
> + } else
> return 1;
> }
> return 0;
Maybe just me, but I think this version is easier to read (and especially to
see the difference):
diff --git a/drivers/net/wireless/b43/rfkill.c
b/drivers/net/wireless/b43/rfkill.c
index ffdce6f..ddc3c93 100644
--- a/drivers/net/wireless/b43/rfkill.c
+++ b/drivers/net/wireless/b43/rfkill.c
@@ -33,8 +33,14 @@ bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
& B43_MMIO_RADIO_HWENABLED_HI_MASK))
return 1;
} else {
- if (b43_status(dev) >= B43_STAT_STARTED &&
- b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
+ /* To prevent CPU fault on PPC, do not read a register
+* unless the interface is started; however, on resume
+* for hibernation, this routine is entered early. When
+* that happens, unconditionally return TRUE.
+*/
+ if (b43_status(dev) < B43_STAT_STARTED)
+ return 1;
+ if (b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
& B43_MMIO_RADIO_HWENABLED_LO_MASK)
return 1;
}
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Enforce DMA descriptor memory constraints
On Thu, Nov 19, 2009 at 05:55:07PM -0600, Larry Finger wrote: > On 11/18/2009 11:21 PM, William Bourque wrote: > > Also, just saying, but it seems Larry's "pm_qos_update_requirement" > > patch had some good effects; I can hardly get any connectivity without > > it. With the patch, the wireless seems to be stable for a few minutes > > before generating DMA errors... without the patch the error start piling > > up as soon the interface get up. > > If the pm_qos patch has some positive benefits, I'll push it; however, I think > this is just a band aid, not a real fix. It also has the bad side effect of > keeping the CPU from going into deep sleep, which increases the power usage > with > reduced battery life. > > John: Any thoughts on this matter? Missing deep sleep is bad. At the very least you need to limit that to devices that truly need it, as Michael suggested. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix Bugzilla #14181 without introducing a new problem
On Fri, Oct 16, 2009 at 08:42:08AM -0500, Larry Finger wrote: > On 10/14/2009 03:06 AM, Michael Buesch wrote: > > On Wednesday 14 October 2009 03:25:30 Larry Finger wrote: > >> Commit 93bad2b757586fb153ef73b028953a8dcaccde77 entitled "b43: Fix PPC > >> crash > >> in rfkill polling on unload" fixed the bug reported in Bugzilla No. 14181; > >> however, it introduced a new bug. Whenever the radio switch was turned off, > >> it was necessary to unload and reload the driver for it to recognize the > >> switch again. > >> > >> I believe this patch fixes the original problem without introducing any new > >> problems. > >> > >> Signed-off-by: Larry Finger > >> --- > >> > As Michael correctly points out, this patch substitutes one bug for > another. The current bug affects every bcm43xx device with an rfkill > switch except BCM4306/3, and the new bug only affects BCM4306/3 users > with a kill switch. As the latter group may be the empty set, I think > the trade-off is worth it. > > An additional complication is that I do not have the hardware to test > the PPC faults. The OP of Bugzilla #14181 has been helpful; however, > if it takes several tries to get a fix, we might miss the 2.6.32 > release, which would introduce a significant regression. > > For the above reasons, I am suggesting that this patch be accepted and > pushed to mainline even though it has faults. Well, hmmm...ok, we have two or three problems here... :-) One is whether or not to take this patch. Normally it is against policy or whatnot to trade one bug for another. In this case, it seems we would fix a real bug in exchange for a theorhetical bug that we believe no one actually has. Is that the case? If so, that might be acceptable. The other problem is a work/patch flow issue. I have occasionally (some would say too often) snagged a patch directly from this list. But in general I have waited for Michael to repost the patches to linux-wireless before merging them. As such, I'm unaccustomed to collecting patches from here. In any event, most patches should be posted to linux-wireless for wider review before merging. That would normally be the maintainer's job, but we are effectively without one for b43 now. I don't suppose anyone wants to stand-up? The third problem (related to the second) is that I missed the original post, so if you don't mind I'd like you to resend it (to linux-wireless)! :-) Thanks, John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: do not stack-allocate pio rx/tx header buffers
On Tue, Oct 06, 2009 at 10:52:15PM +0200, Michael Buesch wrote: > On Tuesday 06 October 2009 18:20:43 Albert Herranz wrote: > > The DMA-API debugging facility complains about b43 mapping memory from > > stack for SDIO-based cards, as can be seen in the following two > > stack traces. > > 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 > 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: [PATCH3]Add analog switch support
On Mon, Sep 14, 2009 at 03:18:24PM -0500, Larry Finger wrote: > Thomas Ilnseher wrote: > > On Mo, 2009-09-14 at 21:43 +0200, Gábor Stefanik wrote: > >> Always send patches to John Linville, and CC linux-wireless. > > Ok, the last try ... > > > > As I've seen Gàbor's patch, I noticed that my previous patch was > > bullshit. This patch should work: > > > > (see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore) > > > > Signed-off-by: Thomas Ilnseher > > > > A few points about patch formatting. > > The subject of the submittal message should be of the form "[PATCH] > component: Description". For this one, something like "[PATCH] b43: > Add LP PHY analog switch support" would be appropriate. If multiple > versions are needed, indicate that a previous one is superceded by > [PATCH V2] ..., etc. > > There should be a line containing --- after the last signed-off-by line. > > Anything between the beginning of the e-mail and the --- line becomes > part of the permanent record if the patch is accepted. Usually quoted > material and words like bullshit are avoided. Not always, but usually. > > Between the --- line and the start of the patch, you can place > instructions to Linville regarding the circumstances of the patch and > its priority. Such directions are useful to distinguish an improvement > that should wait for the next merge period from a bug fix that should > be sent upstream ASAP. In this case, the patch fixes a system crash on > some platforms and should be applied now. Above is a good summary. I usually refer people here (which has mostly the same information): http://linux.yyz.us/patch-format.html Hth! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v2] b43: LP-PHY: Begin implementing calibration & software RFKILL support
On Sun, Aug 30, 2009 at 05:55:40PM +0200, Michael Buesch wrote:
> On Sunday 30 August 2009 17:10:23 Larry Finger wrote:
> > Michael Buesch wrote:
> > > On Sunday 30 August 2009 02:15:55 Gábor Stefanik wrote:
> > >> static void lpphy_pr41573_workaround(struct b43_wldev *dev)
> > >> {
> > >> struct b43_phy_lp *lpphy = dev->phy.lp;
> > >> @@ -1357,28 +1488,440 @@ static void lpphy_pr41573_workaround(struct
> > >> b43_wldev *dev)
> > >> b43_lptab_read_bulk(dev, B43_LPTAB32(7, 0x140),
> > >> saved_tab_size, saved_tab);
> > >> }
> > >> +b43_put_phy_into_reset(dev);
> > >
> > > Are you sure you really want this?
> > > This function completely disables the PHY on the backplane and keeps the
> > > physical
> > > PHY reset pin asserted (even after return from the function).
> > > So the PHY will physically be powered down from this point on. The
> > > following
> > > PHY accesses could even hang the machine, because the PHY won't respond to
> > > register accesses anymore.
> > >
> > > We currently only use this function on A/G Multi-PHY devices to
> > > permanently
> > > hard-disable the PHY that's not used.
> >
> > The PHY reset routine in
> > http://bcm-v4.sipsolutions.net/802.11/PHY/Reset, which I just updated
> > for the latest N PHY changes, appears to be a different routine than
> > b43_put_phy_into_reset(). The names are confusing.
>
> b43_put_phy_into_reset() is opencoded in the specifications in various init
> routines. There's no separate specs page for that function.
> But I think the code is straightforward and easy to understand.
So is this patch right or not? Should I hold onto it for 2.6.33
(i.e. after the 2.6.32 merge window)?
John
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix and update LP-PHY code
On Wed, Aug 26, 2009 at 10:47:12PM +0200, Gábor Stefanik wrote: > 2009/8/26 Michael Buesch : > > And, everything in its own patch, please. I don't see a reason for > > patching unrelated things in one big patch. > > Well, this patch is already in wireless-testing, so doing that would > now involve reverting this patch, applying a version without the > channel change, and applying the channel change - certainly more > confusing than the status quo. But it is not in net-next-2.6. Please submit the patches as Michael requested and I'll take care of the reorganization. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCHv4] b43 add harware tkip
On Fri, Aug 21, 2009 at 11:43:55PM +0200, gregor kowski wrote: > This add hardware tkip for b43. This can help to reduce the load a low > powered router and make higher throughput. To enable it, you need to > set "hwtkip" module param. > > Signed-off-by: Gregor Kowski > Acked-by: Michael Buesch 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: [RESEND] [PATCH] b43 : remove old kidx API
On Mon, Jul 27, 2009 at 10:43:36PM +0200, gregor kowski wrote: > Remove old kidx API. > This simplify the code, and fix a potential key overflow. > > Signed-off-by: Gregor Kowski 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: Implement spec updates and remove resolved FIXMEs
On Thu, Aug 20, 2009 at 12:14:13AM +0200, Gábor Stefanik wrote: > Seeing that this is still not in wireless-testing - this patch should > be applied, the previously mentioned regressions were false alerts > (Larry tested without this patch and with v478 firmware, which worked; > while Mark applied this patch and used v410 firmware, which didn't > work - when Mark upgraded to v478 firmware, his card too came to > life.) So, please apply. You posted the above slightly more than 7 hours after the "false alert" message below. > Date: Wed, 19 Aug 2009 16:57:37 +0200 > From: Gábor Stefanik > To: John Linville , Michael Buesch , > Larry Finger > Cc: Mark Huijgen , > Broadcom Wireless , > linux-wireless > 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: [PATCH] b43: LP-PHY: Fix reading old mode in the set TX power control routine
On Mon, Aug 17, 2009 at 09:33:06PM +0200, Gábor Stefanik wrote: > 2009/8/14 Gábor Stefanik : > > Check the mode the hardware is in, not the mode we used the last time. > > > > Signed-off-by: Gábor Stefanik > > --- > > 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: LP-PHY: Fix setting TX power control mode during RC calibration
On Mon, Aug 17, 2009 at 09:32:42PM +0200, Gábor Stefanik wrote: > 2009/8/14 Gábor Stefanik : > > Call set_tx_power_control with a LPPHY_TXPCTL rather than an > > LPPHY_TX_PWR_CTL_CMD_MODE. > > > > Signed-off-by: Gábor Stefanik > > --- > > This should fix the WARN_ON testers were seeing during init. > > > > drivers/net/wireless/b43/phy_lp.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/net/wireless/b43/phy_lp.c > > b/drivers/net/wireless/b43/phy_lp.c > > index adfa7bf..558224b 100644 > > --- a/drivers/net/wireless/b43/phy_lp.c > > +++ b/drivers/net/wireless/b43/phy_lp.c > > @@ -1080,7 +1080,7 @@ static void lpphy_rev0_1_rc_calib(struct b43_wldev > > *dev) > > old_txpctl = b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_CMD) & > > B43_LPPHY_TX_PWR_CTL_CMD_MODE; > > > > - lpphy_set_tx_power_control(dev, B43_LPPHY_TX_PWR_CTL_CMD_MODE_OFF); > > + lpphy_set_tx_power_control(dev, B43_LPPHY_TXPCTL_OFF); > > lpphy_disable_crs(dev); > > loopback = lpphy_loopback(dev); > > if (loopback == -1) > > -- > > 1.6.2.4 > > > > John, any news on this one? I can't see it in wireless testing. Larry said: With this one, I still get WARNING: at drivers/net/wireless/b43/phy_lp.c:1006 lpphy_set_tx_power_control+0xbf/0xdd [b43](). -- 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: Implement LP-PHY baseband table initialization
On Mon, Aug 10, 2009 at 08:58:44PM +0200, Gábor Stefanik wrote: > 2009/8/10 Larry Finger : > > Gábor Stefanik wrote: > >> Implement LP-PHY baseband table init for all revisions. > >> > >> Signed-off-by: Gábor Stefanik > >> --- > >> Changes from RFC: > >> -Improved table formatting in the code. > >> -The 2GHz check in adjust_gain_table now uses b43_current_band. > >> -Added a comment to rev2plus_table_init about a possible future > >> improvement. > > > > I like the new table formatting. > > > > The comment in rev2plus_table_init has a typo - "ben" should be > > "been". Otherwise it looks good. Thanks for all your work. > > > > Larry > > > > John, can you fix that when checking in, or should I resubmit with the > typo fixed? Sure, fine... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix hardware key index handling
On Thu, Aug 06, 2009 at 10:36:50AM +0200, Michael Buesch wrote: > This fixes the hardware encryption keys index and array size handling. > > Thanks to Gregor Kowski for reporting this issue. > > Signed-off-by: Michael Buesch > > --- > > This should probably go as a bugfix. > (Does this actually fix the PHY transmission errors? I don't see them > anymore... > Note that you need to enable debugging to see them.) It's getting a bit late in the cycle, especially for a patch so large and (at least to me) non-obvious. What is the actual bug being fixed? What is the effect of leaving it for 2.6.32? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] remove wrong probe_resp_plcp write
On Fri, Jul 31, 2009 at 10:38:14PM +0200, Michael Buesch wrote: > On Friday 31 July 2009 22:35:49 gregor kowski wrote: > > The tkip hw support uncovered a bug in b43_write_probe_resp_template : it is > > writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK zone. > > This > > patch comments these writes. > > > > Signed-off-by: Gregor Kowski > > Signed-off-by: Michael Buesch CC [M] drivers/net/wireless/b43/main.o drivers/net/wireless/b43/main.c:1432: warning: ‘b43_write_probe_resp_plcp’ defined but not used Comment it out too? Or are you going to fix the block that has been commented-out here? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ¡Viva Honduras Libre! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Off Subject Question
On Mon, Jul 13, 2009 at 12:48:29PM -0700, Luis R. Rodriguez wrote: > On Mon, Jul 13, 2009 at 12:41 PM, Michael Buesch 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: Fwd: 4318 misbehaving with bleeding edge kernels
On Fri, Jul 10, 2009 at 10:59:46AM -0400, Pavel Roskin wrote: > On Fri, 2009-07-10 at 11:31 +0200, Michael Buesch wrote: > > > I have a 4318 (rev 02), which has been working fine with b43. > > Recently, with 2.6.31-rc2 kernels from the wireless-testing git repo, > > I've been having trouble. Sometimes the card simply fails to associate > > after doing 'iwconfig eth0 essid '. It doesn't even seem to try; > > i.e., when it does associate, I see log entries like these: > > I believe is that the ESSID support in the wext compatibility layer is > seriously broken. It's not shown originally at all. Once it's set, it > cannot be changed. What kernel are you using? I don't see this behavior... 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: [PATCH] b43: Fix possible unaligned u32 access
On Fri, Jun 05, 2009 at 02:53:07PM -0400, John W. Linville wrote: > On Fri, Jun 05, 2009 at 05:03:57PM +0200, castet.matth...@free.fr wrote: > > Quoting "John W. Linville" : > > > > > On Thu, Jun 04, 2009 at 11:18:33PM +0200, Michael Buesch wrote: > > > > From: Matthieu CASTET > > > > > > > > Fix possible unaligned u32 access in b43_generate_plcp_hdr(). > > > > Unaligned data is read/write with a u32 pointer instead of using the > > > > packed structure. Some versions of gcc ignore the "packed" attribute, if > > > the > > > > structure element is accessed through a local pointer. > > > > > > > > Signed-off-by: Matthieu CASTET > > > > Signed-off-by: Michael Buesch > > > > > > That seems pretty brain-dead...can you cite a source for this > > > information? > > The test I did with the attached test case in the first post. > > Link? > > > I don't see why gcc should propagate packed structure info to assignment. > > That will be impossible to handle (think of passing it to function > > parameter). > > Perhaps this is obvious to you, but it isn't to me. OK, I got an explanation from Kyle McMartin that I grok... > > > > > The patch seems like a no-op... > > At least the code produced on mips is different. > > Then why aren't you trying to get the mips gcc guys to fix it? Still worth wondering...anyway, the patch is fine -- I just didn't grok the explanation. 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 possible unaligned u32 access
On Fri, Jun 05, 2009 at 05:03:57PM +0200, castet.matth...@free.fr wrote: > Quoting "John W. Linville" : > > > On Thu, Jun 04, 2009 at 11:18:33PM +0200, Michael Buesch wrote: > > > From: Matthieu CASTET > > > > > > Fix possible unaligned u32 access in b43_generate_plcp_hdr(). > > > Unaligned data is read/write with a u32 pointer instead of using the > > > packed structure. Some versions of gcc ignore the "packed" attribute, if > > the > > > structure element is accessed through a local pointer. > > > > > > Signed-off-by: Matthieu CASTET > > > Signed-off-by: Michael Buesch > > > > That seems pretty brain-dead...can you cite a source for this > > information? > The test I did with the attached test case in the first post. Link? > I don't see why gcc should propagate packed structure info to assignment. > That will be impossible to handle (think of passing it to function parameter). Perhaps this is obvious to you, but it isn't to me. > > > The patch seems like a no-op... > At least the code produced on mips is different. Then why aren't you trying to get the mips gcc guys to fix it? 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 possible unaligned u32 access
On Fri, Jun 05, 2009 at 07:29:07PM +0200, Michael Buesch wrote:
> On Friday 05 June 2009 14:25:03 John W. Linville wrote:
> > On Thu, Jun 04, 2009 at 11:18:33PM +0200, Michael Buesch wrote:
> > > From: Matthieu CASTET
> > >
> > > Fix possible unaligned u32 access in b43_generate_plcp_hdr().
> > > Unaligned data is read/write with a u32 pointer instead of using the
> > > packed structure. Some versions of gcc ignore the "packed" attribute, if
> > > the
> > > structure element is accessed through a local pointer.
> > >
> > > Signed-off-by: Matthieu CASTET
> > > Signed-off-by: Michael Buesch
> >
> > That seems pretty brain-dead...can you cite a source for this
> > information? The patch seems like a no-op...
> >
> > John
>
> struct foo {
> int data;
> } __attribute__((packed));
>
> struct foo foo;
> int *d = &foo->data;
> foo->data = x;/* Works for unaligned */
> *d = y; /* Does not work for unaligned */
Why not?
--
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 possible unaligned u32 access
On Thu, Jun 04, 2009 at 11:18:33PM +0200, Michael Buesch wrote: > From: Matthieu CASTET > > Fix possible unaligned u32 access in b43_generate_plcp_hdr(). > Unaligned data is read/write with a u32 pointer instead of using the > packed structure. Some versions of gcc ignore the "packed" attribute, if the > structure element is accessed through a local pointer. > > Signed-off-by: Matthieu CASTET > Signed-off-by: Michael Buesch That seems pretty brain-dead...can you cite a source for this information? The patch seems like a no-op... 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/2 V2] b43legacy: Fix locking problem
On Fri, May 15, 2009 at 03:39:34PM -0500, Larry Finger wrote: > Commit abb1d2bca0fc429c136747a64e675dd4d8906f36 introduced a locking > problem in b43legacy that caused the system to freeze upon booting. > > Signed-off-by: Larry fin...@lwfinger.net > --- > > John, > > This is 2.6.31 material. I hope that you do not have trouble with > this patch. While on the road, my normal method is not available. > > This is resent as V2 to eliminate some patch offsets that resulted > from the changes in V2 of patch 1. > > Larry This conflicted w/ a patch from Johannes, and I couldn't easily figure-out how to resolve them. Since his claimed to fix something else along with this problem, I just applied his. Also, please don't refer to commit IDs directly, especially ones that aren't already in linux-2.6. Instead, please refer to the patch subject. If the commit is already in linux-2.6, then a short reference to the commit ID is acceptable. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Wed, Jan 14, 2009 at 09:45:22PM +0100, Johannes Berg wrote: > > > Initvals and new firmware version can be found at > > http://www.ing.unibs.it/openfwwf > > I suggest that before this is packaged, we change it so b43 can > recognise it and automatically disable qos and hwcrypto. That's a good idea. Is that simply a driver patch? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Wed, Jan 14, 2009 at 04:30:47PM +0100, Lorenzo Nava wrote: > Hello everybody, > > we completed the 1st version of initvals. They are available at > http://www.ing.unibs.it/openfwwf > . Currently only binary version is available: don't worry, we will > publish source code as soon as possible!! This first version is a > "test version": please try it and let us know if everythink is ok... > > Today we have also tested a new firmware version that works with WPA2- > personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested > on 4306 and 4318 PCI device). If anybody was interested please try new > firmware with encryption and let us know if it works correctly, thanks! > > Initvals and new firmware version can be found at > http://www.ing.unibs.it/openfwwf Awesome...awesome...awesome!!! -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [b43] opensource firmware
On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote: > Hello everybody, > > today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with > Broadcom 4306 chipset: > > BCM94306 802.11g (rev 03) > PHY: Analog 2, Type 2, Revision 2 > Radio: Manuf 0x17F, Version 0x2050, Revision 2 > > I did some tests and everything seems to work fine. > > I remember, once again, that OpenFWWF needs v480 initvals to work > properly, and was tested on 2.6.27-rc5 kernel. Any chance on getting a set of initvals packaged with the open source firmware? That would allow distros like Fedora to package this... John -- John W. LinvilleLinux should be at the core linvi...@tuxdriver.com of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware
On Fri, Jan 09, 2009 at 09:21:52AM +0100, Francesco Gringoli wrote: > we have been involved in the past few months in testing modifications > to the standard 802.11 MAC for research purposes. During this time we > did some tests with Broadcom 802.11b/g boards and we wrote down a > simple 802.11 compliant firmware that we used as a starting point for > the modified MAC algorithms. > The firmware along with the instructions to build it from the assembly > code using the tools developed by the b43 community can be found here > > http://www.ing.unibs.it/openfwwf > > In the firmware website you can find more information about the fw > algorithm, its interaction with Broadcom hardware and other > information that we discovered as we were writing it. I hereby declare this to be Fully Awesome! (TM) John -- John W. LinvilleLinux should be at the core linvi...@tuxdriver.com of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
On Thu, Dec 11, 2008 at 10:28:19PM -0600, Larry Finger wrote: > Matthew Garrett wrote: > > I've reworked the rfkill code in b43. This ought to be more consistent > > with the other drivers and it seems to work on the machines I've tested > > it on here, but it'd be good to get some feedback. > > How does this look to people? > > All this discussion about hard vs soft rfkill makes my head hurt and I have > stopped reading those posts. > > Correction to my earlier post. If the system is booted with the RF switch off, > the LED is on, whereas it should be off. The original code works correctly. Based on the above, I'm dropping this patch. Please submit a non-regressing version! :-) John -- John W. LinvilleLinux should be at the core linvi...@tuxdriver.com of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: B43 STILL randomly and silently dropping connections...
I've seen this message a couple of times -- I'm a bit surprised that you haven't been getting a response. I am Cc'ing Michael and the bcm43xx mailing list just in case they haven't noticed this message. John On Wed, Oct 22, 2008 at 06:48:55AM -0400, Jerry McBride wrote: > > The story is... > > I've moved from 2.6.25.x using BCM43XX with a Broadcom 4306 (rev3) 802.11 > chipset to 2.6.26.6 using the B43 and appropriate firmware. This on a COMPAQ > Presario R3000 P4 and a gig of memory and ATI graphics. > > I followed the install (upgrade) directions at linuxwireless.org. Piece of > cake! However... I find that I've gone from "bulletproof" BCM43XX wifi > connections to "bullethole" connections with B43. > > Under the old BCM43XX the handshake and connections were flawless and > unfaltering. Now with the new B43, handshakes with AP's are perfect, but the > connections randomly and silently fail. There are no debug messages, no > complaints what-so-ever in /var/log/messages... > > To gt wireless back, I have to reinitialize the connection. I've gotten so > good at it, that I can recite by heart the appropriate commands... > > It's killling me! I've got to get this ironed out... it's not just my laptop, > it's happening quite regularly with people I know with similar chips and > laptops. > > Trying 2.6.27-rc's and now 2.6.27 and the situation is no better. > > So I ask... Who is the B43/B43LEGACY maintainer and would you be interested > in > debugging this mess? I'll bend over backward to help you... Email me > direct... I'm very willing. > > SHORT STORY: > -- Kernel 2.6.25.x with BCM43XX, firmware 4.80.53.0.. just perfect. > > -- Kernels 2.6.26 or higher with B43 and firware 4.150.10.5 good > negotiations, > but fragile connections that drop randomly and without complaint. B43LEGACY > does nothing. > > Any help would be appreciated. I'd really like to get this ironed out. I > highly desire to use current kernels. > > Feel free to email me direct. > > -- > > * > > From the desk of: > Jerome D. McBride > >19:17:28 up 15 days, 23:35, 5 users, load average: 0.33, 0.11, 0.03 > > ***** > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- John W. LinvilleLinux should be at the core [EMAIL PROTECTED] of your literate lifestyle. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Can't connect to AP with hidden essid with 2.6.27-rc6
On Thu, Sep 18, 2008 at 07:26:57AM -0500, Larry Finger wrote: > > $ bin/iw dev wmaster0 info > > Band 1: > > Frequencies: > > * 2412 MHz (passive scanning, no IBSS) > > * 2417 MHz (passive scanning, no IBSS) > > * 2422 MHz (passive scanning, no IBSS) > > * 2427 MHz (passive scanning, no IBSS) > > * 2432 MHz (passive scanning, no IBSS) > > * 2437 MHz (passive scanning, no IBSS) > > * 2442 MHz (passive scanning, no IBSS) > > * 2447 MHz (passive scanning, no IBSS) > > * 2452 MHz (passive scanning, no IBSS) > > * 2457 MHz (passive scanning, no IBSS) > > * 2462 MHz (passive scanning, no IBSS) > > It is the passive scanning that is killing you. For hidden essid, you > need an active scan. You need to implement the CRDA > (http://linuxwireless.org/en/developers/Regulatory/CRDA), which will > get your system to provide active scanning. Hmmm...does the user have CONFIG_WIRELESS_OLD_REGULATORY=y? That is supposed to enable identical behavior to what we had before w/o requiring CRDA. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f
On Wed, Sep 17, 2008 at 04:26:28PM +0200, Michael Buesch wrote: > On Wednesday 17 September 2008 00:37:29 Henrique de Moraes Holschuh wrote: > > On Tue, 16 Sep 2008, Michael Buesch wrote: > > > But I don't know how to tell the rfkill subsystem about the states and > > > > rfkill_force_state(). Must NOT be called from within atomic contextes, > > something I haven't got around to find a proper way of fixing, and nobody > > else seems to be on a rfkill coding frenzy right now. > > That's a showstopper for us, as we have to change the state from > within an interrupt tasklet. Workqueue? -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f
On Tue, Sep 16, 2008 at 09:52:12PM -0500, Larry Finger wrote: > I admit that I never tested any of the RFKILL patches as they went in. > One of the reasons is that the development process seemed rather > untidy to an outsider, and I wasn't sure that any of the code would > ever be in the kernel. As such, it snuck up on me. I'll not let that > happen again. After the reversion, I will again test any suggested > code changes, but do not expect me to work out any of the changes. I > have enough to do. FWIW, Henrique has been very persistant with driving rfkill. He has posted and reposted his patch series many times. I'm sorry that it snuck-up on you but it was on the list for quite a while. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
On Wed, Sep 10, 2008 at 12:40:44AM -0600, Otto Solares wrote: > On Mon, Sep 08, 2008 at 04:54:59PM -0400, John W. Linville wrote: > > On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote: > > > Greg KH wrote: > > >> > > >> Bug fixes, not new features, it's pretty simple :) > > > > > > Just bug fixes, or does it have to be a regression? > > > > As I understand it, the rule is more like "bug fixes that are committed > > in the linux-2.6 tree". Since Linus has become more strict about > > requiring "regressions only" after the merge window, that effectively > > enforces the "regressions only" rule on the -stable trees as well. > > In this case that rule is harming, is not idiotic to not accept bug > fixes early or later? I'm just the messenger...FWIW the argument is that even a "fix" can introduce a new "bug" somewhere else, often quite unexpectedly. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote: > Greg KH wrote: >> >> Bug fixes, not new features, it's pretty simple :) > > Just bug fixes, or does it have to be a regression? As I understand it, the rule is more like "bug fixes that are committed in the linux-2.6 tree". Since Linus has become more strict about requiring "regressions only" after the merge window, that effectively enforces the "regressions only" rule on the -stable trees as well. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, Sep 06, 2008 at 08:41:05PM +0200, Michael Buesch wrote: > On Saturday 06 September 2008 20:34:02 Larry Finger wrote: > > A coding error present since b43legacy was incorporated into the > > kernel has prevented the driver from using the rate-setting mechanism > > of mac80211. The driver has been forced to remain at a 1 Mb/s rate. > > Does version3 firmware have a different bitlayout for the status? > > > Although this is not strictly a regression, it is a bug. I hope > > it can be sent to 2.6.27. > > The new rules don't allow us to fix bugs after the merge window. > Only regressions. I imagine the powers that be would claim it isn't a new rule, but it is a new enforcement policy... John ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Regression (FC8 to FC9)
On Wed, Jun 25, 2008 at 12:26:05PM -0400, Pavel Roskin wrote: > On Wed, 2008-06-25 at 11:06 -0400, Frank Middleton wrote: > > > Updated FC8 kernel that worked fine 2.6.25.6-27.fc8 > > FC9 kernel (that has the regression) 2.6.25.6-55.fc9.x86_64 > > I would probably try to bisect it. I realize that it's a lot of work. > > The breakage is caused either by patches or by configuration changes. > Finding out is the first step. Then look for the patch or for > configuration change that affects the problem. Sorry I missed the original post -- my reply is really to the OP rather than to Pavel. It would probably be better to report Fedora distribution problems on Fedora lists rather than the general upstream lists. That said, since -27.fc8 is working for you, you should probably try the -fc9 kernel built on the same date: http://koji.fedoraproject.org/koji/buildinfo?buildID=52606 Perhaps it isn't obvious, but not every F9 kernel is newer than every F8 kernel. Hth! 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 stable] b43: Fix possible NULL pointer dereference in DMA code
On Sat, Jun 14, 2008 at 10:57:55PM +0200, Michael Buesch wrote: > This fixes a possible NULL pointer dereference in an error path of the > DMA allocation error checking code. In case the DMA allocation address is > invalid, > the dev pointer is dereferenced for unmapping of the buffer. > > This is a cut-down version of 3ab4b64c46784ed83f213bf4e1b51d9c55858600 > which is upstream in John Linville's wireless-testing.git tree. ...which will probably be 028118a5f09a9c807e6b43e2231efdff9f224c74 in linux-2.6.git John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH stable] b43: Fix noise calculation WARN_ON
On Sat, Jun 14, 2008 at 11:00:14PM +0200, Michael Buesch wrote: > This removes a WARN_ON that is responsible for the following koops: > http://www.kerneloops.org/searchweek.php?search=b43_generate_noise_sample > > The comment in the patch describes why it's safe to simply remove > the check. > > This patch is upstream in John Linville's wireless-testing.git tree > as commit 86ef1ae07289c9f0aa1aa310d43653e513e6f124 ...and will probably be 98a3b2fe435ae76170936c14f5c9e6a87548e3ef in linux-2.6.git. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [stable] [PATCH stable] b43: Fix controller restart crash
On Fri, Jun 06, 2008 at 07:55:27PM +0200, Michael Buesch wrote: > On Friday 06 June 2008 19:32:23 Chris Wright wrote: > > * Michael Buesch ([EMAIL PROTECTED]) wrote: > > > This fixes a kernel crash on rmmod, in the case where the controller > > > was restarted before doing the rmmod. > > > > > > Upstream commit is 4735f5022c97f6624ced2ec5056c61c4b437d53b > > > > This is not in Linus' tree. Where is this upstream commit? > > John Linville's wireless tree. That's upstream from my point of view. :P :-) The commit ID may have gotten shuffled when Dave M. rebased net-2.6. It is in 2.6.26-rc5 as commit 3bf0a32e22fedc0b46443699db2d61ac2a883ac4. Hth! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix controller restart crash
On Thu, May 22, 2008 at 05:06:36PM +0200, Michael Buesch wrote: > This fixes a kernel crash on rmmod, in the case where the controller > was restarted before doing the rmmod. > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > --- > > Stefano, this is untested. Please test by doing > echo -n 1 >/debug/b43legacy/phy*/restart > rmmod b43legacy > It should not crash anymore at the rmmod (actually the restart should > also hang in b43legacy, as it has a deadlock, which this patch also fixes). Anyone get a chance to test this one? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix typo in firmware file name for 802.11 cores with rev 13
On Thu, May 15, 2008 at 02:07:36PM -0500, [EMAIL PROTECTED] wrote: > When the patch for the BCM4311 rev 2 was prepared, I misread the specs > and coded the wrong file name for the initvals firmware. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > John, > > This is 2.6.27 material. Although it is a bug in 2.6.25 and .26, it > seems to have zero effect on the performance of the device and can > be delayed. Would you prefer to have it in 2.6.26 "just in case"? Or might that cause a problem somehow? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [patch 11/16] b43: Fix some TX/RX locking issues
On Thu, May 08, 2008 at 10:42:21AM -0700, Greg KH wrote: > 2.6.25-stable review patch. If anyone has any objections, please let us > know. > > -- > From: Michael Buesch <[EMAIL PROTECTED]> > > commit 21a75d7788f4e29b6c6d28e08f9f0310c4de828d upstream. > > This fixes some TX/RX related locking issues. > With this patch applied, some of the PHY transmission errors are fixed. ACK -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [patch 08/16] b43: Fix dual-PHY devices
On Thu, May 08, 2008 at 10:42:14AM -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 2e35af143a1380173ba292e48e9b4913ef16b4ee upstream > > This fixes operation of dual-PHY (A/B/G) devices. > Do not anounce the A-PHY to mac80211, as that's not supported, yet. > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > Signed-off-by: John W. Linville <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> ACK -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix some TX/RX locking issues
On Thu, May 01, 2008 at 12:08:10PM +0200, Michael Buesch wrote: > John, did you drop this patch? I can't see it in git and your latest push, > while a patch submitted later is in there. No, I'm sorry. I fat-fingered my patches. I've still got it, and it will go in the next round. John > On Friday 25 April 2008, Michael Buesch wrote: > > This fixes some TX/RX related locking issues. > > With this patch applied, some of the PHY transmission errors are fixed. > > > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > > > --- > > > > John, this is for 2.6.26. -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 sysfs interface
On Wed, Apr 16, 2008 at 05:13:08PM +0200, Michael Buesch wrote: > On Wednesday 16 April 2008 16:50:15 Johannes Berg wrote: > > On Wed, 2008-04-16 at 14:06 +0200, Stefanik Gábor wrote: > > > My recommendations: nl80211 or nlconfig, since it controls NL80211. > > > Also, the syntax "nl80211 --add --master=wmaster0 --mode=monitor > > > mon0" (or, using short parameters, "nlconfig -a -m=monitor -p=wmaster0 > > > mon0" - "-a" for an alias of "--add", "-m" for "--mode" and "-p" for > > > "--master") would be much better than the current one. (This is pretty > > > similar to kexec's or aircrack-ng's syntax, and is used by many other > > > commands.) > > > > I accept patches but I'd *much* rather have a syntax like the "ip" tool. > > Yeah, me too. But the current iw syntax is just really confusing. :) > I guess there's room for improving it. > But the tool name "iw" is just fine, IMO. Less to type = better. Could we make it reference the wiphy instead of the wmaster? I still hold-out some hope of making wmaster go away eventually... -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb-pcmcia: IRQ and DMA related fixes
On Fri, Mar 28, 2008 at 10:34:55AM +0100, Michael Buesch wrote: > Here come some IRQ and DMA related fixes for the ssb PCMCIA-host code. > Not much to say, actually. I think the patch explains itself. > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > --- > > For 2.6.25 This seems to build upon these two patches: commit e7ec2e3230633a858af1b0b359f6c4670dbeb997 Author: Michael Buesch <[EMAIL PROTECTED]> Date: Mon Mar 10 17:26:32 2008 +0100 ssb: Add SPROM/invariants support for PCMCIA devices This adds support for reading/writing the SPROM invariants for PCMCIA based devices. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Signed-off-by: John W. Linville <[EMAIL PROTECTED]> commit ffc7689ddae5cbe12bde437ae0f2b386d568b5cd Author: Michael Buesch <[EMAIL PROTECTED]> Date: Wed Feb 20 19:08:10 2008 +0100 ssb: Add support for 8bit register access This adds support for 8bit wide register reads/writes. This is needed in order to support the gigabit ethernet core. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Signed-off-by: John W. Linville <[EMAIL PROTECTED]> Those are not in 2.6.25. Is 2.6.26 OK for this one? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Asus WL-138G V2 (BCM4318 non-E rev02) scans but doesn't associate using b43 driver, works with bcm43xx
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
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: bcm4311 + 2.6.24 + patch gives blinking wireless LED
On Fri, Mar 14, 2008 at 05:26:57PM +0530, Abhijit Hoskeri wrote: > [EMAIL PROTECTED]:~/src/wireless-testing$ git checkout --track -b > everything origin/everything > git checkout: updating paths is incompatible with switching > branches/forcing > Did you intend to checkout 'origin/everything' which can not be resolved > as commit? This was the old practice from before the latest tree organization (mid-February). > I am sorry, I do not know enough about git yet to guess what the correct > incantation should be. > > Anyway I just did a git-pull and got 2.6.25-rc5-wl. I have built it but not > had > opportunity to test it yet. Is this new enough to work? This is exactly what you want. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: iwlist shows one AP few times
ESSID:"NTC_03"
Mode:Master
Channel:11
Frequency:2.462 GHz (Channel 11)
Quality=31/100 Signal level=-86 dBm Noise level=-72 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
Extra:tsf=00c4357e0181
Cell 03 - Address: 00:18:39:DD:EE:78
ESSID:""
Mode:Master
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=65/100 Signal level=-50 dBm Noise level=-72 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Preauthentication Supported
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=001447c32e34
Cell 04 - Address: 00:18:39:DD:EE:78
ESSID:""
Mode:Master
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=65/100 Signal level=-50 dBm Noise level=-72 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Preauthentication Supported
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=001447c239ef
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Remove PIO support
On Wed, Jan 09, 2008 at 06:58:12PM +0100, Johannes Berg wrote: > John, > > On Wed, 2007-12-26 at 14:41 +0100, Michael Buesch wrote: > > Remove b43 PIO support. > > DMA works well on all supported devices. There's no reason to use PIO. > > Additionally, new devices don't support PIO in hardware anymore. > > b43 PIO support is dead and unused code. > > You merged this patch, but > > > After applying this patch please do > > git rm drivers/net/wireless/b43/pio.h > > git rm drivers/net/wireless/b43/pio.c > > to remove the main PIO support code. > > forgot this. You're right -- thanks for the reminder! -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On 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: b43 will need a firmware upgrade soon
On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote: > On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: > > Quoting Michael Buesch <[EMAIL PROTECTED]>: > > > > > see "fwpostfix" module parameter > > > > Can we please avoid this annoyance this time? > > Go and complain at Broadcom please. Broadcom doesn't really have this problem, since they are free to include the binary firmware in their Windows/Mac/whatever drivers. If the driver needs different firmware, why not have it ask for different filenames? As I suggested elsewhere, this could be as simple as setting a default value for fwpostfix... John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sun, Jan 06, 2008 at 09:58:22PM +0100, Michael Buesch wrote: > On Sunday 06 January 2008 21:05:23 Hendrik Sattler wrote: > > Do these firmware files go to a different directory then? I would like to > > run > > my current kernel (b43 from git or 2.6.24) and the new one without having > > to > > exchange files every time I boot another kernel version. > > And yes, WLAN is my _only_ connection to the internet. > > see "fwpostfix" module parameter Ugh...that works but is a bit ugly. Is there any way we can version these firmware ABIs? I guess it might be as simple as simply setting a default fwpostfix value... John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Sun, Jan 06, 2008 at 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: Lost wireless device?
On Mon, Dec 17, 2007 at 10:39:45PM -0600, John Pierce wrote: > Larry, I know I am waking up an old thread, but I have a development I > thought was interesting and I need some guidance. > > This device: > > 03:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 > WLAN Mini-PCI Card (rev 01) > > quit showing up in fedora 7 and never appeared in fedora 8, however, I > just installed opensuse 10.3 on the second drive and it > has reappeared. > > I did the standard update after the initial install and it disappeared again. If the device does not show-up for lspci then it is probably not a driver issue. I would suspect a changed BIOS setting but you didn't mention the BIOS in between your various kernels so that seems unlikely. The only thing that leaves that I can conjur at the moment is an ACPI problem -- probably bad ACPI code in your BIOS but possibly a bug in the Linux ACPI interpreter. If you boot with "acpi=off" on the kernel command line, does the device either always show-up or never show-up between the various kernels? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: > On Friday, 14 of December 2007, Michael Buesch wrote: > > Either distributions have to install it automatically or people simply have > > to read one or two lines of documentation. That's just what I wanted to > > say. > > It's not that simple. For example, regression testing will be a major PITA > if one needs to switch back and forth from the new driver to the old one in > the > process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. Given a functioning udev configuration, the persistent naming even works so that your device stays as 'eth1' when switching to and fro bcm43xx. I really think everyone is overstating the problem. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote: > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > Oh come on. b43 is more than a year old now. How long should we wait? > > Two or three? Forever? > > possibly forever, if you dont get obvious regressions like "my wlan does > not work" (reported in this very thread), resolved. Pushing the blame to > udev (in a rather unfriendly way) wont give users a working system and > wont get you many new testers for the new driver either. It is true that Michael can be a little unpleasant at times. The colloquialism that comes to mind is that he "does not suffer fools lightly". Hopefully he will take your counseling to heart and learn to be a bit more moderate in his tone. FWIW, he is still young. :-) That said, it is also true that the b43[legacy] driver[s] do a more than adequate job of replacing the old bcm43xx driver provided that one (re-)installs the proper firmware. And I know of no other driver that goes to more trouble to tell you how to get the proper firmware installed than this one. The bcm43xx driver will be added to the feature removal schedule in 2.6.25. Proper judgment will be used in deciding the actual date of its removal. In the meantime hopefully every distribution will have or obtain a working udev configuration. If things don't work out as planned then we will re-evaluate. Let's stop this now please. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: My Laptop
On Wed, Dec 12, 2007 at 11:12:58PM -0500, Matthew Saltzman wrote: > > On Wed, 2007-12-12 at 17:00 -0500, Stuart D. Gathman wrote: > > On Wed, 12 Dec 2007, Larry Finger wrote: > > > > > Stuart D. Gathman wrote: > > >> , but I got kernel exceptions, DMA exception, and eventually the > > >> system froze. I would say it is not ready for prime time. (I will be > > >> looking for where to helpfully report the exceptions for those trying to > > >> debug the thing. I suspect donations of relevant hardware are most > > >> useful.) No problems with the zd1211 driver and USB key. > > > > > > I'm sorry that you had troubles with the BCM94311MCG in your laptop, but > > > I > > > think most of your problems are fixed in driver b43 in any of the > > > 2.6.24-rcX > > > kernels. In any case, the place to report such problems is > > > [EMAIL PROTECTED] > > > > FC8 has 2.6.23. I suppose FC9 might do the trick. Or maybe they'll > > backport > > some fixes. > > Fedora generally releases kernel updates fairly quickly to track > upstream (though they have patches to port forward before they are > ready). There's no 2.6.24 in updates-testing yet, however. > kernel-2.6.23.9-85 is there. Are you looking for wireless patches? At this moment there are no wireless bits in wireless-2.6 that are not in the latest Fedora kernels in Koji. The last one I built is here: http://koji.fedoraproject.org/koji/buildinfo?buildID=27585 Hth! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
On Thu, Nov 22, 2007 at 02:05:52PM +0100, Johannes Berg wrote: > > Note that the same happens if I let Debian manage the card. An excerpt > > from my /etc/network/interfaces shows: > > That sucks, I guess debian's scripts need to be fixed. As it stands, setting the SSID is the closest thing we have to an "associate now" trigger. I would have to advise distros and users to always set it last in the wireless init, just before running dhclient or whatever. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] softmac: mark as obsolete and schedule for removal
Schedule softmac for for removal in the 2.6.26 development window. Signed-off-by: John W. Linville <[EMAIL PROTECTED]> --- Documentation/feature-removal-schedule.txt |8 net/ieee80211/Kconfig |5 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c057e36..aeaa129 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -342,3 +342,11 @@ Why: This driver's functionality has been replaced by the Who: John W. Linville <[EMAIL PROTECTED]> --- + +What: iee80211 softmac wireless networking component +When: 2.6.26 (or after removal of bcm43xx and port of zd1211rw to mac80211) +Files: net/ieee80211/softmac +Why: No in-kernel drivers will depend on it any longer. +Who: John W. Linville <[EMAIL PROTECTED]> + +--- diff --git a/net/ieee80211/Kconfig b/net/ieee80211/Kconfig index 1438ade..bd50104 100644 --- a/net/ieee80211/Kconfig +++ b/net/ieee80211/Kconfig @@ -1,8 +1,9 @@ config IEEE80211 - tristate "Generic IEEE 802.11 Networking Stack" + tristate "Generic IEEE 802.11 Networking Stack (DEPRECATED)" ---help--- This option enables the hardware independent IEEE 802.11 - networking stack. + networking stack. This component is deprecated in favor of the + mac80211 component. config IEEE80211_DEBUG bool "Enable full debugging output" -- 1.5.3.3 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Request for information regarding BCM94311MCG rev 02
On Wed, Nov 21, 2007 at 10:59:48AM -0600, Larry Finger wrote:
> Johannes Berg wrote:
> >
> > Maybe the card can't handle high addresses for the buffers or we're
> > doing something wrong with the address (extension) here?
>
> On a whim, I decided to look at the latest version of ndiswrapper, and found
> this code snippet:
>
> #ifdef CONFIG_X86_64
> /* 64-bit broadcom driver doesn't work if DMA is allocated
> * from over 1GB */
> if (wd->vendor == 0x14e4) {
> if (pci_set_dma_mask(pdev, DMA_30BIT_MASK) ||
> pci_set_consistent_dma_mask(pdev, DMA_30BIT_MASK))
> WARNING("couldn't set DMA mask; this driver "
> "may not work with more than 1GB RAM");
> }
> #endif
>
> This makes it look more-and-more like a design problem with the hardware.
Crap...surely they have resolved this in newer hardware?
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH v2] bcm43xx: mark as obsolete and schedule for removal
Signed-off-by: John W. Linville <[EMAIL PROTECTED]> --- Amended based on suggestions from Stefano... Documentation/feature-removal-schedule.txt |9 + MAINTAINERS|2 +- drivers/net/wireless/bcm43xx/Kconfig |9 ++--- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 20c4c8b..c057e36 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -333,3 +333,12 @@ Why: This driver has been marked obsolete for many years. Who: Stephen Hemminger <[EMAIL PROTECTED]> --- + +What: bcm43xx wireless network driver +When: 2.6.26 +Files: drivers/net/wireless/bcm43xx +Why: This driver's functionality has been replaced by the + mac80211-based b43 and b43legacy drivers. +Who: John W. Linville <[EMAIL PROTECTED]> + +--- diff --git a/MAINTAINERS b/MAINTAINERS index 18b7c8e..2bfc23f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -828,7 +828,7 @@ P: Stefano Brivio M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://bcm43xx.berlios.de/ -S: Maintained +S: Obsolete BEFS FILE SYSTEM P: Sergey S. Kostyliov diff --git a/drivers/net/wireless/bcm43xx/Kconfig b/drivers/net/wireless/bcm43xx/Kconfig index ce397e4..0159701 100644 --- a/drivers/net/wireless/bcm43xx/Kconfig +++ b/drivers/net/wireless/bcm43xx/Kconfig @@ -1,12 +1,15 @@ config BCM43XX - tristate "Broadcom BCM43xx wireless support" + tristate "Broadcom BCM43xx wireless support (DEPRECATED)" depends on PCI && IEEE80211 && IEEE80211_SOFTMAC && WLAN_80211 && EXPERIMENTAL select WIRELESS_EXT select FW_LOADER select HW_RANDOM ---help--- - This is an experimental driver for the Broadcom 43xx wireless chip, - found in the Apple Airport Extreme and various other devices. + This is an experimental driver for the Broadcom 43xx wireless + chip, found in the Apple Airport Extreme and various other + devices. This driver is deprecated and will be removed + from the kernel in the near future. It has been replaced + by the b43 and b43legacy drivers. config BCM43XX_DEBUG bool "Broadcom BCM43xx debugging (RECOMMENDED)" -- 1.5.3.3 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] bcm43xx: mark as obsolete and schedule for removal
Signed-off-by: John W. Linville <[EMAIL PROTECTED]> --- Documentation/feature-removal-schedule.txt |9 + MAINTAINERS|2 +- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 20c4c8b..c057e36 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -333,3 +333,12 @@ Why: This driver has been marked obsolete for many years. Who: Stephen Hemminger <[EMAIL PROTECTED]> --- + +What: bcm43xx wireless network driver +When: 2.6.26 +Files: drivers/net/wireless/bcm43xx +Why: This driver's functionality has been replaced by the + mac80211-based b43 and b43legacy drivers. +Who: John W. Linville <[EMAIL PROTECTED]> + +--- diff --git a/MAINTAINERS b/MAINTAINERS index 18b7c8e..2bfc23f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -828,7 +828,7 @@ P: Stefano Brivio M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://bcm43xx.berlios.de/ -S: Maintained +S: Obsolete BEFS FILE SYSTEM P: Sergey S. Kostyliov -- 1.5.3.3 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
schedule bcm43xx removal for 2.6.26 -- Re: [PATCH v3] remove bcm43xx
On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote: > On Tuesday, 20 of November 2007, Michael Buesch wrote: > > It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to > > replace bcm43xx. And we already do a parrallel release cycle with both > > drivers > > included so people can switch. What else do you want? > > _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more. > Perhaps there's someone who'd be willing to maintain it. Otherwise, it will > be > dropped anyway after some time - when no one uses it any more. Still, it need > not be (and IMHO it shouldn't be) your decision to drop it. It is probably true that we haven't communicated this very well outside the wireless team. We probably should have added bcm43xx to the feature removal schedule before the 2.6.24 merge window closed. How about if we mark bcm43xx as "Obsolete" in MAINTAINERS and add an entry to Documentation/feature-removal-schedule.txt with a "When" of 2.6.26? I think that should give everyone sufficient notice...? John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix compilation errors in ssb
On Fri, Nov 16, 2007 at 08:21:43AM -0600, Larry Finger wrote: > Michael Buesch wrote: > > On Friday 16 November 2007 07:48:23 Larry Finger wrote: > >> Recent changes in ssb sprom handling break compilation. These two patches > >> fix the problem. > > are your sprom r4 changes already applied? I didn't test that in the b44, > > yet. > > I did a git pull yesterday and the sprom r3 and r4 changes were in > wireless-2.6/everything. And now, so is this one. I'll probably roll it into the main ssb sprom patch before actually sending it to Jeff. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: silence a bogus gcc warning
On Sat, Nov 10, 2007 at 04:14:03PM +0100, Michael Buesch wrote: > From: Frank Lichtenheld <[EMAIL PROTECTED]> > > inititalise ret to 0 to avoid the following bogus warning: > CC [M] drivers/net/wireless/b43/debugfs.o > drivers/net/wireless/b43/debugfs.c: In function ‘b43_debugfs_read’: > drivers/net/wireless/b43/debugfs.c:355: warning: ‘ret’ may be used > uninitialized in this function > > Signed-off-by: Frank Lichtenheld <[EMAIL PROTECTED]> > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Isn't this what uninitialized_var() is for? -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Help with wireless on Fedora 8
On Fri, Nov 09, 2007 at 04:39:56PM -0600, Larry Finger wrote:
> I need some Fedora help. This new b43 user is having problems making a
> connection. He has a b-only
> AP of unspecified make with no encryption. He is using F8 with the default
> kernel (I think). He has
> done the following:
>
> Ruggiero wrote:
> > i used "system->adminstration>Network" and i configurated everything from
> > there...and the clicking on "activate wlan0" for a while my access point
> > communicate and in the log i see that it's connected... here are outputs:
> > if i use NetworkManager i see it's connecting...but after a while i get the
> > message "disconnected"
>
> Tail of dmesg:
>
> > wlan0: Initial auth_alg=0
> > wlan0: authenticate with AP 00:0c:41:19:2d:c1
> > wlan0: authenticate with AP 00:0c:41:19:2d:c1
> > wlan0: authenticate with AP 00:0c:41:19:2d:c1
> > wlan0: authentication with AP 00:0c:41:19:2d:c1 timed out
> > wlan0: authentication frame received from 00:0c:41:19:2d:c1, but not in
> > authenticate state - ignored
> > wlan0: RX disassociation from 00:0c:41:19:2d:c1 (reason=4)
>
> All the b43 messages are normal. He sees the AP with a scan, but never
> authenticates. Any suggestions?
FWIW, the F8 install kernel has wireless bits that are a month or
so old. You may want to have him try these kernels:
http://koji.fedoraproject.org/koji/buildinfo?buildID=23734
Those at least have wireless bits that are up-to-date w/ wireless-2.6.
John
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43, b43legacy questions
On Wed, Nov 07, 2007 at 05:29:12PM -0700, Ehud Gavron wrote: > dmesg | grep b43 > > The version with F7 wants the v4 microcode files with the *old* names > (bcm43xx_*) instead of the new ones. Just to clarify, all this means is that for F7 you should continue to use "bcm43xx-fwcutter" instead of "b43-fwcutter". Gene, FWIW if b43 is getting loaded then that is almost certainly the right driver. The one in F7 is a bit behind, so if it isn't working you might want to try an F8 kernel. I think you should be able to run an F8 kernel on F7 w/o any trouble. Hopefully that will drive your 4318 -- it works for both of mine. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.24 patches for b43legacy
On Fri, Oct 19, 2007 at 12:41:21PM -0500, Larry Finger wrote: > Are the following patches queued for Linus's tree? > > "[PATCH V2] b43legacy: LED triggers support" - sent 10/12/07 > "[PATCH] b43legacy: RF-kill support" - sent 10/10/07 > "[PATCH] b43legacy: Use input-polldev for the rfkill switch" - sent 10/10/07 > "[PATCH] b43legacy: Rewrite pwork locking" - sent 10/10/07 > "[PATCH] b43legacy: Fix potential return of uninitialized variable" - sent > 10/14/07 > "[PATCH] b43legacy: Fix namespace pollution and sparse warnings" - sent > 10/17/07 I have them all, but they did not make the cut-off for 2.6.24. I sent the next-to-last one to Jeff last night as a "fix". The rest will be sent to Jeff after 2.6.24-rc1 is released, in anticipation of inclusion into 2.6.25. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH #3] b43: Fix sparse warnings.
On Fri, Oct 19, 2007 at 03:47:13PM +0200, Michael Buesch wrote: > On Thursday 18 October 2007 21:53:22 John W. Linville wrote: > > On Wed, Oct 17, 2007 at 06:34:03PM +0200, Michael Buesch wrote: > > > The remaining warning in phy.c will be fixed later. > > > > > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > > > > > --- > > > > > > John, this is the third time I submit this. > > > Is something wrong with this patch or did you simply forget to apply it? > > > > Where are you looking? It is in Linus' tree. > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a09404a2338163f181d170c7abdc2242b6c6f03 > > > > John > > Uhm, it still applies to wireless-2.6#everything. I imagine that it won't when that gets rebased, probably after 2.6.24-rc1. :-) Seriously, either I must have neglected to add it to everything and merged-upstream. I'll look into it. The important thing is that Linus has it. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH #3] b43: Fix sparse warnings.
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 -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix regression in 2.6.23-git3 due to change in calling add_uevent_var
On Sat, Oct 13, 2007 at 11:46:47PM -0500, Larry Finger wrote: > In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence > for add_uevent_var was changed, but the ssb driver was not modified, which > leads to a "Unable to handle kernel paging request" oops. This patch fixes > the problem. Sorry, Al Viro got a patch merged before I got to yours! Thanks anyway! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311: trouble with Fedora 8 Test 3
On Wed, Oct 10, 2007 at 12:08:08PM -0400, sean darcy wrote: > Nothing at all about the 4311 card in dmesg. > > Made sure NetworkManager was working. Restarted it. I can see the icon. > No connection. If I connect the wire it starts up the wired connection. Please post the output of this command: cat /sys/bus/ssb/devices/ssb0\:0/uevent I suspect that your device's core is too new to be supported. > dmesg does show this error: > > ssb: rev 6000 > WARNING: at drivers/ssb/main.c:889 ssb_tmslow_reject_bitmask() (Not tainted) Technically a warning, not an error. :-) John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Leds spinlock SMP compilefix
I'll just roll this into the "b43: LED triggers support" patch. Thanks, John On Sun, Sep 30, 2007 at 12:04:36AM +0200, Michael Buesch wrote: > This was missing an address operator. > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > Index: wireless-2.6/drivers/net/wireless/b43/leds.c > === > --- wireless-2.6.orig/drivers/net/wireless/b43/leds.c 2007-09-29 > 12:44:08.0 +0200 > +++ wireless-2.6/drivers/net/wireless/b43/leds.c 2007-09-30 > 00:02:18.0 +0200 > @@ -37,14 +37,14 @@ static void b43_led_turn_on(struct b43_w > unsigned long flags; > u16 ctl; > > - spin_lock_irqsave(wl->leds_lock, flags); > + spin_lock_irqsave(&wl->leds_lock, flags); > ctl = b43_read16(dev, B43_MMIO_GPIO_CONTROL); > if (activelow) > ctl &= ~(1 << led_index); > else > ctl |= (1 << led_index); > b43_write16(dev, B43_MMIO_GPIO_CONTROL, ctl); > - spin_unlock_irqrestore(wl->leds_lock, flags); > + spin_unlock_irqrestore(&wl->leds_lock, flags); > } > > static void b43_led_turn_off(struct b43_wldev *dev, u8 led_index, > @@ -54,14 +54,14 @@ static void b43_led_turn_off(struct b43_ > unsigned long flags; > u16 ctl; > > - spin_lock_irqsave(wl->leds_lock, flags); > + spin_lock_irqsave(&wl->leds_lock, flags); > ctl = b43_read16(dev, B43_MMIO_GPIO_CONTROL); > if (activelow) > ctl |= (1 << led_index); > else > ctl &= ~(1 << led_index); > b43_write16(dev, B43_MMIO_GPIO_CONTROL, ctl); > - spin_unlock_irqrestore(wl->leds_lock, flags); > + spin_unlock_irqrestore(&wl->leds_lock, flags); > } > > /* Callback from the LED subsystem. */ -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Mon, Sep 17, 2007 at 09:18:57PM +0100, David Woodhouse wrote: > On Fri, 2007-09-14 at 23:33 +0200, Michael Buesch wrote: > > These are all false positives, except this one, where the wrong > > converter function was used. > > > > @@ -442,7 +444,7 @@ void b43legacy_rx(struct b43legacy_wldev > > phystat0 = le16_to_cpu(rxhdr->phy_status0); > > phystat3 = le16_to_cpu(rxhdr->phy_status3); > > jssi = rxhdr->jssi; > > - macstat = le32_to_cpu(rxhdr->mac_status); > > + macstat = le16_to_cpu(rxhdr->mac_status); > > mactime = le16_to_cpu(rxhdr->mac_time); > > chanstat = le16_to_cpu(rxhdr->channel); > > Did this one get committed yet? Working on it now... -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
On Mon, Sep 17, 2007 at 12:05:36PM -0500, Larry Finger wrote:
> John W. Linville wrote:
> > Is this the correct patch? The first hunk conflicts with an earlier
> > patch ("b43legacy: Fix cancellation of work queues").
> >
> > John
>
> Yes, this one is correct. The first one was without a commit message, and had
> an error.
H, not that one. There was another patch that (looking closer)
you sent me and cc'ed bcm43xx-dev on or about 30 August. I guess
I'll drop that one and use this one instead.
Thanks,
John
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
Is this the correct patch? The first hunk conflicts with an earlier
patch ("b43legacy: Fix cancellation of work queues").
John
On Mon, Sep 10, 2007 at 11:59:20AM -0500, Larry Finger wrote:
> From: Michael Buesch <[EMAIL PROTECTED]>
>
> The wq must be canceled later on rmmod. It's nonfatal, if
> the wq runs on a device that's not started or down. It will
> handle these cases.
> But syncing in wireless_core_exit() will cause a deadlock with
> the restart_work. (restart work cancels itself)
>
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> John,
>
> Sorry, but I sent the bare patch in the first version.
>
> Larry
>
> drivers/net/wireless/b43legacy/main.c |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: wireless-dev/drivers/net/wireless/b43legacy/main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/b43legacy/main.c
> +++ wireless-dev/drivers/net/wireless/b43legacy/main.c
> @@ -3021,6 +3021,7 @@ static void b43legacy_wireless_core_exit
> B43legacy_WARN_ON(b43legacy_status(dev) > B43legacy_STAT_INITIALIZED);
> if (b43legacy_status(dev) != B43legacy_STAT_INITIALIZED)
> return;
> + b43legacy_set_status(dev, B43legacy_STAT_UNINIT);
>
> b43legacy_rng_exit(dev->wl);
> b43legacy_pio_free(dev);
> @@ -3520,6 +3521,7 @@ static void b43legacy_one_core_detach(st
>
> wldev = ssb_get_drvdata(dev);
> wl = wldev->wl;
> + cancel_work_sync(&wldev->restart_work);
> b43legacy_debugfs_remove_device(wldev);
> b43legacy_wireless_core_detach(wldev);
> list_del(&wldev->list);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: fetching wireless dev
On Wed, Aug 29, 2007 at 09:54:16PM +0200, Richard Jonsson wrote: > [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git checkout -b > everything origin/everything > Switched to a new branch "everything" > [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git branch > * everything >master > [EMAIL PROTECTED]:/usr/src/git/wireless-dev$ git pull > Warning: No merge candidate found because value of config option > "branch.everything.merge" does not match any remote branch > fetched. > No changes. Well, you did just clone the repository -- no new changes since your clone... John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: fetching wireless dev
On Wed, Aug 29, 2007 at 07:34:58PM +0200, Richard Jonsson wrote: > I can't figure out how to keep up to date with the wireless dev tree. > I've set up as told by John W. Linville in a post here and use the > "everything" branch. > > When browsing the tree at kernel.org I see changes from 24'th of august, > but my local copy is from 15'th (when I first fetched) even after "git > fetch". What command am I supposed to use? I think 'git pull' is what you want. But be warned that wireless-dev will be rebased from time to time, and pulling won't work across rebases. > What is the best practice to apply patches not yet in Linvilles tree? > > My purpose is to test patches from the list and will probably not do > patches myself. The best practice would be to keep an up-to-date copy of Linus' tree (i.e. linux-2.6) using 'git pull'. Then when you want to experiment w/ wireless-dev, you can create a lightweight clone (my terminology) using a command like this: git clone --reference linux-2.6 git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git wireless-dev Then create a working branch for yourself: git checkout -b work origin/everything Then you can apply patch emails for testing. Save the patch email in mbox format, then use this command: git applymbox patch.mbox Then, build-test-patch-repeat... :-) Hth! John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Updated Status on b43 driver and Fedora 7
On Fri, Aug 24, 2007 at 05:50:12PM -0500, Larry Finger wrote: > If your V4 firmware is still in /lib/firmware, then the Fedora kernel is a > little behind the > wireless-dev tree. Once the code that uses the new naming scheme hits their > kernel, your wireless > will probably stop working. Be prepared. FWIW, this isn't quite true -- at least not in F7. It is true in rawhide, and I'm a bit surprised that no one has complained yet... :-) In F7 I am carrying a patch to reverse the change to the new firmware format. I want to keep F7 near wireless-dev's head, but I didn't want to break a bunch of existing configurations. I haven't quite figured-out how long I'm going to carry this in F7. It will not be in F8. Just curious, what was the motivation for the new firmware format? Can the new format be quickly described in high level terms? I'm wondering if a tool could easily convert the old firmware format to the new, so that we might add it as an upgrade tool for F8. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: minor grips with b43
On Fri, Aug 24, 2007 at 10:03:58AM -0500, Larry Finger wrote: > We are working on all these problems. What effect they have on the > performance is unknown, but it > cannot be too severe. Last night I had to boot into Windows (uugh!!) and > happened to notice that the > bit rate for my BCM4311 was toggling between 18 and 24M. With the same setup, > b43 usually is at > either 48 or 54M. Take that Broadcom!!! Hereby nominated for quote of the day, 2007-08-24... :-) -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43, b43legacy: Fix inconsistency between branches 'b43' and 'everything' in wireless-dev
On Thu, Aug 23, 2007 at 06:05:40PM -0500, Larry Finger wrote: > I'm not sure how to handle this. In it's present state, branch 'b43' cannot > be used > to generate a working version of b43 or b43legacy. In addition, the Kconfig > and Makefile > from b43legacy are not included, thus it is not possible to build b43legacy > in that branch. I had neglected to pull the mac80211 updates into the branches that depend on them (now most of the driver branches). I have done that now, and pushed the results. Hth! John P.S. FWIW, b43legacy seems to have Kconfig and Makefile in my tree. I was able to build it just fine. Yes, I checked to make sure I had included them in git. :-) -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Initial port of new driver with bcm43xx PHY code and ssb/mac80211 front end
On Wed, Aug 22, 2007 at 12:41:46PM -0500, Larry Finger wrote: > This patch ports the PHY and radio handling code of the softmac driver > to the mac80211 front end from b43. The resulting driver is known as > b43legacy. I have added this to the b43 branch of wireless-dev. It is available in 'everything' as well. -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc3-mm1: fix b43 compilation
On Wed, Aug 22, 2007 at 11:56:43PM +0200, Michael Buesch wrote: > On Wednesday 22 August 2007 18:33:58 Rafael J. Wysocki wrote: > > On Wednesday, 22 August 2007 11:06, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ > > > > > > - git-ixgbe.patch got dropped - git-net.patch destroyed it > > > > > > - then git-net got dropped as it doesn't work > > > > Apparently, the b43 driver is expecting another version of mac80211. > > > > This patch fixes the compilation, but I'm not sure what about the > > functionality. ;-) > > There seems to be a screwup somehow. > These mac80211 API functions were recently changed to include > the additional parameter. So it seems you carry an old version of mac80211. I think what happened is because Andrew dropped Dave M.'s net tree. Since mac80211 has been getting merged through Dave M., crucial bits are missing which then break the bits from wireless-dev. Andrew, if you find that you need to drop git-net again then I'll be happy to provide you with a wireless-dev patch that does not depend on Dave's tree. The mm-master branch in wireless-dev has dropped those patches which have gone to Dave M. in the hopes of avoiding conflicts. Dependencies are another matter... :-) John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ALERT: firmware change for b43
On Wed, Aug 22, 2007 at 10:25:28AM -0500, Larry Finger wrote: > John W. Linville wrote: > >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. > > The new code is in the svn repository; however, a tarball would not be a > problem. Is source sufficient, or would you want an executable? Source would be fine, equivalent to what is here: http://download.berlios.de/bcm43xx/bcm43xx-fwcutter-006.tar.bz2 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: ALERT: firmware change for b43
On Sun, Aug 19, 2007 at 02:37:21PM -0500, Larry Finger wrote: > > Just in case you missed the details, the latest set of changes to b43 queued > by Michael will require > a new version of fwcutter, now called b43-fwcutter, and a new extraction of > your firmware. Is there a tarball available for download, as with bcm43xx-fwcutter? It would be handy for packaging. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [patch 6/6] b43: New firmware file format
On Tue, Aug 21, 2007 at 05:46:40PM +0200, Johannes Berg wrote:
> On Sun, 2007-08-19 at 01:48 +0200, Michael Buesch wrote:
>
> > @@ -1598,8 +1601,29 @@ static int do_request_fw(struct b43_wlde
> > b43err(dev->wl, "Firmware file \"%s\" not found "
> >"or load failed.\n", path);
>
> + return err;
>
> > }
> > + if ((*fw)->size < sizeof(struct b43_fw_header))
> > + goto err_format;
>
> otherwise it oopses when the file can't be loaded.
ACK...here is a patch, in case you are lazy... :-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index dcf7edc..d8693cf 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -1600,6 +1600,7 @@ static int do_request_fw(struct b43_wldev *dev,
if (err) {
b43err(dev->wl, "Firmware file \"%s\" not found "
"or load failed.\n", path);
+ return err;
}
if ((*fw)->size < sizeof(struct b43_fw_header))
goto err_format;
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Does auto-loading of b43 work for you?
On Thu, Aug 16, 2007 at 06:40:23PM -0500, Larry Finger wrote: > Has anyone used the new driver variation known as b43 from that branch of > wireless-dev and gotten > auto-loading at bootup of the b43 module on i386 or x86_64 platforms. It > still doesn't work here > even after upgrading to the latest version of udev. Before I post to LKML > regarding this problem, I > would like to get an idea if is restricted to my system, or if it is a > general problem with x86 > architectures. We know it works on PPC platforms. If your system is also > failing, I would like to > know your distro. Seems to work fine for me w/ latest wireless-dev built w/ mostly-stock (had to change BCM43XX-MAC80211 to B43) F-7 kernel config on T41 w/ F-7. Don't even have the "%X" patch. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Fri, Aug 17, 2007 at 02:52:56AM +0200, Johannes Berg wrote:
> On Mon, 2007-08-06 at 13:05 -0400, John W. Linville wrote:
>
> > --- a/net/mac80211/ieee80211.c
> > +++ b/net/mac80211/ieee80211.c
> > @@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
> > memcpy(dst, hdr->addr1, ETH_ALEN);
> > memcpy(src, hdr->addr3, ETH_ALEN);
> >
> > - if (sdata->type != IEEE80211_IF_TYPE_STA) {
> > + if (sdata->type != IEEE80211_IF_TYPE_STA ||
> > + (is_multicast_ether_addr(dst) &&
> > +!compare_ether_addr(src, dev->dev_addr)))
> > return TXRX_DROP;
>
> I can confirm that this works (applies if you s/ieee80211.c/rx.c/) for
> IPv6 link local addresses, and it's definitely the right thing to do
> here.
Yes, seems so. FWIW, this patch is in later Fedora kernels.
Unfortunately (due to the ieee80211.c -> rx.c issue you mentioned)
applying this to 2.6.23 conflicts with patches already queued for
2.6.24. Since my experiments show that git doesn't help much in this
instance, I'll need to work something out with Dave M. if we are to
get this into 2.6.23.
If nothing else, I suppose we can just wait for 2.6.23 and send this
patch to -stable. Would that burn anyone's biscuits?
John
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
wireless-dev rebased, new rebasing policies
Greetings! Some of you have already noticed that the wireless-dev tree has been rebased. I adopted the mac80211 work of Jiri Benc as a base, then re-imported all of the mac80211 drivers (and the SSB stuff) from wireless-dev into individual branches. There is also an 'everything' branch into which all the other branches get pulled, and an 'mm-master' branch which has the sole purpose of feeding patches to akpm while minimizing conflicts with the other networking trees. The master branch is a direct pull of something relatively recent from Linus, usually an -rc or release tag. Recent versions of git seem to hide remote branches by default when cloning a tree, so by default you will just get my master branch. Since this isn't very interesting for wireless development, you will want to recreate one or more of my branches to work from as a base. At a minimum, everyone from "early adopter" users to driver maintainers will want the 'everything' branch, so I will illustrate recreating that below. Other branches are done similarly. /home/linville/git/wireless-dev [linville-t43.mobile]:> git branch * master /home/linville/git/wireless-dev [linville-t43.mobile]:> git branch -r origin/HEAD origin/adm8211 origin/b43 origin/everything origin/iwlwifi origin/mac80211 origin/master origin/merged-upstream origin/mm-master origin/p54 origin/rt2x00 origin/ssb origin/zd1211rw /home/linville/git/wireless-dev [linville-t43.mobile]:> git checkout -b everything origin/everything Switched to a new branch "everything" /home/linville/git/wireless-dev [linville-t43.mobile]:> git branch * everything master Unlike the way wireless-dev was used in the past, I make no promises about rebasing. I intend to rebase most/all of the branches at least as often as Linus produces an -rc or release tag, and I reserve the right to rebase more often as I deem necessary. I'm sorry, but as you can see I have to manage a lot of patches. Keeping them based off a recent head is helpful to me. I will entertain suggestions for how to minimize rebasing pain for anyone following this tree. However, the best suggestion I have for anyone tracking wireless-dev is for them to get their favorite driver(s) merged upstream. Barring that, I understand that quilt can be a good tool for tracking stacks of patches in development. The git-format-patch, git-applymbox, and git-rebase commands are handy as well. Those simply following the tree should learn about the "--reference" option to git-clone, and should use it often. Keeping a backup of previous git trees with any work in progress wouldn't hurt either. Questions? Complaints? Comments? Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
