.
It is safe to drop these packets, as the association they belong to
is not guaranteed anymore anyway.
This is a security fix in the sense that it prevents information leakage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is upstream inside of the netdev tree.
Index: linux-2.6.24
We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please try to push this for 2.6.24. Seems quite important,
as it leaks resources and might crash the kernel.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please try to push this for 2.6.24. Seems quite important,
as it leaks resources and might crash the kernel.
Index: wireless-2.6/drivers/net/wireless/b43legacy
This fixes suspend/resume.
We must not overwrite the MAC addresses on resume. Otherwise
the card won't ACK any packets anymore.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is a bugfix that makes suspend/resume working. Without this
people need to do an interface up/down
the DMA slots in any DMA
allocation error path.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is _not_ only a theoretical problem. I saw a few packets hitting
this race condition.
John, please try to push for 2.6.24, as this is a security fix.
Stefano, this might need porting to legacy
On Tuesday 22 January 2008 00:36:45 Rafael J. Wysocki wrote:
I still don't like this function wrapping.
I'm pretty sure the additional parameter to the function is not
needed. We can check dev-suspend_in_progress to find out
if we are in a up/down or in a suspend/resume cycle.
You're
.
Better safe than sorry.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this bugfix should go into 2.6.24.
Stefano, this must be ported to b43legacy.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless
On Monday 21 January 2008, Rafael J. Wysocki wrote:
I modified the patch to implement something like this. This still is one big
patch against everything what's necessary. [BTW, in the current version
of the code, b43_resume() may leave wl-mutex locked in the error paths,
which also is fixed
-by: Michael Buesch [EMAIL PROTECTED]
---
John, as we don't support A-PHY operation, yet, we don't need to
apply this patch to 2.6.24. Please queue this patch for 2.6.25.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
On Sunday 20 January 2008, Rafael J. Wysocki wrote:
Nah, please don't obfuscate the code.
Better add a flag to struct b43_wldev and check that in the few places
that need different behaviour.
I can do that, if you prefer, but that will look worse, IMHO.
I'm pretty sure it won't. We had
This also adds lots of TODOs. Oh well. Lots of work. :)
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/nphy.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/nphy.c
We must reject new incompatible firmware early to avoid
running into strange transmission failures.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this must _only_ be applied to 2.6.24.
2.6.25 does have actual support for the new firmware.
Index: wireless-2.6/drivers/net/wireless
On Wednesday 16 January 2008 17:58:26 Gavin McCullagh wrote:
Hi,
On Wed, 16 Jan 2008, Larry Finger wrote:
Please check that modules rfkill and rfkill-input are configured and loaded
on your system. In your dmesg output, you are missing lines that look like
Registered led device:
On Wednesday 16 January 2008 23:00:09 Gavin McCullagh wrote:
Hi,
On Wed, 16 Jan 2008, Michael Buesch wrote:
dmesg | grep led
produces no output whatsoever.
Can you please post the SPROM data?
$ cat $(find /sys -name ssb_sprom)
[EMAIL PROTECTED]:~# cat $(find /sys
On Tuesday 15 January 2008 20:15:38 Stefano Brivio wrote:
On Tue, 15 Jan 2008 13:27:42 -0500
Pavel Roskin [EMAIL PROTECTED] wrote:
I have finally found some time and hardware to test it, but the tarball
is overwhelming at its 186M. And the worst thing, the server
disconnected after 30M
On Tuesday 15 January 2008 23:21:40 Michael Buesch wrote:
Yep, the berlios stuff is dropped completely, except the download
section for the fwcutter tarballs. But that may also change in future.
We will announce that on linuxwireless.org.
Actually, I think I will change that _now_.
I'll simply
This adds lots of N-PHY related lookup tables.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/tables_nphy.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43
This fixes reading of the high 16 bits of the radio ID
on new devices. 2055 radios want lo16 to be read first.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/main.c
Add the register definitions for the Broadcom 2055 N-radio.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/nphy.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43
On Sunday 13 January 2008 18:08:57 Alan Stern wrote:
On Sun, 13 Jan 2008, Rafael J. Wysocki wrote:
On Sunday, 13 of January 2008, Michael Buesch wrote:
On Sunday 13 January 2008 00:08:29 Rafael J. Wysocki wrote:
There is a problem with b43_suspend() that it (indirectly) causes
rfkill_unregister(rfk-rfkill);
input_free_polled_device(rfk-poll_dev);
rfk-poll_dev = NULL;
- rfkill_free(rfk-rfkill);
rfk-rfkill = NULL;
}
Acked-by: Michael Buesch [EMAIL PROTECTED]
--
Greetings Michael.
___
Bcm43xx-dev
Add boardflags-high.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
For 2.6.25
Index: wireless-2.6/drivers/ssb/pci.c
===
--- wireless-2.6.orig/drivers/ssb/pci.c 2008-01-09 16:59:33.0 +0100
+++ wireless-2.6/drivers/ssb
On Sunday 13 January 2008 22:20:52 Eric Paris wrote:
inside b43_rfkill_exit() we call rfkill_unregister() which puts the last
reference and frees the rfkill struct. Then just 3 lines later the code
explicitly calls rfkill_free() on the struct we already freed. This
showed up as slub
On Friday 11 January 2008 17:40:04 Larry Finger wrote:
Michael Buesch wrote:
This patch adds support for new firmware.
Please test this on old and new firmware.
I have tested this patch with old firmware. It seems to work; however my
testing is not complete as
my computer has started
readability/maintainability
+ and slightly hurts runtime performance. Bugfixes for the old firmware
+ are not provided by Broadcom anymore.
+Who: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/phy.h
This patch adds all register definitions for the N-PHY.
This adds two new files: nphy.h and nphy.c
No functional changes to existing code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Stuff for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/nphy.h
This fixes a sparse warning about weird locking.
The spinlock is not needed, so simply remove it.
This also adds some sanity checks to the PHY and radio locking
to protect against recursive locking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch is only compiletime tested
On Tuesday 08 January 2008 16:31:53 David Ellingsworth wrote:
mac80211 supposedly has support for packet injection. Like you however, I
have have not been able to get packet injection to work with the
b43/b43legacy drivers and the developers have expressed that they are not
interested in
On Tuesday 08 January 2008 21:23:18 Daniel wrote:
Hello,
Johannes Berg wrote:
mac80211 has support for packet injection and people say it works.
This is a very good point, mac80211 (if patched) can handle packet
injection.
It should work without any patches.
The patch is in the
This adds the initval filenames for the N-PHY firmware.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Stuff for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43
The b43 driver will need an incompatible firmware upgrade, soon.
I'm probably going to do this in 2.6.25 or 2.6.26.
The update will require people to download and extract updated
officially supported firmware. The firmware will be linked to
from the usual place at linuxwireless.org.
The driver
On Sunday 06 January 2008 21:05:23 Hendrik Sattler wrote:
Am Sonntag 06 Januar 2008 schrieb Michael Buesch:
The b43 driver will need an incompatible firmware upgrade, soon.
I'm probably going to do this in 2.6.25 or 2.6.26.
The update will require people to download and extract updated
On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote:
Quoting Michael Buesch [EMAIL PROTECTED]:
see fwpostfix module parameter
Can we please avoid this annoyance this time?
Go and complain at Broadcom please.
--
Greetings Michael.
___
Bcm43xx
On Sunday 06 January 2008 21:34:35 John W. Linville wrote:
On Sun, Jan 06, 2008 at 06:02:38PM +0100, Michael Buesch wrote:
This is needed in order to add support for new devices (N-PHY).
Broadcom changed the ABI of the firmware, so we are forced to also
change the ABI of the driver.
Do
On Sunday 06 January 2008 23:01:00 John W. Linville wrote:
On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote:
On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote:
Quoting Michael Buesch [EMAIL PROTECTED]:
see fwpostfix module parameter
Can we please avoid
On Monday 07 January 2008 00:28:15 Rafael J. Wysocki wrote:
On Monday, 7 of January 2008, Michael Buesch wrote:
On Sunday 06 January 2008 23:01:00 John W. Linville wrote:
On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote:
On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote
On Monday 07 January 2008 00:51:55 Rafael J. Wysocki wrote:
On Monday, 7 of January 2008, Michael Buesch wrote:
On Monday 07 January 2008 00:28:15 Rafael J. Wysocki wrote:
On Monday, 7 of January 2008, Michael Buesch wrote:
On Sunday 06 January 2008 23:01:00 John W. Linville wrote
On Monday 07 January 2008 01:12:25 Rafał Miłecki wrote:
2008/1/7, Michael Buesch [EMAIL PROTECTED]:
People don't want N-PHY support?
Well, if your definition of people is similar to my one, they
definitely want it! :-) I think we are just a little afraid of
_possible_ problem with a few
On Friday 04 January 2008, Michael Buesch wrote:
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
I'm sorry, this patch was the wrong one.
I'll immediately send the correct one
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
This is patch version 2. Sorry for the inconvenience.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
simply remove the BROKEN dependency
and enable the option in the kernel config.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===
--- wireless-2.6.orig/drivers/net
This fixes all WARN_ON()s in the attach stage.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is stuff for 2.6.25
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
===
--- wireless-2.6.orig/drivers/net/wireless/b43/b43
This will make sure that always the correct core is selected, even if
there are both a PCI and PCI-E core on a PCI or PCI-E card.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this is a bugfix it should probably go into 2.6.24.
Index: wireless-2.6/drivers/ssb/scan.c
This adds the PCI ID 0x4329 for the BCM43XG.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is stuff for 2.6.25
Index: wireless-2.6/drivers/ssb/b43_pci_bridge.c
===
--- wireless-2.6.orig/drivers/ssb
. They will be fixed later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, as this is a bugfix, it should go into 2.6.24 if still possible.
Index: wireless-2.6/drivers/net/wireless/b43/xmit.c
===
--- wireless-2.6.orig
On Wednesday 02 January 2008 19:52:08 Larry Finger wrote:
Michael Buesch wrote:
This patch fixes the parsing of the RX data header channel field.
The current code parses the header incorrectly and passes a wrong
channel number and frequency for each frame to mac80211.
The FIXMEs added
On Wednesday 02 January 2008 20:37:41 Ehud Gavron wrote:
Happy New Year, Michael!
:)
Yeah, thanks. :)
Happy New Year to everyone on the list.
Let's work on making The Linux Wireless Year (tm) out of it.
--
Greetings Michael.
___
Bcm43xx-dev
On Wednesday 02 January 2008 21:18:29 David Ellingsworth wrote:
While using the b43legacy driver with my 4306 card, wpa_supplicant and
iwconfig both report that the device is busy when trying to switch from
monitor mode to managed mode after having used kismet or airodump-ng. So far
the
.vserver.de with esmtpa (Exim 4.63)
(envelope-from [EMAIL PROTECTED])
id 1JAAl5-0004Yv-Ft; Wed, 02 Jan 2008 21:04:15 +
From: Michael Buesch [EMAIL PROTECTED]
To: bcm43xx-dev@lists.berlios.de,
[EMAIL PROTECTED]
Subject: Re: Device busy error
Date: Wed, 2 Jan 2008 22:03:40 +0100
Use the length of the variable section of the beacon instead of the
whole beacon length for bounds checking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6
/wireless/b43/pio.c
to remove the main PIO support code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/Kconfig
===
--- wireless-2.6.orig/drivers/net/wireless/b43/Kconfig 2007-12-26
14:31
Fix writing of some wakeup times.
The MMIO write does not change in functionality.
But I think the SHM writes are wrong. I think they are the old v3 firmware
API. It seems that this stuff moved in the v4 firmware API.
I guess that the old 0x416 offset is the PRETBTT offset in the new API.
That
This adds some definitions for the MAC Control register
and uses them.
This basically is no functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this can probably be applied for 2.6.25. I don't care much.
This is some pre-work to get to get AP and IBSS working better
This adds some definitions for the MAC Control register
and uses them.
This basically is no functional change.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This is patch version 2.
Forgot to run a quilt refresh. Sorry.
John, this can probably be applied for 2.6.25. I don't care much
This fixes uploading of the beacon data and writing of the
TIM and DTIM offsets.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless
This fixes the template upload locking.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/main.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/main.c
This queues frames flagged as send after DTIM by mac80211
on the special multicast queue. The firmware will take care
to send the packet after the DTIM.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, this is 2.6.25 stuff.
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
On Sunday 23 December 2007 13:36:31 Shourya Sarcar wrote:
Michael Buesch wrote:
This fixes extraction of some values from the SPROM.
It mainly fixes extraction of antenna related values, which
is needed for another b43 fix sent later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED
On Sunday 23 December 2007 20:39:18 Larry Finger wrote:
With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module,
which should be loaded by
the ssb module, fails with the following type of message:
ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
b43: disagrees
This fixes extraction of some values from the SPROM.
It mainly fixes extraction of antenna related values, which
is needed for another b43 fix sent later.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/ssb/pci.c
This fixes chip access validation for newer devices
(4318 and up, I think)
This patch fixes probing of a PCMCIA based 4318 device.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/b43.h
it's OK.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/ssb/pcmcia.c
===
--- wireless-2.6.orig/drivers/ssb/pcmcia.c 2007-12-09 21:33:20.0
+0100
+++ wireless-2.6/drivers/ssb/pcmcia.c 2007-12
On Saturday 22 December 2007 22:55:38 Larry Finger wrote:
Michael Buesch wrote:
This fixes antenna selection in b43. It adds a sanity check
for the antenna numbers we get from mac80211.
This patch depends on
[PATCH] ssb: Fix extraction of values from SPROM
Signed-off-by: Michael
On Tuesday 18 December 2007 06:42:56 Ehud Gavron wrote:
A little test code answered my own question. I don't know if this is
the best way to do it, but this patch fixes the problem.
Ehud
--- drivers/net/wireless/b43/rfkill.c.orig 2007-12-17
22:39:31.0 -0700
+++
On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote:
Ehud Gavron wrote:
If I manually turn the LED on (with the keyboard sequence for
KEY_WLAN), rfkill will turn the LED off when I turn the radio off
consistently but without the wait will never turn the LED back on.
That makes no
On Tuesday 18 December 2007 13:31:20 Ehud Gavron wrote:
Michael Buesch wrote:
On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote:
Ehud Gavron wrote:
If I manually turn the LED on (with the keyboard sequence for
KEY_WLAN), rfkill will turn the LED off when I turn
On Tuesday 18 December 2007 12:36:02 Robert Allerstorfer wrote:
On Mon, 17 Dec 2007, 15:14 GMT+01 Michael Buesch wrote:
Please test what I suggested.
done. I have recompiled and replaced the original b43.ko from
'kernel-2.6.23.9-90.fc8.src.rpm', with the modified 'phy.c' [if
(B43_DEBUG
On Tuesday 18 December 2007 15:41:04 Ehud Gavron wrote:
Michael Buesch wrote:
On Tuesday 18 December 2007 13:31:20 Ehud Gavron wrote:
Michael Buesch wrote:
On Tuesday 18 December 2007 12:37:04 Ehud Gavron wrote:
Ehud Gavron wrote:
If I
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change)) {
b43info(wl,EHUD: sleeping\n);
msleep(1);
b43info(wl,EHUD: LED coming on\n);
input_report_key
On Tuesday 18 December 2007 18:33:43 Michael Buesch wrote:
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change)) {
b43info(wl,EHUD: sleeping\n);
msleep(1);
b43info(wl
On Tuesday 18 December 2007 19:39:15 Ehud Gavron wrote:
Michael Buesch wrote:
On Tuesday 18 December 2007 18:33:43 Michael Buesch wrote:
On Tuesday 18 December 2007 18:29:34 Michael Buesch wrote:
And here's the code:
if (unlikely(report_change
On Tuesday 18 December 2007 22:09:24 Ehud Gavron wrote:
I did just check and you are right! It is a compiler bug despite the
version being supposedly safe.
two msleep(0); 's got inlined out of the way and the KEY_WLAN code ran
as it's supposed to.
I can't find gcc 4.3 on gnu's site and
On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 1:52 AM, Larry Finger [EMAIL PROTECTED] wrote:
One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the
former always used a fixed
rate; whereas mac80211 tries to adjust the bit rate according
On Monday 17 December 2007 02:46:29 Robert Allerstorfer wrote:
On Thu, 13 Dec 2007, 00:20 GMT+01 Michael Buesch wrote:
On Wednesday 12 December 2007 23:48:10 Robert Allerstorfer wrote:
Before starting wpa_supplicant:
[EMAIL PROTECTED] ~]# dmesg | egrep 'b43|ssb|wlan0|wmaster0'
ssb
On Monday 17 December 2007 13:49:00 Robert Allerstorfer wrote:
On Mon, 17 Dec 2007, 11:00 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 02:46:29 Robert Allerstorfer wrote:
The strange thing is that the b43-phy0 debug: !WARNING!... line
disappeared from the dmesg output after I
On Monday 17 December 2007 14:43:37 Robert Allerstorfer wrote:
On Mon, 17 Dec 2007, 13:53 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 13:49:00 Robert Allerstorfer wrote:
After
rebooting several times, the output of dmesg | egrep
'b43|ssb|wlan0|wmaster0' sometimes contains
On Monday 17 December 2007 15:09:32 Robert Allerstorfer wrote:
On Mon, 17 Dec 2007, 14:46 GMT+01 Michael Buesch wrote:
On Monday 17 December 2007 14:43:37 Robert Allerstorfer wrote:
But shouldn't setting/unsetting B43_DEBUG only affect the verbosity
level of the kernel messages
On Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 5:35 AM, [EMAIL PROTECTED] wrote:
If this is a mac80211 related problem, then other systems connecting
to the same ap and using mac80211 would also be affected? Like I said
earlier, there are five machines
On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 5:45 PM, Michael Buesch [EMAIL PROTECTED] wrote:
Ehm, excuse me.
What are you doing exactly? In this thread you told me you have
a device which requires b43:
Well, I'm not sure what you mean by requires b43
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote:
* John W. Linville [EMAIL PROTECTED] wrote:
It's not that simple. For example, regression testing will be a
major PITA if one needs to switch back and forth from the new driver
to the old one in the process.
Not really
On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote:
On Friday, 14 of December 2007, Michael Buesch wrote:
On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
This user did get the following messages in dmesg:
b43err(dev-wl, Firmware file \%s\ not found
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
Well, the only problem with that is I suspect there are some newer cards
that
work better with v3 firmware, although they are supposed to support both.
And I suspect that you are wrong until you show me one. :)
--
Greetings
On Friday 14 December 2007 01:55:50 Harvey Harrison wrote:
On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote:
Oh come on. b43 is more than a year old now. How long should we wait?
Two or three? Forever?
Any pointers to the advantages of b43?
http://www.linuxwireless.org/en/users
On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
This user did get the following messages in dmesg:
b43err(dev-wl, Firmware file \%s\ not found
or load failed.\n, path);
So the question seems to be why b43 needs version 4, when b43legacy and
bcm43x uses version
Brivio
9 John W. Linville
48 Larry Finger
80 Michael Buesch
so it's not like someone else messed it up and that you would be
incapable of getting it all work nicely and make the migration of users
smoother. And if udev is a hindrance to you, reduce your driver's
) A circular mutex locking situation existed.
(7) If rfkill-input is built as a module, it is not automatically loaded.
This patch fixes all of the above.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
On Friday 14 December 2007 13:16:17 Ingo Molnar wrote:
* Michael Buesch [EMAIL PROTECTED] wrote:
The testers who did nothing but reported that the new driver did not
work on their hardware.
Which testers?
right in this thread Ray Lee is reporting:
| | Digging a little
On Friday 14 December 2007 17:45:52 Ray Lee wrote:
On Dec 14, 2007 8:27 AM, Ray Lee [EMAIL PROTECTED] wrote:
On Dec 14, 2007 6:40 AM, [EMAIL PROTECTED] wrote:
Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
suggests other ways to smooth out the transition. I haven't read
On Friday 14 December 2007 17:06:39 Ray Lee wrote:
Hi all. Perhaps I can inject some facts into this?
On Dec 14, 2007 5:08 AM, Michael Buesch [EMAIL PROTECTED] wrote:
This user did get the following messages in dmesg:
b43err(dev-wl, Firmware file \%s\ not found
or load
On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
* Michael Buesch [EMAIL PROTECTED] wrote:
In my opinion this all is the work of the distributions and not the
work of the kernel developers. Distributions have to make sure that
everything works after a kernel update
On Friday 14 December 2007 19:01:51 Ray Lee wrote:
No, I don't have module autoloading disabled. modprobe-ing b43
automatically loads ssb. Neither, however, will load rfkill or
rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
silent during load. Nothing to dmesg at all.
On Friday 14 December 2007 19:45:02 Ray Lee wrote:
One problem related to b43 source code, patch exists, has yet to be
merged upstream.
Yeah. A problem preventing a LED from blinking.
That's a real regression Come on. Stop that bullshit.
I'm going to say this one last time. If
On Friday 14 December 2007 20:25:39 Ray Lee wrote:
I'm sorry. The patch that _you_ quoted fixes a blinking LED
and nothing else.
Well, you're wrong. Sorry, but that's just the way it is. See below.
It does _not_ fix loading of rfkill or b43 in any way.
It does, however, fix loading of
On Friday 14 December 2007 20:55:43 Ray Lee wrote:
Oh. My. God.
Michael. I have a degree in Physics. I placed sixth in the world
finals of the ACM Collegiate programming contest in 1999, Cal Poly
Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
, I'm the guy all the
On Thursday 13 December 2007 06:32:11 Larry Finger wrote:
Michael,
I finally found the problem. It turned out that b43_rfkill_soft_toggle()
was returning -EBUSY even when there was no error. I also changed the
Oh, damn. :)
logic in the request_module(rfkill-input) section. Now, the code is
On Friday 14 December 2007 01:05:00 Ray Lee wrote:
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lo
On Wednesday 12 December 2007 09:21:26 Pavel Roskin wrote:
Quoting Larry Finger [EMAIL PROTECTED]:
Michael Buesch wrote:
Here's an updated version that should fix even more bugs:
http://bu3sch.de/patches/wireless-2.6/20071211-1622/patches/005-b43-fix-init-rewrite-breakage.patch
I had
On Wednesday 12 December 2007 04:16:22 Brennan Ashton wrote:
On Dec 11, 2007 3:02 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Tuesday 11 December 2007 02:14:05 Brennan Ashton wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=412861
I downloaded the source for 2.6.23.8-63.fc8.src.rpm
, it is not automatically loaded.
This patch fixes all of the above.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/rfkill.c
===
--- wireless-2.6.orig/drivers
-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/b43/wa.c
===
--- wireless-2.6.orig/drivers/net/wireless/b43/wa.c 2007-12-11
01:08:40.0 +0100
+++ wireless-2.6/drivers/net/wireless/b43/wa.c
801 - 900 of 1753 matches
Mail list logo
