On Tuesday 11 December 2007 22:41:49 John H. wrote:
> Is that a question?
Not really.
You know the history of this driver? I mean. It's good
that it works at all. If you need better performance
someone has to fix it, probably. You could start with it. :)
> On Dec 9, 2007 5:40 AM, Mic
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/20071
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 down
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
===
---
).
Signed-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/
On Wednesday 12 December 2007 19:50:11 Michael Buesch wrote:
> This patch fixes the transmission problems introduced by
> commit f04b3787bbce4567e28069a9ec97dcd804626ac7
>
> I'm not sure if the dummy read is really required.
> The old code does it. I think it can't hu
).
Signed-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/
On Wednesday 12 December 2007 23:48:10 Robert Allerstorfer wrote:
> Before starting wpa_supplicant:
> [EMAIL PROTECTED] ~]# dmesg | egrep 'b43|ssb|wlan0|wmaster0'
> ssb: SPROM revision 1 detected.
> ssb: Sonics Silicon Backplane found on PCI device 0001:10:12.0
> b43-phy0: Broadcom 4306 WLAN found
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 c
On Thursday 13 December 2007 18:24:34 Larry Finger wrote:
> If (!built_in && !module)
> warn that the LED will not work.
This can not happen. b43 rfkill support is disabled, as it doesn't
make any sense without rfkill-input.
> In the version I sent you, the logic is:
>
> if (!built_in) {
>
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:
>
> l
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?
h
On Friday 14 December 2007 02:12:25 Ray Lee wrote:
> Digging a little farther into it, it looks like b43 is barfing partway
> through init as the firmware file it's looking for has changed names.
> Perhaps that's the issue. I'll take a longer look at this all
> tomorrow.
http://www.linuxwireless.o
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
> bcm
/wireless/bcm43xx/ | tail -10
> 2 Sam Ravnborg
> 3 David Howells
> 3 David Woodhouse
> 3 Joe Perches
> 4 Jeff Garzik
> 5 Daniel Drake
> 6 Stefano Brivio
> 9 John W. Linville
> 48 Larry Finger
> 80 Michael Bu
On Friday 14 December 2007 13:53:27 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > This user did get the following messages in dmesg:
> >
> > b43err(dev->wl, "Firmware file \"%s\" not found "
> >
(6) 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/driver
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?
&
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 h
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:
> > > >
> > > &
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
> > every
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 la
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
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
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:
> > > >
> >
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 Mi
On Sunday 16 December 2007 03:30:16 Larry Finger wrote:
> Michael Buesch wrote:
> > 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 bette
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.
> >
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 a
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 |
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
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 |
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
> &g
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:
> >
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
> +++ dri
On Tuesday 18 December 2007 10:39:14 Ehud Gavron wrote:
> When the hardware switch is changed from OFF to ON there is a period of
> time before the hardware enables the LED to work at all.
> During this period of time the KEY_WLAN sequence has no effect. This
> means the LED is not turned on.
>
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
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 fo
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',
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
On Tuesday 18 December 2007 17:14:54 Ehud Gavron wrote:
> I've trimmed some of this.
>
> Michael Buesch wrote:
> >>> I have no idea. But I don't understand why waiting a random time up to
> >>> 1000ms fails
> >>> and a random time up to 1000
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);
> >
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,"E
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
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
On Wednesday 19 December 2007 09:11:02 Larry Finger wrote:
> >
> > or could tsc being marked as unstable have anything to do with the
> > speed of network transfers?
>
> Absolutely not.
Well, if the clocksource of the machine is unstable it _can_ cause all kinds
of weird things. If you think som
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
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 Buesch <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/b43/
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
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.
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
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.
> >
> > Sign
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: disa
rivers/net/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 2
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 woul
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 wor
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'
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/
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/wirele
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/wi
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
===
--- wirele
ted anyway. 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
===
--- w
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
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 mai
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
> t
by vs166246.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
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/
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/drive
obing 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.o
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/wirele
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
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
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 wil
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 requir
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 Broad
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
> &g
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
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
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
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
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/wirele
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
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/
This fixes the PHY routing bit handling.
This is needed for N-PHY.
No functional change to A-PHY and G-PHY code.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
For 2.6.25.
Index: wireless-2.6/drivers/net/wireless/b43
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]>
---
For 2.6.25
Index: wireless-2.6/d
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
On Thursday 10 January 2008 18:50:54 Chuck Ebbert wrote:
> Using Fedora 8 kernel 2.6.23.13-104 which was just updated
> yesterday with 2.6.25-bound patches, the adapter still drops
> every packet sent to it.
No it does not. See your log below.
> wlan0: authenticate with AP ZZZ
> wlan0
schedule.txt
2007-12-20 18:53:57.0 +0100
+++ wireless-2.6/Documentation/feature-removal-schedule.txt 2008-01-10
20:29:48.0 +0100
@@ -355,6 +355,15 @@ What: rc80211-simple rate control algori
When: 2.6.26
Files: net/mac80211/rc80211-simple.c
Why: This algorithm
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 compl
On Sunday 13 January 2008 00:08:29 Rafael J. Wysocki wrote:
> There is a problem with b43_suspend() that it (indirectly) causes
> b43_leds_exit() to be called, which attempts to unregister the leds device
> objects, which is forbidden (ie. you can't unregister and/or register devices
> during a sus
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/
=
--- wireless-2.6.orig/Documentation/feature-removal-schedule.txt
2008-01-13 13:26:18.0 +0100
+++ wireless-2.6/Documentation/feature-removal-schedule.txt 2008-01-13
14:14:29.0 +0100
@@
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/wirele
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
- rfkill_free(rfk->rfkill);
> +err_freed_rfk:
> rfk->rfkill = NULL;
> out_error:
> rfk->registered = 0;
> @@ -195,6 +197,5 @@ void b43_rfkill_exit(struct b43_wldev *d
> rfkill_unregister(rfk->rfkill);
> input_free_polled_device(rfk->
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/d
This adds some code to init the 2055 radio.
This patch adds two files "tables_nphy.h" and "tables_nphy.c"
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
For 2.6.25.
Index: wireless-2.6/drive
701 - 800 of 2290 matches
Mail list logo
