On Thursday 14 February 2008 16:59:55 bou.gui wrote:
Hi Michael and thank's for you answer.
Perhaps's your crystal ball will be more effective with the error message
when doing make command ?
yeah, I guess so
--
Greetings Michael.
___
On Saturday 16 February 2008 12:33:57 Rafał Miłecki wrote:
2008/2/16, Michael Buesch [EMAIL PROTECTED]:
On Saturday 16 February 2008 12:01:34 Rafał Miłecki wrote:
I use 4318/02 and 2.6.24 kernel. Usually everything works fine but in
some moments iwlist shows my AP a few time in the output
On Saturday 16 February 2008 12:01:34 Rafał Miłecki wrote:
I use 4318/02 and 2.6.24 kernel. Usually everything works fine but in
some moments iwlist shows my AP a few time in the output. The problem
is that as long as iwlist do that, KNetworkManager doesn't display my
AP. I wonder if this can
On Sunday 17 February 2008 21:34:40 Christian Stalp wrote:
Hello together,
I have a problem. I want to sniff a network traffic (but without a
malicious inted, just to check how many packets were retransmited (retry
flag))
Okay, the problem now is that I have to change into the
Can you please test if this fixes beaconing?
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h2008-02-21
17:10:17.0 +0100
+++
On Friday 22 February 2008 14:16:06 Johannes Berg wrote:
On Thu, 2008-02-21 at 17:57 +0100, Michael Buesch wrote:
Can you please test if this fixes beaconing?
Hmm, unfortunately not. This results in continuous beacon update
interrupts because when both templates are valid we keep them
Fix a typo.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-testing/drivers/net/wireless/b43legacy/b43legacy.h
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/b43legacy.h
2008-02-24 14:23
On Monday 25 February 2008 14:51:02 Johannes Berg wrote:
I hacked the bcm43xx driver in a linux 2.6.23 kernel to also include the
pci id of this card. Fails as expected, but maybe this dmesg info is
usefull:
bcm43xx: Chip ID 0x4312, rev 0x1
bcm43xx: Number of cores: 4
bcm43xx: Core
On Tuesday 26 February 2008 10:33:22 Mark Huijgen wrote:
[ 133.632495] b43-phy0: Broadcom 4312 WLAN found
[ 133.673220] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 6, Type 5,
Revision 1)
We don't support the LP-PHY.
--
Greetings Michael.
___
On Tuesday 26 February 2008 13:10:56 Mark Huijgen wrote:
Michael Buesch wrote:
On Tuesday 26 February 2008 10:33:22 Mark Huijgen wrote:
[ 133.632495] b43-phy0: Broadcom 4312 WLAN found
[ 133.673220] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 6, Type 5,
Revision 1)
We
On Tuesday 26 February 2008 21:45:06 Martin Marques wrote:
Johannes Berg escribió:
On Tue, 2008-02-26 at 07:34 +0100, Rafał Miłecki wrote:
I tried to find this info on
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware but I
couldn't find info about 2.6.25-rcX kernel. Which
This adds QOS support to the b43 driver.
QOS can be disabled on driver level with a module parameter for debugging
purposes.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.26
Index: wireless-testing/drivers/net/wireless/b43/b43.h
change, except less memory allocation for
the removed rings.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.26
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43
This adds a few debugging counters, that are useful for debugging the
card does not transmit or connection is unstable kind of problems.
It's also useful for tuning an RC algorithm.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.26
Index: wireless-testing/drivers/net/wireless/b43
This fixes a typo in the status report.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.26
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
On Friday 07 March 2008 19:57:57 Peter Diesner wrote:
Hi,
i compiled kernel 2.6.24 with debbuging for b43 enabled:
dmesg | grep b43
[ 38.504708] b43-phy0: Broadcom 4311 WLAN found
Use bleeding edge b43.
--
Greetings Michael.
___
Bcm43xx-dev
On Sunday 09 March 2008 17:28:33 Dad wrote:
Mar 9 12:08:22 ubuntu kernel: [ 2776.972000] ssb: Sonics Silicon
Backplane found on PCMCIA device pcmcia0.0
PCMCIA devices are not supported, yet. They don't work, yet.
We don't read the SPROM, but generate a random MAC address.
That's why you see
This adds support for reading/writing the SPROM invariants
for PCMCIA based devices.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.26.
Index: wireless-testing/drivers/ssb/Kconfig
===
--- wireless-testing.orig
From: Harvey Harrison [EMAIL PROTECTED]
Commit 61bca6eb85c863603d6054530e2f65c3b9aba85b b43: rewrite A PHY
initialization
has a typo, the result of the register read should be masked, not the
register offset.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL
On Wednesday 19 March 2008 05:37:18 kala mazoo wrote:
I'm new to this list ~ greetings all round,
I've been
following the thread on the above card for a few days now -- as luck (or
misfortune) would have it, I bought a
This fixes a DMA mapping leakage in the case where we reject a DMA
buffer because of its address.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Christian Casteyde [EMAIL PROTECTED]
---
John, this is a fix for 2.6.25.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
Remove all irqs_disabled() sanity checks, as they are not safe on
a RT-enabled kernel and will trigger bogus warnings.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply to 2.6.25
Index: wireless-testing/drivers/net/wireless/b43/debugfs.c
There's no need to compile the N-PHY support code, when the
N-PHY support is disabled in Kconfig.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply to 2.6.26
Index: wireless-testing/drivers/net/wireless/b43/Makefile
On Sunday 23 March 2008 15:11:37 kala mazoo wrote:
From: [EMAIL PROTECTED]
To: bcm43xx-dev@lists.berlios.de
Subject: Re: More on ASUS WL-138G V2
Date: Sun, 23 Mar 2008 15:04:09 +0100
CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]
On Sunday 23
On Monday 24 March 2008 05:45:46 Larry Finger wrote:
[EMAIL PROTECTED] wrote:
I'll happily pick up the cost of shipping his card to Larry if it will
make him shut up. You can send it on my FedEx code or I'll PayPal you
the cost.
If the problem is an IOMMU problem with x86_64, I
On Monday 24 March 2008 02:59:53 kala mazoo wrote:
Faith? No, seriouslypoint taken, but we do know -something-
...ie; as you indicated earlier, a few people have reported this
problem before..not just me, and so even though we don't know exactly
why it is so or which hardware
On Tuesday 25 March 2008 16:39:23 Larry Finger wrote:
Jouni and Johannes,
The correspondent below has a problem authenticating when using the
b43 driver with mac80211, but all works with bcm43xx/SoftMAC. As far
as I can tell, the problem driver is transmitting and receiving, but
still no
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
Index: wireless-testing/drivers/ssb/pcmcia.c
This adds messages for some DMA mapping failures.
These are useful for debugging DMA address problems, as they appear
on x86_64 machines with IOMMU enabled.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Please queue for 2.6.25
Index: wireless-testing/drivers/net/wireless/b43/dma.c
This fixes the IRQ routing on PCMCIA devices.
With this patch the card will finally be able to receive IRQs.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Please queue for 2.6.25
Index: wireless-testing/drivers/net/wireless/b43/pcmcia.c
is needed for 16bit PCMCIA devices, as we really don't want to poke with
the braindead DMA mechanisms on PCMCIA sockets. Additionally, not all
PCMCIA sockets do actually support DMA in 16bit mode (mine doesn't).
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for 2.6.26
On Saturday 29 March 2008, Michael Buesch wrote:
+# Data transfers to the device via PIO
+# This is only needed on PCMCIA devices. All others can do DMA properly.
+config B43_PIO
+ bool
+ depends on B43 (B43_PCMCIA || B43_FORCE_PIO)
+ default y
+
config B43_NPHY
bool
On Sunday 30 March 2008 17:10:48 Julien Muchembled wrote:
The only thing that happens on a 120-second cycle is the following
routine from drivers/net/wireless/main.c:
static void b43_periodic_every120sec(struct b43_wldev *dev)
{
struct b43_phy *phy = dev-phy;
if
On Monday 31 March 2008 15:15:03 Subodh Shrivastava wrote:
[ 2056.834017] b43-phy1 ERROR: FOUND UNSUPPORTED PHY (Analog 5, Type
4, Revision 1)
I am aware that support for this chipset is work in progress, I would
be happy to help in testing.
Help in reverse engineering is needed ;)
--
On Monday 31 March 2008 22:22:54 Stefanik Gábor wrote:
Thanks, now I got the ssb_sprom file in place, but it's completely
corrupt (0120... until the end, ssb-sprom says CRC
error, if I run it with --force -P, I get for all values). Could
someone upload an SPROM dump
connection
possible. Of course, that's only the case, if both ends use b43-qcrypto.
In the case where one STA uses legacy encryption, the card will automatically
detect this and switch back to plain old CCMP.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue this patch for linux
On Tuesday 01 April 2008 16:50:19 Mark Hagger wrote:
Excellent, did you manage to implement the time travel support mode as
well?
Sure. I used it to actually get one of those q-crypto devices to test
the code. ;)
--
Greetings Michael.
___
On Tuesday 01 April 2008 21:27:33 John W. Linville wrote:
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
: In function `ssb_attr_sprom_store':
(.text+0x1c4bb3): undefined reference to `ssb_devices_thaw'
make[1]: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply this to 2.6.26
Index: wireless-testing/drivers/ssb/main.c
On Wednesday 02 April 2008 17:54:31 Stefanik Gábor wrote:
Apparently enough died for an RMA to be accepted. I got it replaced,
now the new card is recognized (although I still can't associate with
the new b43 driver, only with bcm43xx - it gives Authentication timed
update wpa_supplicant
--
This adds support for block based I/O to SSB.
This is needed in order to efficiently support PIO data
transfers to the card.
The block-I/O support is only compiled, if it's selected by the
weird driver that needs it. So there's no overhead for sane devices.
Signed-off-by: Michael Buesch [EMAIL
This changes the b43-PIO code to use the new SSB block-I/O.
This reduces the overhead by removing lots of function calls, pointer
dereferencing, if-conditionals any byteswapping for each packet data word.
This also fixes a harmless sparse endianness warning.
Signed-off-by: Michael Buesch [EMAIL
On Wednesday 02 April 2008 21:12:34 krop wrote:
Le Wednesday 02 April 2008 20:50:59 Larry Finger, vous avez écrit :
The rev 02 BCM4306 cards that use b43legacy had much more of their
initialization done from the host and less done by the hardware (or by
the firmware). As a result, the
On Thursday 03 April 2008 12:36:48 Johannes Berg wrote:
PIO is needed for 16bit PCMCIA devices, as we really don't want to poke with
the braindead DMA mechanisms on PCMCIA sockets. Additionally, not all
PCMCIA sockets do actually support DMA in 16bit mode (mine doesn't).
Oddly, my CF
On Thursday 03 April 2008 17:27:16 Fernando Toledo wrote:
El Jue 03 Abr 2008, Holger Schurig escribió:
i continue search and found that i forgot enable the
CONFIG_INPUT_POLLDEV option.
Thanks
Shouldn't this be done automatically by a proper entry in the
Kconfig file?
yes, but i
This adds some minor stuff for N-PHY support. Nothing special.
Adds Analog switching and some TODOs for RSSI processing.
Just a patch I had floating around for quite some time now.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
This fixes some timings for pre-TBTT and synthetic PU.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for 2.6.26
Stefano, you might want to port this.
Index: wireless-testing/drivers/net/wireless/b43/b43.h
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
: Michael Buesch [EMAIL PROTECTED]
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
These are some beaconing related fixes. Basically it prevents
the card from triggering the beacon IRQ over and over again.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please apply to 2.6.26.
The fix doesn't apply to 2.6.25, as AP mode is disabled there anyway.
Index: wireless
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
Index: wireless-testing/drivers/net/wireless/b43/b43.h
On Friday 04 April 2008 22:01:53 [EMAIL PROTECTED] wrote:
Works great on my 4311 rev 01.
Thanks a lot for testing!
Michael Buesch wrote:
Hi b43 users,
Please be so kind to run lots of regression tests on the following
patch. This patch is supposed to make the LO calibration a _lot_
On Friday 04 April 2008 23:15:39 [EMAIL PROTECTED] wrote:
One time my car had a problem and the mechanic said I had to bring it in
to get it fixed. I died laughing. What,
me bring the car in? That's ridiculous. I'll wait for the new model to
be released.
Funny thing is my mechanic
On Saturday 05 April 2008 00:41:15 Larry Finger wrote:
@@ -1876,7 +1924,6 @@ void b43legacy_phy_xmitpower(struct b43l
/* Do we need to adjust anything? */
if ((radio_att_delta == 0) (baseband_att_delta == 0)) {
b43legacy_phy_lo_mark_current_used(dev);
-
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
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 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
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 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
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 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
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 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
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 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 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 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
1001 - 1100 of 1753 matches
Mail list logo
