This patch removes some dead code from the driver.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for 2.6.27
Index: wireless-testing/drivers/net/wireless/b43/lo.c
===
--- wireless-testing.orig/drivers/net
On Sunday 20 April 2008 18:04:20 Daniel wrote:
Hey All,
Michael Buesch wrote:
Can you also give this a try?
http://bu3sch.de/patches/wireless-testing/20080419-1646/patches/005-b43-calibrate-lo-on-demand.patch
I'm getting these errors on a 2.6.25 tree. Any ideas?
drivers/net/wireless
On Monday 21 April 2008 08:52:00 Rafał Miłecki wrote:
2008/4/17, Michael Buesch [EMAIL PROTECTED]:
On Thursday 17 April 2008 19:07:22 Larry Finger wrote:
I'm glad it is not working.
Haha. And people call _me_ inhuman. :D
Oh come on. Make that device working and we will be even
On Sunday 20 April 2008 22:41:27 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 20 April 2008 07:27:57 Larry Finger wrote:
I'm not sure what happened to my patch; however, I just added that
information to the sprom section of the b43 wiki at linux-wireless.
Can you resend
On Monday 21 April 2008 17:24:34 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 20 April 2008 22:41:27 Larry Finger wrote:
--snip--
+Obtaining a disk copy of the sprom contents
+---
+
+This file name for the sprom contents depends
On Monday 21 April 2008 20:50:06 Miles Lane wrote:
On Mon, Apr 21, 2008 at 7:57 AM, Johannes Berg
[EMAIL PROTECTED] wrote:
Hi,
Miles described a b43 speed problem in the thread
2.6.25-rc9 -- bcm4306 performance is in the toilet
(over 2.6.24) and not being able to see
On Tuesday 22 April 2008 18:26:34 Stefanik Gábor wrote:
And as we can expect from ASUS, the LED settings are wrong, too. (All are @
0xFF.) The same is true for the antenna bitfields (it has 1 antenna for B/G,
and no A antennas, yet the bitfield says 0 B/G antennas and 2 A ones...).
Well, there
a lower mask.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix for 2.6.26
Stefano, we might probably want to backport this to legacy.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless
a lower mask.
This patch is in wireless-testing.git, commit
91725545159f81f1c9dc738dfc329199583f649a
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/net/wireless/b43/dma.c
===
--- linux-2.6.25.orig/drivers
d30cdf8a251e88e58bc566f5acaa9eb97ac102e9
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Gabor Stefanik [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/ssb/pci.c
This adds more workarounds for devices with broken BT bits.
This patch is in wireless-testing.git, commit
4b43b16f74b362d4d2ce7df5b761eb838dfd5d32
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/net/wireless/b43/main.c
).
This also adds a modparam knob to help debugging this in the future,
as more devices with this bug may show up.
This patch is in wireless-testing.git, commit
5e0fa73f3f6d2aea9c0498dc8d7e621c8fb9e6aa
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/net/wireless/b43
On Friday 25 April 2008 06:55:54 Larry Finger wrote:
Michael,
I have discovered that both sprom_extract_r123() in the ssb driver,
and ssb-sprom use a two-byte quantity to extract the board revision.
In the specifications detailed in
http://bcm-v4.sipsolutions.net/SPROM, a single-byte is
On Friday 25 April 2008 06:42:20 Larry Finger wrote:
This version modifies the setting of the patch to ssb_sprom to handle
systems with multiple SSB-based devices.
Applied, thanks.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
On Friday 25 April 2008 16:16:49 Larry Finger wrote:
Michael Buesch wrote:
On Friday 25 April 2008 06:55:54 Larry Finger wrote:
Michael,
I have discovered that both sprom_extract_r123() in the ssb driver,
and ssb-sprom use a two-byte quantity to extract the board revision
On Friday 25 April 2008 17:21:00 Richard Jonsson wrote:
I use a custom kernel, but I think I turned off b43/ssb debugging some
time ago. Anyway dmesg is drowning in this:
Oh, finally something useful. Great!
[ 7389.533848] b43-phy0 warning: You must go to
On Friday 25 April 2008 18:09:27 Richard Jonsson wrote:
To add, I thought that my hardware had died judging by the messages
above, so I temporarily connected to an access point in the area and
could successfully load a few webpages before I disconnected.
You really need to be a bit more
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.
Index: wireless-testing/drivers/net/wireless/b43/b43.h
This patch removes the IRQ-disable from mac_suspend.
The main advantage of this is to get rid of the IRQ-sync call in mac_suspend.
We need to remove the MAC suspend bit from the IRQ service mask, as otherwise
the IRQ handler would race with us.
Signed-off-by: Michael Buesch [EMAIL PROTECTED
On Sunday 27 April 2008 01:42:24 Larry Finger wrote:
I have no idea as to why the interface is switching from 5 to 2.4 GHz,
Well, most likely it's scanning the channels, right?
and back endlessly. Perhaps Michael knows. It is also possible that
the bug is in the new mac80211 band API, which
On Sunday 27 April 2008 17:36:22 Larry Finger wrote:
Richard Jonsson wrote:
With the reverted commit b43: Fix bandswitch back in, and the above
patch applied the bad behavior is back. This is on mainline.
regards, Richard
My interface was definitely a BCM4311 with only B/G mode. I
Please test whether this fixes the regression.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2008-04-27
17:47:49.0 +0200
+++
On Sunday 27 April 2008 17:36:22 Larry Finger wrote:
Richard Jonsson wrote:
With the reverted commit b43: Fix bandswitch back in, and the above
patch applied the bad behavior is back. This is on mainline.
regards, Richard
My interface was definitely a BCM4311 with only B/G mode. I
On Sunday 27 April 2008 18:57:20 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 27 April 2008 17:36:22 Larry Finger wrote:
Richard Jonsson wrote:
With the reverted commit b43: Fix bandswitch back in, and the above
patch applied the bad behavior is back. This is on mainline
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]
---
John, this is 2.6.26 material.
Index: wireless-testing/drivers/net/wireless/b43/main.c
On Tuesday 29 April 2008 09:06:00 Abel Camarillo Ojeda wrote:
Hi everyone:
I am using the b43 driver from compat-wireless-18-apr-2008 tarball
with my 2.6.25 kernel at my slackware 12.0 box and I have the next problem:
when I start a very bandwith eating transfer y concern about an
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.
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
This patchset adds API and one user for a weak dma_set_mask().
Weak means that it will fallback to smaller masks in case the
DMA subsystem rejects a big mask.
Currently such rejection may happen if the driver requests a 64bit
mask on a VIA machine, for example. dma_set_mask_weak() will fallback
to
This adds a user for the new weak DMA mask API.
This removes the b43 DMA mask probe loop.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/wireless/b43/dma.c
===
--- linux-2.6.orig/drivers/net/wireless
() will fallback
to 32bit, in that case, and tell the caller about it by modifying the
passed mask.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-testing/drivers/base/dma-mapping.c
===
--- wireless-testing.orig/drivers/base
This adds a weak variant of ssb_dma_set_mask().
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6/drivers/ssb/main.c
===
--- linux-2.6.orig/drivers/ssb/main.c 2008-05-01 13:19:53.0 +0200
+++ linux-2.6
On Thursday 01 May 2008 17:36:18 Christoph Hellwig wrote:
On Thu, May 01, 2008 at 04:38:15PM +0200, Michael Buesch wrote:
This patchset adds API and one user for a weak dma_set_mask().
Weak means that it will fallback to smaller masks in case the
DMA subsystem rejects a big mask
On Thursday 01 May 2008 17:43:58 Christoph Hellwig wrote:
On Thu, May 01, 2008 at 05:42:04PM +0200, Michael Buesch wrote:
Yeah. because it has to be done in every driver.
So we put the implementation into a central place, instead of
reimplementing the wheel over and over again. This way we
On Thursday 01 May 2008 17:58:26 Christoph Hellwig wrote:
On Thu, May 01, 2008 at 05:47:26PM +0200, Michael Buesch wrote:
We've discussed that and this behaviour is not acceptable, as the driver
must know about a possible fallback in case it can do 32bit DMA
more efficiently than 64bit DMA
On Thursday 01 May 2008 18:20:45 Alan Cox wrote:
On Thu, 1 May 2008 16:40:16 +0200
Michael Buesch [EMAIL PROTECTED] wrote:
This adds a new DMA subsystem API call for weak setting
of the DMA mask
weak is an odd term - and we use weak for things like weak symbols so it
might be confusing
On Thursday 01 May 2008 18:30:04 Jesse Barnes wrote:
On Thursday, May 01, 2008 9:07 am Michael Buesch wrote:
On Thursday 01 May 2008 17:58:26 Christoph Hellwig wrote:
On Thu, May 01, 2008 at 05:47:26PM +0200, Michael Buesch wrote:
We've discussed that and this behaviour is not acceptable
On Thursday 01 May 2008 19:22:55 Jesse Barnes wrote:
On Thursday, May 01, 2008 10:16 am Michael Buesch wrote:
Ok, will redo the patches with that added and the name changed.
Most drivers just do the fallback themselves, right?
Right.
So it makes sense to
just update the current
On Thursday 01 May 2008 19:27:35 Jesse Barnes wrote:
On Thursday, May 01, 2008 10:16 am Michael Buesch wrote:
So it makes sense to
just update the current code to fallback, and update drivers wanting
specific mask values to check afterwards. I hate to inflict that kind of
driver wide
This fixes some TX/RX related locking issues.
With this patch applied, some of the PHY transmission errors are fixed.
This patch is in wireless-testing.git, commit
c83d30b31aebdf652f78f4f6898959e44fd67ca3
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/net/wireless
On Wednesday 07 May 2008 20:35:16 Larry Finger wrote:
Michael,
On the current Ubuntu kernel (2.6.24), trying to load b43legacy causes a
kernel hang with BCM4301 and BCM4303 devices. In trying to debug this, I have
b43legacy blacklisted and I am trying to get useful information on the hang
On Wednesday 07 May 2008 22:33:23 [EMAIL PROTECTED] wrote:
My apologies if I'm spamming the wrong list; please reply privately and I'll
take this elsewhere if so.
I have a Bcm 4315 (not 18, not 03) and it seems that this model is not
listed anywhere in any references I can find; not
From: Huang Weiyi [EMAIL PROTECTED]
Remove duplicated include linux/delay.h in
drivers/net/wireless/b43/nphy.c
Signed-off-by: Huang Weiyi [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
--- a/drivers/net/wireless/b43/nphy.c 2008-05-10 08:46:36.0 +0800
+++ b/drivers
On Saturday 10 May 2008 10:47:09 Stefanik Gábor wrote:
Rui: BCM4328 is an N-PHY. N-PHYs can't be supported using the current PHY
code, not even 802.11b-only. However, support for N-PHYs is under
development, just it's hidden from view in the wireless-testing kernel.
Apply the patch @
On Monday 12 May 2008 18:06:51 Richard Jonsson wrote:
Ehud Gavron skrev:
Rafal Milecki wrote:
Really, HP-laptop dv6057ea doesn't mean much for every one. It would
be nice to post proper part of
lspci -nnv
Others have written:
Please include dmesg
Still others have said:
It
On Monday 12 May 2008 20:32:00 Richard Jonsson wrote:
* If performance is poor; What environment is your wlan in, walls,
distance etc.
I wish these weren't reported at all.
First fact is we can't do anything about them anyway.
Second fact is that we already know about possible performance
On Monday 12 May 2008 22:25:50 Richard Jonsson wrote:
If the bug worked with earlier kernels, but has since stopped working, a
bisection is of great value.
If the _driver_ worked with earlier...
Probably :)
Maybe somebody might also complain about a bug that stopped working :P
--
Greetings
On Monday 12 May 2008 22:42:51 Richard Jonsson wrote:
Michael Buesch skrev:
On Monday 12 May 2008 22:25:50 Richard Jonsson wrote:
If the bug worked with earlier kernels, but has since stopped working, a
bisection is of great value.
If the _driver_ worked with earlier...
Probably
On Tuesday 13 May 2008 10:19:23 Daniel wrote:
Hello All,
Apologies if this has been fixed in a newer version. I was just
wondering if anyone has seen this bug before:
Could you _please_ be so kind an explain your actual problem??
My magic crystalball is broken today.
b43-phy1: Broadcom
On Tuesday 13 May 2008 23:31:17 Daniel wrote:
Hello,
Michael Buesch wrote:
Could you _please_ be so kind an explain your actual problem??
My magic crystalball is broken today.
Sorry, it's the problem where after X minutes the device seems to loose
the ability to communicate. It seems
On Wednesday 14 May 2008 01:36:04 Johannes Berg wrote:
On Wed, 2008-05-14 at 01:33 +0200, Johannes Berg wrote:
Where does this wrong buffer size message come from, and what does it
mean?
b43-phy1 debug: Using hardware based encryption for keyidx: 1, mac:
ff:ff:ff:ff:ff:ff
On Thursday 15 May 2008 21:07:36 [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.
You didn't misread it. The specs changed recently.
And I think the bsinitvals also have to be rechecked.
I'll
On Thursday 15 May 2008 21:53:48 Pavel Roskin wrote:
On Thu, 2008-05-15 at 21:39 +0200, Michael Buesch wrote:
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.
Exactly. That's why I
This patch adds some hooks for firmware debugging.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.27
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net
On Saturday 17 May 2008 23:21:22 Stefanik Gábor wrote:
Hmm... what's this? Are we planning something along the lines of
prism54's FreeMAC?
http://bu3sch.de/gitweb?p=b43-ucode.git;a=summary
Doesn't work, yet. So you don't need to try. ;)
--
Greetings Michael.
This patch adds code to allow running the device without PCM firmware loaded.
Without PCM firmware we don't have hardware accelerated crypto on
devices with a core rev = 10.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.27
Index: wireless-testing/drivers/net
On Sunday 18 May 2008 00:27:49 Stefanik Gábor wrote:
On Sat, May 17, 2008 at 11:24 PM, Michael Buesch [EMAIL PROTECTED] wrote:
On Saturday 17 May 2008 23:21:22 Stefanik Gábor wrote:
Hmm... what's this? Are we planning something along the lines of
prism54's FreeMAC?
http://bu3sch.de
On Monday 19 May 2008 01:16:30 Bubba Siggler wrote:
way to much mail.
Hahaha :D That's a good one.
You should consider subscribing the linux-kernel-mailinglist.
That has about 500 mails per day. :)
___
Bcm43xx-dev mailing list
Add a firmware panic reason code that doesn't trigger a restart.
This is useful for firmware debugging and avoiding endless
restart loops. We can use FWPANIC_DIE to halt the firmware at a
well defined point.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.27
Index
This adds support for firmware markers.
With firmware markers it's easily possible to check whether the
firmware runs some codepath or not. The driver will throw a message
when the firmware executes a MARKER(x).
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.27
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h2008-05-20
00:16:27.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/b43.h 2008-05-20
This updates the beacon template code to upload both templates,
if we never uploaded one before.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, we can apply that to 2.6.26, but I guess it's not too important
there, as that doesn't support AP, IBSS or Mesh anyway.
Index: wireless
On Tuesday 20 May 2008 12:16:28 Michael Buesch wrote:
This updates the beacon template code to upload both templates,
if we never uploaded one before.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, we can apply that to 2.6.26, but I guess it's not too important
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]
---
John, this is a bugfix for 2.6.26
Index: wireless-testing/drivers/net/wireless/b43/main.c
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
On Friday 30 May 2008 14:31:53 Johannes Berg wrote:
Since a while ago I've had trouble resuming when b43 was connected to an
AP while suspended.
I did a test today where this was the only difference, but I failed to
see whether ssb or b43 were causing the problem.
Does anyone have a
On Friday 30 May 2008 16:37:18 Johannes Berg wrote:
Odd. Resume itself works just fine here, except when b43 is up. But then
again, you might not notice that this is the problem because by default,
nothing gets printed on the resume console and then it will indeed hang
with a black screen.
On Saturday 31 May 2008 16:23:58 Stefanik Gábor wrote:
In the latest wireless-testing kernel, I get a panic when I try to
connect to a network or inject a packet in monitor mode using b43
(stack obtained using kdump and crash):
crash bt -l
PID: 0 TASK: c0431340 CPU: 0 COMMAND:
On Saturday 31 May 2008 18:34:29 Stefanik Gábor wrote:
BUG: unable to handle kernel NULL pointer dereference at 0004
IP: [f8dd3a99] :b43:b43_generate_txhdr+0x6a9/0x790
So can you put a few printks into the function to see where it dereferences
a NULL pointer? (or use gdb to lookup the
On Saturday 31 May 2008 18:50:36 Pavel Roskin wrote:
On Sat, 2008-05-31 at 18:41 +0200, Michael Buesch wrote:
On Saturday 31 May 2008 18:34:29 Stefanik Gábor wrote:
BUG: unable to handle kernel NULL pointer dereference at 0004
IP: [f8dd3a99] :b43:b43_generate_txhdr+0x6a9/0x790
So
On Saturday 31 May 2008 18:48:42 Pavel Roskin wrote:
It's strange that other drivers (b43legacy, ath5k) use
b43legacy does not support hwcrypto, so it can't crash.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Saturday 31 May 2008 22:29:13 Stefanik Gábor wrote:
On Sat, May 31, 2008 at 10:22 PM, Johannes Berg
[EMAIL PROTECTED] wrote:
On Sat, 2008-05-31 at 19:54 +0200, Michael Buesch wrote:
On Saturday 31 May 2008 18:50:36 Pavel Roskin wrote:
On Sat, 2008-05-31 at 18:41 +0200, Michael Buesch
Hi,
I hacked up some patches that add a virtual machine to the
b43 driver to run the firmware inside of the kernel.
http://bu3sch.de/patches/misc/b43-vm/
This doesn't sound very useful, but it might help when debugging
firmware code, as firmware code is extremely hard to debug when
run on the
On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote:
Looks like we are losing track of the microcode. The driver thinks
it's loaded, but in fact it isn't. Maybe we should reupload the
microcode on resume.
We already do this, of course.
--
Greetings Michael.
On Sunday 01 June 2008 13:47:22 Rafael J. Wysocki wrote:
On Sunday, 1 of June 2008, Michael Buesch wrote:
On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote:
Looks like we are losing track of the microcode. The driver thinks
it's loaded, but in fact it isn't. Maybe we should reupload
On Sunday 01 June 2008 15:18:39 Rafael J. Wysocki wrote:
On Sunday, 1 of June 2008, Michael Buesch wrote:
On Sunday 01 June 2008 13:47:22 Rafael J. Wysocki wrote:
On Sunday, 1 of June 2008, Michael Buesch wrote:
On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote:
Looks like we
Release early, release often.
Here's the first testing release of the b43 opensource firmware.
http://bu3sch.de/misc/b43-openfw-20080604.tar.bz2
Currently only the receive path is partially implemented. So that
means we can only run it in monitor mode for now. This firmware is
able to receive
On Thursday 05 June 2008 04:46:28 Pavel Roskin wrote:
On Wed, 2008-06-04 at 17:16 +0200, Michael Buesch wrote:
Release early, release often.
Here's the first testing release of the b43 opensource firmware.
http://bu3sch.de/misc/b43-openfw-20080604.tar.bz2
Currently only the receive
On Thursday 05 June 2008 16:37:18 Felipe Maya wrote:
[EMAIL PROTECTED]:/# insmod b43.ko fwpostfix=-open
Segmentation fault
[EMAIL PROTECTED]:/# dmesg
Unhandled kernel unaligned access[#1]:
Ah well. The alignment is not completely implemented, yet ;)
Working on that...
--
Greetings
On Friday 06 June 2008 08:51:53 Dale Walsh wrote:
On Jun 06, 2008, at 00:12 AM, [EMAIL PROTECTED] wrote:
Dale Walsh wrote:
I'm new to the list and new to firmware modification so hi everyone.
I have a broadcom PCI card and I need to modify the vendor and
product ID's, in case it
This fixes a kernel crash on rmmod, in the case where the controller
was restarted before doing the rmmod.
Upstream commit is 4735f5022c97f6624ced2ec5056c61c4b437d53b
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Index: linux-2.6.25.4/drivers/net/wireless/b43/main.c
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
On Sunday 08 June 2008 20:33:18 Dale Walsh wrote:
It appears that the b43 driver supports 11n functionality
What makes you think this?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Sunday 08 June 2008 20:46:18 Dale Walsh wrote:
On Jun 08, 2008, at 14:39 PM, Michael Buesch wrote:
On Sunday 08 June 2008 20:33:18 Dale Walsh wrote:
It appears that the b43 driver supports 11n functionality
What makes you think this?
Reading the english language I believe
On Sunday 08 June 2008 20:53:05 Dale Walsh wrote:
OK, wondering if you have a guesstimate on a time frame before
something useable is available?
No.
Would donating a card speed up the process???
No. Donating a Reverse Engineer would help.
--
Greetings Michael.
On Sunday 08 June 2008 22:11:38 Larry Finger wrote:
Booting the machine so that the SPROM can be changed is a little tricky. You
need to remove the WLAN card, boot into GRUB, and press a key to stop the
automatic GRUB booting. Next you install the WLAN card with the power on, and
then
On Monday 09 June 2008 05:03:46 Pavel Roskin wrote:
On Thu, 2008-06-05 at 15:35 +0200, Michael Buesch wrote:
There shouldn't be a reason for a freeze. It might crash, yes, but it always
prints out useful messages first for me.
I tried different miniPCI-toPCI bridges, hoping that it's
On Monday 09 June 2008 12:03:35 Dale Walsh wrote:
While the process has now become much simpler, I think it's extremely
dangerous if it doesn't perform some kind of verification on the data
that is being copied before it actually performs the firmware update.
It performs an 8bit CRC check.
On Monday 09 June 2008 11:36:13 Michael Buesch wrote:
On Monday 09 June 2008 05:03:46 Pavel Roskin wrote:
On Thu, 2008-06-05 at 15:35 +0200, Michael Buesch wrote:
There shouldn't be a reason for a freeze. It might crash, yes, but it
always
prints out useful messages first for me
On Thursday 12 June 2008 04:20:04 Larry Finger wrote:
Dale Walsh wrote:
I've been in touch with Broadcom a since I am considering having a card
OEM'ed and it was discussed acquiring the API and a framework for driver
programming in a custom OS so now I'm just waiting on approval.
Is
On Friday 13 June 2008 00:22:39 Pavel Roskin wrote:
On Mon, 2008-06-09 at 14:08 +0200, Michael Buesch wrote:
You can try the latest firmware from git, btw. It should be (partially)
fixed there.
I've tried the today's version. It's working in monitor mode.
Moreover, it scans in managed
On Friday 13 June 2008 03:14:08 Steve Brown wrote:
b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 6, Type 5, Revision 0)
LP PHYs are not supported, yet.
I'm not sure if I can send a patch in that converts this error message to
triple-uppercase. Why do people always ignore it?
--
Greetings
From: [EMAIL PROTECTED]
In current ssb-sprom code, the Subsystem and Product ID's are wrong for rev 4
SPROM's.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix for 2.6.26.
Index: ssb_sprom/ssb_sprom.h
On Friday 13 June 2008 10:47:33 Michael Buesch wrote:
From: [EMAIL PROTECTED]
In current ssb-sprom code, the Subsystem and Product ID's are wrong for rev 4
SPROM's.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix
On Friday 13 June 2008 17:31:53 Pavel Roskin wrote:
diff --git a/ssb_sprom/ssb_sprom.c b/ssb_sprom/ssb_sprom.c
index 2b05e9f..facacab 100644
--- a/ssb_sprom/ssb_sprom.c
+++ b/ssb_sprom/ssb_sprom.c
@@ -16,7 +16,7 @@
You should have received a copy of the GNU General Public License
On Friday 13 June 2008 17:33:05 Pavel Roskin wrote:
...
applied, thanks.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Hi,
Here comes another snapshot of the Opensource firmware for
the b43 wireless core.
http://bu3sch.de/b43/openfw/b43-openfw-20080614.tar.bz2
The firmware does _ONLY_ work in monitor mode. The TX path is not implemented,
so it can not associate or whatever. It can only receive packets.
This
86ef1ae07289c9f0aa1aa310d43653e513e6f124
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25.6/drivers/net/wireless/b43/b43.h
===
--- linux-2.6.25.6.orig/drivers/net/wireless/b43/b43.h 2008-06-14
22:43:28.0
is upstream in John Linville's wireless-testing.git tree.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25.6/drivers/net/wireless/b43/dma.c
===
--- linux-2.6.25.6.orig/drivers/net/wireless/b43/dma.c 2008-06-14
22:43
Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
This will fix the resume hang.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix for 2.6.26.
Index: wireless-testing/drivers
Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix for 2.6.26.
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
1101 - 1200 of 1753 matches
Mail list logo
