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 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
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 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
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 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
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
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
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
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
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 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 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
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
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
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
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 Sunday 20 April 2008 05:43:18 Pavel Roskin wrote:
Hello!
It looks like all tests with the experimental LO calibration code were
for bcm4306 and bcm4318. So I downgraded my Dell laptop from bcm4328
to bcm4311 (PCIe Mini Card), so that I can cover this gap and finally
switch to a
On Sunday 20 April 2008 07:27:57 Larry Finger wrote:
kala mazoo wrote:
Greets,
I'd originally downloaded ssb_sprom from the git link on the
b43 page.
Initially the syntax / usage of ssb_sprom totally eluded me, so I went back
and
searched the mailling list for
, 4311 and 4318 flavours.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply to 2.6.27
Index: wireless-testing/drivers/net/wireless/b43/lo.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/lo.c 2008-04-18
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 Saturday 19 April 2008 00:38:28 Larry Finger wrote:
Michael,
After seeing the fix for the ASUS cards, I went back to my card with a
BCM4301 and discovered that the board flags, both low and high, are
all set to ones. By detecting those conditions and forcing the values
to zero, I got
On Saturday 19 April 2008 05:49:24 [EMAIL PROTECTED] wrote:
The specifications call for the low 16 bits of the board flags to
be cleared if unset (== 0x). This step was taken in bcm43xx,
but was missed when ssb was coded. This omission prevents Linksys
WMP11 cards with a BCM4301 from
On Saturday 19 April 2008 05:54:06 [EMAIL PROTECTED] wrote:
The current code checks for the special signature that signifies
a revision 4 SPROM. A rev. 8 SPROM with a 440-byte length has been
found, but any special code for it is unknown. The the check should
be relaxed. With this patch, if
On Saturday 19 April 2008 15:13:24 Michael Buesch wrote:
On Saturday 19 April 2008 05:54:06 [EMAIL PROTECTED] wrote:
The current code checks for the special signature that signifies
a revision 4 SPROM. A rev. 8 SPROM with a 440-byte length has been
found, but any special code
, the code will immediately check for a 440-byte SPROM. If there
is still a CRC error, the size is set to 440 bytes, which allows dumping
of most of any 512-byte SPROM if one is encountered.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John
]
Signed-off-by: Gábor Stefanik [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John,
This is 2.6.26 material.
diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
index 904b1a8..57c4ccf 100644
--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -484,6 +484,11 @@ static int
]
Signed-off-by: Gabor Stefanik [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Resent without quoted-printable encoding and attachment.
John,
This is 2.6.26 material.
diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
index 904b1a8..57c4ccf 100644
--- a/drivers/ssb/pci.c
On Friday 18 April 2008 14:21:11 Johannes Berg wrote:
On Thu, 2008-04-17 at 21:35 +0200, Michael Buesch wrote:
On Thursday 17 April 2008 21:26:17 Larry Finger wrote:
Michael Buesch wrote:
On Thursday 17 April 2008 19:47:57 Larry Finger wrote:
b43-phy0 ERROR: FOUND UNSUPPORTED PHY
On Friday 18 April 2008 04:10:37 kala mazoo wrote:
Greets,
Following up on this idea of substituting sprom images;
Oops, sorry, here is the attached SPROM file.
On Tue, Apr 15, 2008 at 11:39 PM, Stefanik Gábor
wrote:
Looks like this is an Asus-specific
On Friday 18 April 2008 16:27:18 Johannes Berg wrote:
On Fri, 2008-04-18 at 15:57 +0200, Michael Buesch wrote:
Following up on this idea of substituting sprom images;
Oops, sorry, here is the attached SPROM file.
Using that sprom dump which Stefanik
On Friday 18 April 2008 16:44:58 Stefanik Gábor wrote:
That's *exactly* what I am doing at this moment. Here are my findings so
far:
WL-138G V2 comes with BoardFlags=0x0049. That would mean, no Afterburner
(among other things), even though Asus specifically advertises this card as
On Friday 18 April 2008 17:31:41 Johannes Berg wrote:
It is the BFL_BTCMOD this bit selects which GPIO pin the microcode
uses for disabling the bluetooth chip.
I think the GPIO pin is actually connected to the power amplifier
on this device. So you see what this results in. :)
So the
On Friday 18 April 2008 17:40:09 [EMAIL PROTECTED] wrote:
The current code checks for the special signature that signifies
a revision 4 SPROM. Now that a rev. 8 SPROM with a 440-byte length
has been found that may not have any special code, this check could
be relaxed. With this patch, if the
On Friday 18 April 2008 17:51:29 Stefanik Gábor wrote:
Bisection complete!
After testing numerous settings for BoardFlags, I found that the only ones
to have a benefical effect on the card is 0x4049/0x4249 and 0x0048/0x0248,
which differs from the original 0x0049 only in the BFL_BTCMOD bit,
On Friday 18 April 2008 18:17:23 Stefanik Gábor wrote:
According to the README of the Vista driver, the card supports Afterburner,
To be honest, I don't care for afterburner. It's a horrible
proprietary extension and it's (IMO) not really what people should
be using.
So I'm OK with leaving that
).
This also adds a modparam knob to help debugging this in the future,
as more devices with this bug may show up.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.26 stuff.
Index: wireless-testing/drivers/net/wireless/b43/main.c
The HostFlags are a bitmask of 48bit. So we must use an u64 datatype
to hold all bits.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.26.
There is no need to backport this to 2.6.25-stable, as the devices supported
by 2.6.25 don't use the high 16 bits of the HostFlags
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
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Thursday 17 April 2008 19:47:57 Larry Finger wrote:
b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 6, Type 5, Revision 1)
Heh, with an LP-PHY. That is not going to be supported anytime, soon, unless
somebody else shows up and writes some specifications and code.
--
Greetings Michael.
On Thursday 17 April 2008 21:26:17 Larry Finger wrote:
Michael Buesch wrote:
On Thursday 17 April 2008 19:47:57 Larry Finger wrote:
b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 6, Type 5, Revision 1)
Heh, with an LP-PHY. That is not going to be supported anytime, soon, unless
somebody
On Wednesday 16 April 2008 16:42:16 Larry Finger wrote:
Stefanik Gábor wrote:
Looks like this is an Asus-specific issue. Can you try flashing the
attached SPROM file (with a modified MAC address, of course) into your
card to see if it results in *any* transmission? (Back up your SPROM
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
On Wednesday 16 April 2008 20:36:39 Johannes Berg wrote:
On Tue, 2008-04-15 at 21:13 +0200, Michael Buesch wrote:
This adds a fastpath for the common workloads to the
MAC suspend flushing.
@@ -2340,12 +2340,20 @@ static void b43_mac_suspend(struct b43_w
or latency
disadvantage from that.
And yes, I measured this. So this is not one of these
bad Programmer Likeliness Assumptions that are always wrong. ;)
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply to 2.6.26
Stefano, you may port this, if you like to.
Index: wireless
or latency
disadvantage from that.
And yes, I measured this. So this is not one of these
bad Programmer Likeliness Assumptions that are always wrong. ;)
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Patch version without useless {}
John, please apply to 2.6.26
Stefano, you may port
On Monday 14 April 2008 01:08:53 Stefano Brivio wrote:
On Tue, 08 Apr 2008 14:11:04 -0500
Larry Finger [EMAIL PROTECTED] wrote:
1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was
finally able to read beacons; however, no output interrupts were
delivered.
[...]
On Monday 14 April 2008 02:42:55 Pavel Roskin wrote:
On Sun, 2008-04-13 at 19:36 -0500, Larry Finger wrote:
Do you have any PCI (not Cardbus) devices that work with b43? Do you
know of anyone that does?
I have MiniPCI cards with bcm4306 and bcm4318, and both are working fine
with the
On Monday 14 April 2008 16:56:56 Larry Finger wrote:
Michael Buesch wrote:
I'd really _love_ to know where to get a b43 (not legacy) device
that worked in bcm43xx and broke in b43. Somebody any pointers? Or maybe
someone
could probably donate one? We can also do things like: You ship
On Monday 14 April 2008 17:01:04 Larry Finger wrote:
Michael Buesch wrote:
What do the target_idle_tssi from SPROM and the current_idle_tssi read
from the PHY look like? They should be almost equal. If not, this could
result in a complete TX breakage.
Would an idle_tssi problem also
This fixes b43legacy for the SSB DMA API change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Stefano Brivio [EMAIL PROTECTED]
---
John, this is a bugfix for 2.6.25
Index: wireless-testing/drivers/net/wireless/b43legacy/dma.c
This fixes b43legacy for the SSB DMA API change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Stefano Brivio [EMAIL PROTECTED]
---
John, this is the fixed version of the bugfix for 2.6.25 :P
Index: wireless-testing/drivers/net/wireless/b43legacy/dma.c
On Wednesday 09 April 2008 18:13:20 Larry Finger wrote:
Michael Buesch wrote:
So, well. I'd say the new code is identical. The IHR bit is set earlier.
The INFRA bit is just bogus to set here. We set it later when selecting
the operation mode. b43legacy_adjust_opmode()
The fact
Now that we fixed the TPS flag assignment in commit
JOHN, INSERT COMMIT ID HERE
we don't need the workaround for the bcm44xx chip anymore.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply to 2.6.26.
But please insert the commit ID of
[PATCH] ssb-pcicore: Fix IRQ TPS flag
On Tuesday 08 April 2008 21:11:04 Larry Finger wrote:
Michael,
I'm gaining on my problems with 2 PCI (not Cardbus) cards, which are
as follows:
1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was
finally able to read beacons; however, no output interrupts were
On Tuesday 08 April 2008 22:56:33 Michael Buesch wrote:
On Tuesday 08 April 2008 21:11:04 Larry Finger wrote:
Michael,
I'm gaining on my problems with 2 PCI (not Cardbus) cards, which are
as follows:
1. BCM4301 - With the ssb patch fixing IRQ TPS flag handling, I was
finally
On Monday 07 April 2008 00:42:57 Larry Finger wrote:
Stefano and Michael,
In order to test Stefano's recent patches for the BCM4303 using
b43legacy, I dug out my Linksys WMP11-V27, which has a BCM4301 chip.
Implementing it is a pain as it kills my sound card - thus it must be
removed
On Tuesday 08 April 2008 00:06:00 Larry Finger wrote:
Michael Buesch wrote:
Can you add a printk here that prints the contents of
B43legacy_DMA32_TXSTATUS
and post the logs?
This could actually be a bus (ssb) problem. Not sure, yet.
Some people do see it on b43, too.
ACPI
On Sunday 06 April 2008 22:16:59 KURT PETERS wrote:
Although I found the right phy.c file in the kernel I'm using, I can't
ensure I'm making the right changes.
For instance, it seems like your refs in b43legacy_phy_xmitpower() is
different than in my b43legacy file:
max_pwr =
On Friday 04 April 2008 21:43:07 Michael Buesch wrote:
This fixes the initialization of the PHY TX control words in
shared memory. These control words are used for management frames
like beacons.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.26
Please
This fixes beacon updating in the bottomhalf.
In case the device is busy, we will defer to later in the IRQ handler.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.26 in addition to the beacon patch I sent yesterday.
drivers/net/wireless/b43/main.c | 98
This fixes the initialization of the PHY TX control words in
shared memory. These control words are used for management frames
like beacons.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.26.
This is a replacement patch for the one I sent yesterday.
Index: wireless
We must use the b43_is_mode() call to check the current interface
operation mode.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is for 2.6.26.
Index: wireless-testing/drivers/net/wireless/b43/main.c
and have nothing in
common with how broadcom does the stuff in the proprietary driver. So it's
highly experimental and I'm not responsible in case this patch eats your cat.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25-rc8-mm1/drivers/net/wireless/b43/lo.c
Can you try the following patch?
http://bu3sch.de/patches/wireless-testing/20080404-1408/patches/010-b43-calibrate-lo-on-demand.patch
This patch is supposed to distribute the calibration bursts over time,
so that calibration only happens when it's actually needed.
So instead of disabling the MAC
601 - 700 of 1753 matches
Mail list logo
