The scheduled date for the removal of old fw support was in July 2008.
However, we're not going to remove the support unless it causes a major
headache. So change the schedule from July 2008 to when it causes headaches.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Please queue for 2.6.29
On Saturday 27 December 2008 00:28:01 Ulf Dambacher wrote:
Hi Michael
I did like you wanted and wrote the following output from screen (no
digicam at hand .-(
kernel 2.6.27.9 init=/bin/bash, no modules loaded so far
modprobe b43legacy:
ssb: Core 0 found: IEEE 802.11 (cc 0x812 rev
On Saturday 27 December 2008 00:48:20 Michael Buesch wrote:
On Saturday 27 December 2008 00:28:01 Ulf Dambacher wrote:
Hi Michael
I did like you wanted and wrote the following output from screen (no
digicam at hand .-(
kernel 2.6.27.9 init=/bin/bash, no modules loaded so far
On Wednesday 24 December 2008 11:16:36 Ulf Dambacher wrote:
Matthew Garrett schrieb:
On Sat, Dec 20, 2008 at 06:08:17PM +0100, Ulf Dambacher wrote:
Hi
I hav a dell inspiron 5100 and it has no hardware button device to
toggle rfkill.
The broadcom bcm4301 card has this feature and the
On Wednesday 24 December 2008 16:58:14 Gene Heskett wrote:
With all due respect Michael, if it has been disabled by the panel switch
such
as the one on my lappy, can it not be made to emit such an error message so
that we know we have to toggle that pushbutton?
We emit a message that the
This adds detection code for the LP-PHY and SPROM
extraction code for version 8, which is needed by the LP-PHY and
newer N-PHY.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Please queue for 2.6.29
Index: wireless-testing/drivers/ssb/b43_pci_bridge.c
On Wednesday 24 December 2008 18:16:20 Ulf Dambacher wrote:
And both drivers use exactly the same code to test for the rfkill button. one
sais on the other sees off.
You must also honor the fact that you are running a completely different kernel.
It's _not_ that just one driver works, but the
On Thursday 25 December 2008 00:52:04 Johannes Berg wrote:
On Thu, 2008-12-25 at 00:39 +0100, Michael Buesch wrote:
This adds detection code for the LP-PHY and SPROM
extraction code for version 8, which is needed by the LP-PHY and
newer N-PHY.
I still get mac address ff:ff:ff:ff:ff:ff
On Thursday 25 December 2008 01:05:30 Johannes Berg wrote:
Hey,
I hope those of you who got their presents today enjoyed that. Here's
one from me for the poor souls like myself who have a Broadcom 11n chip:
I've been publishing specifications for things we have reverse
engineered, is
On Friday 19 December 2008 16:39:23 Larry Finger wrote:
Michael Buesch wrote:
This fixes some locking w.r.t. the lower MAC (firmware).
It also removes a lot of ancient IRQ-locking that's not needed anymore.
We simply suspend the MAC. That's easier and causes less trouble.
When booting
We should suspend the MAC, before we kill the radio. This gives
the MAC a chance to leave any TX/RX state and it avoids races on
the PHY/RADIO registers.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43/phy_common.c
This adds an option to dump all crypto related memory to
the kernel log.
Obviously, it should not be enabled on productive systems. ;)
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43/debugfs.c
This fixes the key handling for mac80211's new key-flags.
It also adds TX locking to the set_key handler and adds a comment why this is
required.
This doesn't fix any known bugs.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43
On modern b43 devices with core rev =3, the hardware guarantees us an
atomic 64bit read/write of the TSF, if we access the lower 32bits first.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43/main.c
On Thursday 18 December 2008 16:11:46 Mark Ryden wrote:
Hello,
Regarding on b43 drive:
As I understand, the b43 does not support power saving mode because of
some hw limitation.
It's not implemented in the driver.
Does anybody know: is there any attention to add
such a feature in hw in
On Thursday 18 December 2008 17:55:40 Mark Ryden wrote:
It's not implemented in the driver.
You mean It's not implemented in the driver firmware , as I understand
It means what I wrote.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
This fixes some locking w.r.t. the lower MAC (firmware).
It also removes a lot of ancient IRQ-locking that's not needed anymore.
We simply suspend the MAC. That's easier and causes less trouble.
Signed-off-by: Michael Buesch m...@bu3sch.de
--
Stuff for the next feature release.
Index
On Wednesday 10 December 2008 06:35:41 Larry Finger wrote:
CHECK drivers/net/wireless/b43legacy/debugfs.c
drivers/net/wireless/b43legacy/debugfs.c:243:9: warning: memset with byte
count of 131072
I know about this error and I think it's a damn stupid error.
There is a reason why the value
On Wednesday 10 December 2008 16:09:35 Matthew Garrett wrote:
I've reworked the rfkill code in b43. This ought to be more consistent
...
I'm fine with this, as long as you take over the responsibility for the whole
b43-rfkill code.
I'm not going to touch it anymore. I'm only going to fix it by
On Wednesday 10 December 2008 18:23:40 Johannes Berg wrote:
Then there's user_claim_unsupported which is set by all drivers but
rt2x00, probably because they have hardware kill switches and thus they
have to set it even if it's not strictly true, because of the lacking
separation between these
On Wednesday 10 December 2008 18:51:02 Matthew Garrett wrote:
On Wed, Dec 10, 2008 at 06:37:23PM +0100, Johannes Berg wrote:
Ok. I think the fundamental flaw here is assuming that there's just a
single state. There isn't. The device can be turned off in hardware (in
which case sw won't be
On Wednesday 10 December 2008 19:29:50 Dan Williams wrote:
On Wed, 2008-12-10 at 19:05 +0100, Johannes Berg wrote:
On Wed, 2008-12-10 at 17:51 +, Matthew Garrett wrote:
They may not be physical buttons, but we can often control this anyway.
For instance, my HP has a button that
On Wednesday 10 December 2008 22:33:34 Henrique de Moraes Holschuh wrote:
On Wed, 10 Dec 2008, Johannes Berg wrote:
On Wed, 2008-12-10 at 18:23 +0100, Johannes Berg wrote:
Then there's user_claim_unsupported which is set by all drivers but
rt2x00, probably because they have hardware kill
On Thursday 11 December 2008 01:32:37 Julian Calaby wrote:
On Thu, Dec 11, 2008 at 02:29, Johannes Berg [EMAIL PROTECTED] wrote:
On Wed, 2008-12-10 at 15:09 +, Matthew Garrett wrote:
The final change is that I removed the code for changing the wireless
state in response to the txpower
On Tuesday 02 December 2008 10:15:17 Mark Ryden wrote:
As far as I know, this driver
does support power saving mode.
No
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Tuesday 25 November 2008 06:43:22 Yuval Hager wrote:
However, I have some few interesting findings.
First, this is totally unrelated to b43, but to the PCI. I get the flawed 1's
read from lspci even without loading b43.
I played around with different video drivers and the results are:
On Monday 24 November 2008 09:49:38 Yuval Hager wrote:
On Sunday 23 November 2008, Larry Finger wrote:
From a config file posted earlier, the OP is using SLAB. Is there any point
in trying SLUB?
Another try, not sure what it means:
* Added CONFIG_SLUB and CONFIG_SLUB_DEBUG
* boot
On Sunday 23 November 2008 12:49:55 Yuval Hager wrote:
[ 182.891400] ** b43: B43_MMIO_MACCTL 0x840A0503
[ 182.891409] ** b43: SSB_TMSLOW 0x2015
[ 258.299027] irq 10: nobody cared (try booting with the irqpoll option)
Does the kernel disable the PCI device, if it ignores the
On Sunday 23 November 2008 16:42:28 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 23 November 2008 12:49:55 Yuval Hager wrote:
[ 182.891400] ** b43: B43_MMIO_MACCTL 0x840A0503
[ 182.891409] ** b43: SSB_TMSLOW 0x2015
[ 258.299027] irq 10: nobody cared (try booting
On Sunday 23 November 2008 18:55:36 Yuval Hager wrote:
On Sunday 23 November 2008, you wrote:
On Sunday 23 November 2008 16:42:28 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 23 November 2008 12:49:55 Yuval Hager wrote:
[ 182.891400] ** b43: B43_MMIO_MACCTL 0x840A0503
On Saturday 22 November 2008 07:39:24 Yuval Hager wrote:
On Friday 21 November 2008, Larry Finger wrote:
Yuval,
Michael Buesch wrote:
Can you dump PCI config space and SSB registers (TMSLOW, maybe others,
too). It looks like a random bus write disabled the device.
Please
On Saturday 22 November 2008 12:59:27 Yuval Hager wrote:
On Saturday 22 November 2008, Peter Stuge wrote:
Yuval Hager wrote:
When the wireless is working:
00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00
10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00
On Saturday 22 November 2008 16:32:08 Larry Finger wrote:
Michael Buesch wrote:
Somebody disabled MMIO and busmastering.
And somebody cleared the CACHE_LINE_SIZE register.
Are these all the read/write bits in the configuration area? Should I conclude
that someone zeroed this area?
Yeah
On Friday 21 November 2008 17:25:22 Larry Finger wrote:
A problem was recently posted to the bcm43xx mailing list that I am unable to
solve. The machine in question is an HP Mini 2133 (HP product number FU346EA)
with a BCM4312 PCIe wireless card. This card is known to work with the b43
driver
On Thursday 13 November 2008 20:10:01 Tex wrote:
I am getting stack traces (see below) on my broadcom 4318 card, they are
always started off at b43/xmit.c:76 (function
b43_plcp_get_bitrate_idx_ofdm) and mac80211/rx.c:2183 (function
__ieee80211_rx) both are hitting the WARN_ON macro
Everybody with PHY TX error, please try updated firmware from
ftp://ftp.linksys.com/opensourcecode/wrt610n/1.00.00.018/wrt610n_v1.00.00.018_us.tgz
(Yeah, big tarball. It's 87MB)
Extract the file wrt610n_v1.00.00.018_us/release/src/wl/linux/wl.o out of the
archive.
Get latest b43-tools:
git clone
On Thursday 23 October 2008 15:57:47 [EMAIL PROTECTED] wrote:
KURT PETERS wrote:
I still have the same problem here as well... except that I just went to
2.6.27.2 and still get the same problem. Last night, it seemed like my
laptop (with 4306 using the b43legacy driver) actually took
On Thursday 23 October 2008 17:13:44 KURT PETERS wrote:
Answers, as best I can, below:
KURT PETERS wrote:
I still have the same problem here as well... except that I just went to
2.6.27.2 and still get the same problem. Last night, it seemed like my
laptop (with 4306 using the b43legacy
On Thursday 23 October 2008 19:36:32 KURT PETERS wrote:
If you wanted to go over the specific suggested setup for wireshark, I'd be
happy to implement it. I don't know wireshark, so if you could eliminate
the learning curve, I'd be happy to take the data.
Just setup your testbed like the
On Thursday 23 October 2008 19:32:45 KURT PETERS wrote:
I'm using Cisco/Linksys.
I have a spare Netgear one I could try.
Please try this.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Wednesday 22 October 2008 14:51:43 John W. Linville wrote:
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.
I know about this issue.
But
On Sunday 19 October 2008 06:04:52 Brian J. Murrell wrote:
On Sat, 2008-10-18 at 19:24 -0700, [EMAIL PROTECTED] wrote:
Since you're running a custom distro for a particular branch of
hardware, have you communicated on their lists about this issue?
Not yet. I thought I would come to the
On Friday 03 October 2008 00:31:42 Larry Finger wrote:
On occasion, the PHY errors get much more serious. In dmesg, you get
the notation that 600 or 700 have been skipped. In addition, the
interface will reset.
That happens for one out of a thousand people.
--
Greetings Michael.
On Friday 03 October 2008 17:36:38 Mike VanRoy wrote:
This was happening to me but only a few errors (10), on 2.6.26.1.
After updating to 2.6.26.5, wpa_supplicant will not authenticate at all.
(BCM4318)
See, this is what I'm talking about. There's a lot of placebo involved.
There was no
On Thursday 02 October 2008 16:51:42 Rafał Miłecki wrote:
2008/10/1 Vaidas Mikalauskas [EMAIL PROTECTED]:
b43-phy0 ERROR: PHY transmission error
wlan0: No ProbeResp from current AP 00:18:e7:32:a0:a4 - assume out of range
I guess it was Larry who was talking about PHY transmission error few
On Monday 29 September 2008 23:16:20 Peter Stuge wrote:
Michael Buesch wrote:
Actually, I do know since the very first days of bcm43xx that the
loop counts are not big enough in some of these loops.
Would it make sense to double check the conditions after the loop?
No it wouldn't
On Tuesday 30 September 2008 04:52:08 Peter Stuge wrote:
Celejar wrote:
simultaneously associate with two different APs
They would at least have to be on the same channel - or I think you
would need double radios and hardware tricks?
Well, you can use PS tricks (put STA into PS mode while
On Tuesday 30 September 2008 07:50:34 Peter Stuge wrote:
Larry Finger wrote:
Which specs?
The ones generated by the reverse engineers. See
http://bcm-v4.sipsolutions.net/.
Nice work, but as it's a spec of another driver implementation rather
than hardware (or even the firmware API)
On Tuesday 30 September 2008 15:46:04 [EMAIL PROTECTED] wrote:
If I understand him correctly he's suggesting that there could be BETTER
values than those used by the reference driver. In other words, yes,
B43/B43-Legacy are based on the RE of the Windows driver but perhaps
there are better
On Tuesday 30 September 2008 16:13:53 Peter Stuge wrote:
At this point, if there are only/mostly benefits, I don't see why
deviating from the specs is bad - after all they only document
another driver, right?
The past taught us that deviations from the specs are almost certainly
hidden bugs
On Tuesday 30 September 2008 16:11:18 Holger Schurig wrote:
The b43 and b43-legacy driver are _based_ on these
specifications. There are no other specs available.
Can it be the case that the binary windows driver the spec
They didn't use a windows driver.
producer analyzed used a
On Monday 29 September 2008 20:31:58 Larry Finger wrote:
Michael,
I have started modifying my copy of b43 to see if I can locate any
coding problems that might be causing the PHY transmission errors. To
start with, I am checking all the sections that use udelay. The main
reason is that when
.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John,
This is 2.6.28 material.
Larry
---
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 7205a93..af60122 100644
--- a/drivers/net/wireless/b43
On Saturday 27 September 2008 19:55:48 Steve Brown wrote:
FWIW: Last July, I posted this patch for dma_set_mask to the linux-mips
list. It never went anywhere.
Yeah thanks. That's the correct solution, IMO.
And I don't think it can even break anything. (Could probably
uncover hidden bugs,
On Friday 26 September 2008 07:10:37 Larry Finger wrote:
Yet another BCM4306 card with the Bluetooth Coexistence SPROM programming
error has been found.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
Owners of these cards keep crawling out of the woodwork. This is
2.6.28
On Friday 26 September 2008 22:27:11 Aurelien Jarno wrote:
For SSB_BUSTYPE_SSB type devices, we need to initialize dma_mask using
coherent_dma_mask so that calls to dma_set_mask() succeed.
This is a hack IMO and the mips DMA API should be fixed.
However, I can live with it and you can add my
On Friday 26 September 2008 23:09:26 Aurelien Jarno wrote:
On Fri, Sep 26, 2008 at 10:49:25PM +0200, Michael Buesch wrote:
On Friday 26 September 2008 22:27:11 Aurelien Jarno wrote:
For SSB_BUSTYPE_SSB type devices, we need to initialize dma_mask using
coherent_dma_mask so that calls
On Friday 26 September 2008 23:42:01 Aurelien Jarno wrote:
Anyway, as I said I'm fine with this.
Ok. In which tree do you think it should be merged?
I do not care. Just merge it through some way that does actually work
and doesn't delay it for a couple of months.
--
Greetings Michael.
On Monday 22 September 2008 05:01:37 Henrique de Moraes Holschuh wrote:
As long as the drivers based on mac80211 still know it is rfkill they're
dealing with (i.e. as long as they will know they MUST NOT emit energy from
the transmitter when they're soft-blocked),
That's the only policy that
On Saturday 20 September 2008 23:02:55 Johannes Berg wrote:
On Sat, 2008-09-20 at 13:59 -0700, Luis R. Rodriguez wrote:
On Sat, Sep 20, 2008 at 1:51 PM, Johannes Berg
[EMAIL PROTECTED] wrote:
On Sat, 2008-09-20 at 17:44 +0200, Michael Buesch wrote:
On Friday 19 September 2008 21:47:38
On Sunday 21 September 2008 10:42:40 LÉVAI Dániel wrote:
Hi!
I have this device in a laptop:
05:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan
mini-PCI (rev 01)
I'm using linux kernel 2.6.26.5 with the b43 module. I'm trying to scan
for available aps. Here is what I
On Friday 19 September 2008 21:47:38 Larry Finger wrote:
An additional BCM4306 has been found with the Bluetooth coexistence
SPROM coding error.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
These devices work with bcm43xx, but not with b43. I'll let you
decide if this is a
On Thursday 18 September 2008 16:24:05 Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Larry Finger wrote:
The changes below, along with Henriques patch [PATCH] rfkill: update
LEDs for all state changes, and the reversion of commit bc19d6e make
the wireless LED toggle correctly.
On Thursday 18 September 2008 18:49:01 Larry Finger wrote:
Henrique de Moraes Holschuh wrote:
The problem is in the should.
Maybe something else than b43 (like firmware) changed the radio software
rfkill bit, and it does not match what mac80211 and userland requested
anymore.
On Thursday 18 September 2008 07:07:51 Larry Finger wrote:
Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
+++
On Thursday 18 September 2008 15:47:42 Larry Finger wrote:
Ivo van Doorn wrote:
Is dev-phy.radio_on set when mac80211 has send an instruction
to the driver to enable the radio (start() or config() callback)
or does it represent the key state in the hardware?
If it is something coming
On Thursday 18 September 2008 16:24:52 Ivo van Doorn wrote:
On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Ivo van Doorn wrote:
If it is something coming from mac80211, then you do not want
to send a SOFT_BLOCKED event since that will cause all
On Thursday 18 September 2008 16:48:36 Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Ivo van Doorn wrote:
On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2008, Larry Finger wrote:
The changes below, along with Henriques patch [PATCH] rfkill:
On Thursday 18 September 2008 19:42:28 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 15:47:42 Larry Finger wrote:
Ivo van Doorn wrote:
Is dev-phy.radio_on set when mac80211 has send an instruction
to the driver to enable
On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote:
Well no actually, when the radio state (software rfkill state in your words)
No, radio state is _not_ software rfkill state in my words.
It's an independent state.
The actual physical radio state is a combined state of the two sw and hw
On Thursday 18 September 2008 20:10:35 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote:
Well no actually, when the radio state (software rfkill state in your
words)
No, radio state is _not_ software
On Thursday 18 September 2008 20:23:21 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 20:10:35 Ivo van Doorn wrote:
On Thursday 18 September 2008, Michael Buesch wrote:
On Thursday 18 September 2008 19:48:27 Ivo van Doorn wrote
On Tuesday 16 September 2008 23:09:20 Matthew Garrett wrote:
Oh, hey, I suck. This one might stand a better chance of not falling
over.
diff --git a/drivers/net/wireless/b43/rfkill.c
b/drivers/net/wireless/b43/rfkill.c
index fec5645..991e318 100644
--- a/drivers/net/wireless/b43/rfkill.c
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
On Wednesday 17 September 2008 16:29:31 John W. Linville wrote:
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
On Wednesday 17 September 2008 17:18:22 Henrique de Moraes Holschuh wrote:
On Wed, 17 Sep 2008, Michael Buesch wrote:
On Tuesday 16 September 2008 23:09:20 Matthew Garrett wrote:
Oh, hey, I suck. This one might stand a better chance of not falling
over.
diff --git a/drivers/net
On Monday 15 September 2008 21:43:06 Larry Finger wrote:
If the system is misconfigured with CONFIG_RFKILL set but CONFIG_RFKILL_INPUT
not set, the built-in radio LEDs will not work. In the current code, no
warning
is issued.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
This is
On Tuesday 16 September 2008 15:24:12 Hendrik Sattler wrote:
Zitat von Michael Buesch [EMAIL PROTECTED]:
This is wrong. Please do something like the following:
It maybe annoying that some people don't get that but
Reading the documentation of RFKILL_INPUT, is it impossible to have
On Tuesday 16 September 2008 16:32:29 Hendrik Sattler wrote:
Zitat von Michael Buesch [EMAIL PROTECTED]:
On Tuesday 16 September 2008 15:24:12 Hendrik Sattler wrote:
Zitat von Michael Buesch [EMAIL PROTECTED]:
This is wrong. Please do something like the following:
It maybe annoying
On Tuesday 16 September 2008 16:18:34 Larry Finger wrote:
Since commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f entitled
b43/b43legacy: add RFKILL_STATE_HARD_BLOCKED support, the radio LED
no longer responds to rfkill switch events.
ATM, I do not have a fix, other than reversion of this
On Tuesday 16 September 2008 21:18:27 Carlos Corbacho wrote:
On Tuesday 16 September 2008 18:08:48 Larry Finger wrote:
I agree with Michael. From what I know, the only possible reason for
having [RFKILL_STATE_HARD_BLOCKED] would be if user space could
somehow affect the state of the
On Thursday 11 September 2008 05:37:48 Larry Finger wrote:
Lorenzo Nava wrote:
I'm not a reverse engineer, so I have no chance to check the original
code to agree (or not) with you.
Ok, the mail has Johannes in Cc. I hope that he can tell me if me and
Francesco are right or not.
On Thursday 11 September 2008 01:14:29 Peter Stuge wrote:
I'm looking at buying an HP laptop which HP claims has 4311AG wifi.
I like to use .11a whenever possible and was a little sad to see that
b43 doesn't support it.
I am curious about why. Just lack of resources, or something more
On Thursday 11 September 2008 15:24:02 Larry Finger wrote:
Lorenzo Nava wrote:
This fixes the initialization of QoS parameters.
Reported-by: Lorenzo Nava, Francesco Gringoli
Signed-off-by: Francesco Gringoli [EMAIL PROTECTED]
Acked-by: Larry Finger [EMAIL PROTECTED]
---
John,
On Wednesday 10 September 2008 00:15:14 Lorenzo Nava wrote:
Hi everybody,
I worked with the QoS parameters trying to understand why, checking
them within the firmware, they don't seems to have the correct values
even if they were set correctly by the driver.
I think that there could be
On Wednesday 10 September 2008 15:18:07 Francesco Gringoli wrote:
Hi Michael,
we are collecting every kind of material about Broadcom board, too.
Could you please point out the document with such specifications?
http://bcm-v4.sipsolutions.net/802.11/QoS
I confirm what Lorenzo wrote:
Stay on list.
I'm not going to start another private thread for this.
In general, I avoid private threads most of the time and
barely answer them. There are so many people on the list
that can answer your questions.
On Wednesday 10 September 2008 17:50:33 Francesco Gringoli wrote:
The code is
On Wednesday 10 September 2008 21:42:57 Francesco Gringoli wrote:
Hello everybody,
we found a strange behavior problem with the b43 driver. We begin
investigating this when doing some access tests with several boards:
we discovered that the Broadcom boards usually acquire the channel
On Monday 08 September 2008 07:31:55 Greg KH wrote:
On Sun, Sep 07, 2008 at 12:40:04AM +0200, Michael Buesch wrote:
On Saturday 06 September 2008 23:51:22 Larry Finger wrote:
A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using
On Sunday 07 September 2008 19:58:52 Artem Antonov wrote:
Hi!
This patch fixes hardware power control init. Now it works better :)
Hardware power control cannot work, as we don't implement major parts of it.
--- linux-2.6.27/drivers/net/wireless/b43/phy_g.c 2008-09-07
20:16:35.0
On Sunday 07 September 2008 06:30:00 [EMAIL PROTECTED] wrote:
(Please inline the patch next time.)
Acked-by: Michael Buesch [EMAIL PROTECTED]
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de
On Saturday 06 September 2008 07:04:36 [EMAIL PROTECTED] wrote:
+}
+if (phy-rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
Does this even compile?
--
Greetings Michael.
___
Bcm43xx-dev mailing list
This fixes the initialization of the default QoS parameters.
This got broken by 0b57664cf2393bc1eff594ff7e5ff26533843fe6
Reported-by: Lorenzo Nava
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window, as I'm not interested
in finding explanations
It causes compile errors on m68k and it is not needed.
Remove it.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window.
Index: wireless-testing/drivers/net/wireless/b43/phy_g.c
On Saturday 06 September 2008 20:07:15 [EMAIL PROTECTED] wrote:
correct these issues. I did see several other ways in which the code
does not match the specs. Should that be documented in the code or
should the code be conformed to the specs even if that ends up breaking
the driver?
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
On Saturday 06 September 2008 20:52:53 Larry Finger wrote:
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
On Saturday 06 September 2008 20:57:50 Johannes Berg wrote:
On Sat, 2008-09-06 at 20:55 +0200, Michael Buesch wrote:
On Saturday 06 September 2008 20:52:53 Larry Finger wrote:
Michael Buesch wrote:
On Saturday 06 September 2008 20:34:02 Larry Finger wrote:
A coding error present
[EMAIL PROTECTED]
Cc: Stable [EMAIL PROTECTED][2.6.26], [2.6.25]
Reviewed-by: Michael Buesch [EMAIL PROTECTED]
---
John,
This is a bug, not a regression. I guess under the new rules that it
is 2.6.28 material.
I wonder what the -stable rules are.
It seems really screwed
b43 had a mechanism to set default QoS parameters. Somebody
removed it, because changes in mac80211 introduced compiler
warnings for it.
A Bug was introduced. Does somebody know which patch removed that
stuff, so I don't have to dig git history?
--
Greetings Michael.
401 - 500 of 1753 matches
Mail list logo
