Signed-Off-By: Daniel Walker <dwalker@mvista.com>
---

 drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |   30 ++++++++++++-------------

 1 file changed, 15 insertions(+), 15 deletions(-)
Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c

===================================================================

--- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c

+++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c

@@ -43,7 +43,7 @@
 static struct bcm43xx_debugfs fs;

 static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];

-static DECLARE_MUTEX(big_buffer_sem);

+static DEFINE_MUTEX(big_buffer_mutex);
 static ssize_t write_file_dummy(struct file *file, const char __user *buf,

@@ -75,7 +75,7 @@ static ssize_t devinfo_read_file(struct

 	u16 tmp16;

 	int i;
-	down(&big_buffer_sem);

+	mutex_lock(&big_buffer_mutex);
 	mutex_lock(&bcm->mutex);

 	spin_lock_irqsave(&bcm->irq_lock, flags);

@@ -125,7 +125,7 @@ out:

 	spin_unlock_irqrestore(&bcm->irq_lock, flags);

 	mutex_unlock(&bcm->mutex);

 	res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);

-	up(&big_buffer_sem);

+	mutex_unlock(&big_buffer_mutex);

 	return res;

 }
@@ -138,14 +138,14 @@ static ssize_t drvinfo_read_file(struct

 	size_t pos = 0;

 	ssize_t res;
-	down(&big_buffer_sem);

+	mutex_lock(&big_buffer_mutex);
 	/* This is where the information is written to the "driver" file */

 	fappend(KBUILD_MODNAME " driver\n");

 	fappend("Compiled at: %s %s\n", __DATE__, __TIME__);
 	res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);

-	up(&big_buffer_sem);

+	mutex_unlock(&big_buffer_mutex);

 	return res;

 }
@@ -160,7 +160,7 @@ static ssize_t spromdump_read_file(struc

 	ssize_t res;

 	unsigned long flags;
-	down(&big_buffer_sem);

+	mutex_lock(&big_buffer_mutex);

 	mutex_lock(&bcm->mutex);

 	spin_lock_irqsave(&bcm->irq_lock, flags);

 	if (bcm43xx_s...
[ message continues ]

This driver is scheduled for removal, so I'd not touch it anymore

to avoid the possibility to introduce a lastminute regression.

The new drivers (b43 and b43legacy) have this fixed (in a different

way by completely removing it).
--

Greetings Michael.

--

Uhm, hijacking the thread a bit here, but which driver is supposed to

be supporting my 4309? Neither b43 nor b43legacy found my wireless,

and I'm not seeing its PCI ID anywhere either of those...
$ lspci -s 02:02 -v;  lspci -n -s 02:02 -v -x

02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)

        Subsystem: Hewlett-Packard Company Unknown device 12f9

        Flags: bus master, fast devsel, latency 64, IRQ 22

        Memory at d0010000 (32-bit, non-prefetchable) [size=8K]
02:02.0 0280: 14e4:4324 (rev 03)

        Subsystem: 103c:12f9

        Flags: bus master, fast devsel, latency 64, IRQ 22

        Memory at d0010000 (32-bit, non-prefetchable) [size=8K]

00: e4 14 24 43 06 00 00 00 03 00 80 02 00 40 00 00

10: 00 00 01 d0 00 00 00 00 00 00 00 00 00 00 00 00

20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 f9 12

30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00

--

The device is supported by b43.

The PCI ID is in the SSB PCI bridge code
static const struct pci_device_id b43_pci_bridge_tbl[] = {

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4301) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },

        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4328) },

        { 0, },

};

MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
--

Greetings Michael.

--

Ah, thanks, so it is. Well, doing an `rmmod bcm43xx ; modprobe ssb

b43` gives me nothing in dmesg other than lines related to the bcm43xx

driver. iwconfig/ifconfig do not see the interface either.
<goes and reads bcm43xx-dev archives>
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        no wireless extensions.

eth0      no wireless extensions.

tun0      no wireless extensions.

eth1      no wireless extensions.

wlan0_rename  IEEE 802.11g  ESSID:""

          Mode:Managed  Channel:0  Access Point: Not-Associated

          Tx-Power=0 dBm

          Retry min limit:7   RTS thr:off   Fragment thr=2346 B

          Link Quality:0  Signal level:0  Noise level:0

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
(eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
`ifconfig` doesn't see eth1 or wlan0_rename.
What else might I be doing wrong? Regardless, perhaps scheduling

bcm43xx for removal in 2.6.26 is a bit premature.

--

I don't know. Try ifconfig -a
Oh come on. b43 is more than a year old now. How long should we wait?

Two or three? Forever?
--

Greetings Michael.

--

Your udev rules are screwed up. In /etc/udev/rules.d/70-persistent-net.rules, you should have a line

that looks like
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1a:73:6b:28:5a", ATTR{type}=="1", NAME="eth1"
with the MAC address for your device. You probably have the ATTR{type}=="1" clause missing.
Larry

--

Uhm, I haven't had to tell udev to not crap up any of my *other*

devices, why is b43 special? I'm using an up-to-date userspace, so I'm

not going to be the only one hitting this problem. And ifconfig -a

does indeed show it, sorry about that. But my understanding is that

udev renames interfaces based on MAC address, so I wouldn't suspect

udev to be at fault here.
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
Well, it only hit the main kernel October 10th. That means no final

point release of the kernel.org kernel has even had it included! So

testing-wise, you still haven't hit the hordes yet. Scheduling a

removal of bcm43xx (as painful as that code is [*]), seems either

premature or very optimistic. So, how about scheduling the removal

once you get a feel for the bug reports that'll come in once 2.6.24 is

released.
   [*] Yeah, even as a user the code is painful. It *still* locks my

keyboard if I happen to disable the wireless while it's scanning. The

sooner bcm43xx is dead, the better. But b43 is quite obviously not a

full replacement for everyone.
I don't mean to come off harsh, I know you put an amazing amount of

work into both b43 and bcm43xx, and I'm thankful for that. But

requiring the end-user to go scan bcm43xx-dev archives to find out

that the b43 module isn't correctly autoloading all of its

dependencies is a sign that the code still hasn't had a lot of

testing, no?
In the meantime I'll keep plugging away at trying to figure out what's wrong.
Ray

--

I'm pretty sure it is.

Please carefully read the instructions on

http://www.linuxwireless.org/en/users/Drivers/b43

especially for firmware installation.

It will work very well.
--

Greetings Michael.

--

it's sad that you are trying to force testers to upgrade to your new

driver by threatening to unsupport the old driver. The testers who did

nothing but reported that the new driver did not work on their hardware.
You can write new drivers but you must not break existing users. That's

true for every single piece of the kernel. It is _your_ responsibility

to get that rule right - and if it does not work out of box (no matter

whom to blame, udev or the driver) you dont get to remove the driver

from the upstream kernel.
Yes, you can then "unsupport it" in spite and be a prick about it in

general but that will only talk of your own personal qualities and will

sharply reduce your credibility as a maintainer (and eventually hinder

your ability to introduce new code) - users will still have the code

available and will have a chance to fix the driver that happens to work.

(and perhaps another, capable, but friendler maintainer arises.) And

that old code will be a clot to drag around, hindering your 'new'

wireless code all along.
I really dont know why it's so hard to understand: new is totally

useless if it does not work for old setups 100% of the time. And people

_WANT_ to use your new code, so it's not like you have to pull their

hairs to get your stuff tested. And YOU wrote the old code in large

part:
 $ git-authors drivers/net/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 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

dependence on udev breakages.
	Ingo

--

I dropped maintainance for bcm43xx over a year ago.

So I am not going to catch it up again. b43 works fine.

I don't see a reason to support bcm43xx anymore.

Currently bcm43xx is orphaned, as Larry couldn't support it
Which testers?

Ray Lee didn't even install the firmware. So it can't work by definition.
So new code is included in the Linux kernel based only on political

considerations instead on technical?

I'm not sure what's the matter. Show me _one_ person for whom

bcm43xx works and b43/legacy does not. And I will immediately stop
I'm not sure what you are talking about.

If udev renames the device to something stupid (like wlan0_rename)

that is not my fault. That is the fault of a big Linux Distribution

messing udev config up.
Let's summarise it:

I don't know a single user for whom bcm43xx works but b43 does not.

In most cases b43 does work a _lot_ better than bcm43xx.

If you show me one person for whom bcm43xx works but b43 does not I

will stop removal of the driver.
--

Greetings Michael.

--

right in this thread Ray Lee is reporting:
| | 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.
you are really in denial of reality. Just re-read this thread. Upon

re-reading this thread, try to imagine that you are in place of Ray Lee

(might be hard), that you had a working bcm43xx driver and that now you

try to get b43 to work. You are not a kernel hacker who knows this

driver, just an advanced user who'd like to give you some more feedback

about your shiny new code. From that perspective, do you think your

replies were fine, constructive and involved the tester? I sure read

them as dismissive, they had an annoyed tone (i'm not sure why - he was

trying to get _YOUR_ code to work) and were borderline arrogant. Looking

at the replies from Ray Lee it sure seemed to me he had a similar

impression. In place of Ray Lee, would you report new bugs to the

maintainer of b43? I sure as hell would avoid it if i could. Do you

think such incidents help Linux in the long run?
which questions your basic skills of reading or of empathy. Why is a

reasonable firmware blob not included in the kernel? If not, why doesnt

the b43 driver warn in the dmesg (where Ray Lee did look) that no

firmware was loaded? These are basic driver usability issues, and of 
huh? This is nothing "political". It's the basic rule of maintenance:

try to be a good maintainer, involve people, forgive their newbie

mistakes. It's like the driving principle of Intenret protocols: be

conservative at what you xmit and be liberal at what you rx.
	Ingo

--

This user did get the following messages in dmesg:
b43err(dev->wl, "Firmware file \"%s\" not found "

       "or load failed.\n", path);

b43err(wl, "You must go to "

       "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "

       "and download the correct firmware (version 4).\n");
I'm not sure how I can improve that even more. There is a full URL

describing how to get the device workin in _full_ detail.
Yes. I know people don't read messages and immediately report

a "regression". But that is not my fault. Not in this case.
It's not rocket science to get b43 working. The way firmware is

installed did not change at all. (b43-fwcutter is still used).

So it's the very same procedure that user X already successfully

did when installing bcm43xx.
What should I do to improve the situation? Writing the message

all in uppercase? Maybe. I can do a patch, if people finally start reading
That's not what my problem is here.

The problem is that every now and then people come up and say that

b43 is crap and doesn't work for them while bcm43xx does. In _every_

single case it was the user's fault. Mostly not reading the kernel

message I quoted above.
So I'm not sure what I have to do now? Defer removal of an obsolete

and unstable piece of junk because some people don't read kernel

logs in case something doesn't work?
--

Greetings Michael.

--

well i dont have this hardware, but the following description in this

thread seems to contradict that:
|| Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in

|| dmesg other than lines related to the bcm43xx driver.

|| iwconfig/ifconfig do not see the interface either.
	Ingo

--

Let's quote another of Ray's statements:

"And ifconfig -a does indeed show it, sorry about that."
So if he did then try to initialize that device, that clearly

_did_ show up in a standard place where network devices are

expected to show up, he did see the message I quoted.

Well, what if he did not try to initialize the device by doing

an "ifconfig wlanX up"? That can hardly be my fault, right?
--

Greetings Michael.

--

Hi all. Perhaps I can inject some facts into this?
Yes, but only if you load rfkill-input and rfkill by hand, prior.

Without those, dmesg is entirely silent, and nothing works even to the

stage that I got it to last night. I had to search the bcm43xx-dev

archives to find that out, and it was a message from Larry saying that

he'd finally tracked down why it was working for some people and not

others -- some of us build fully modular kernels.
That I'm one of the first people to hit that makes me think that your

testing base so far has been miniscule.
Once I did that, the dmesg after loading did indeed contain the URL,
Heeeeellooooo? I tried that. It failed. What *I'm* talking about here

is that this everyone needs to be aware that this is *not* a drop in

replacement for bcm43xx, and if I'm having problems (not a kernel

hacker, but I make my living writing code), then sheesh, you're gonna

have a flood of people needing hand-holding on this.
I still don't understand why bcm43xx is sane enough to create an eth1

entry, and b43 needs more handholding, but I'm going to hold off on

commenting farther on that until I download the newer firmware. As it

stands, I haven't given b43 an honest test yet.
Please keep in mind that I'm really just trying to report my issues

with the code before others hit the same thing, and trying to do this

in a way that's productive for you all. I actually do understand what

an amazing amount of effort you've poured into bcm43xx and the b43's,

and again, I am thankful. I understand that bcm43xx is effectively

dead, and it has architectural problems (locking, at minimum), that

have been a problem for at least the past two years that *I've* been

using it, probably more.
The goal here is to make sure that your shiny new code will *work* for

everyone, okay? Not to attack you, as I don't think you in any way

deserve an attack. If I come off that way, I'm sorry. But likewise, if

you could give me the benefit of the doubt, this conversation would go

a lo...
[ message continues ]

I'm not sure what you are doing there.

Do you have module autoloading disabled?

This all works perfectly well on all of my systems. And I never heared

such a problem before.
If you have a PCI device probing works as follows:

The PCI table is in ssb. So as soon as your kernel detects the PCI device

it will load ssb. ssb will register the PCI device. That will trigger

an udev event for the contained 802.11 core to get probed. This will load

b43.
You can't do

modprobe ssb b43

This will be interpreted as modprobe of "ssb" with the module

parameter "b43". At least by my modutils.
If you do

modprobe b43

it will automatically load _all_ required modules.

It works perfectly well on my systems.
All problems so far were not related to the b43 sourcecode at all.

And I think I can not be held responsible for unrelated code or bugs

in the operating system scripts.
--

Greetings Michael.

--

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*
WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
I'm going to blame this on you being tired or something, okay? But in

the meantime, could you *PLEASE* start giving me the benefit of the
There's a patch from Larry Finger to address this and other issues. It

hasn't made it's way fully upstream yet. Please read your message

here, in particular item number seven on Larry's list:
<shrug> Well, then they've made changes to udev or something else to

make this work okay for mere mortals such as myself, and haven't
As I've said multiple times earlier in this thread, I did try that and
So, do you want a scorecard on this?
One problem related to b43 source code, patch exists, has yet to be

merged upstream.
One problem related to udev rules, that may or may not be fixed in the

latest udev. I have udev version 113, which is the latest shipped in

Ubuntu's nightly development snapshots (hardy heron). I see that

version 117 of udev is available on kernel.org, but mine is from the

end of June. One would think that wouldn't be so old as to be a

complete deal breaker. Especially as bcm43xx works fine with my udev.
The b43 code requires the latest firmware, something that isn't quite

obvious from skimming the changelogs. But is in dmesg, so thanks for

that.
With udev rules hand-edited to include the ATTRS{type}==1 Larry

pointed out (thanks Larry), b43 also seems to create an odd extra

device, wmaster0. Same MAC as eth1, my wireless. It's just an odd

thing that wasn't there before with bcm43xx. May be good, may be bad,

dunno.
And yeah, in my opinion, making the kernel play well with up-to-date

userspace actually *is* part of your job, but then again, what do I

know.
Michael, you're a go...
[ message continues ]

That is a bug in your distribution. I cannot fix this.
The message you quote describes a _completely_ unrelated bug.

Besides that the bug described in the message does _not_ prevent

the device from working. It does _just_ prevent some random LED from

blinking. I'd not call that a big issue.

To say it again: This message was about loading "rfkill-input" _after_

b43 was loaded successfully.
1) I sent this patch out today for inclusion in the kernel

2) This is a _completely_ unrelated issue.

   It is about "rfkill-input" being not loaded. NOT about
Yeah. A problem preventing a LED from blinking.
That's not b43 specific. And it is not a bug. Ignore wmaster.
Yeah. So PLEASE point out real bugs in MY code and do not bother

me with other peoples bugs that I simply can not fix.

In the list above there was exactly one bug for which I am responsible.
Have fun.
--

Greetings Michael.

--

I've run out of time to donate to the kernel today, so I'll keep this short.
I'm going to say this one last time. If rfkill and rfkill-input aren't

manually loaded before sb and b43, not one damn thing comes out in

dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to

find out that those modules had to be loaded by hand was to go read

the bcm43xx-dev archives. Once those were loaded, messages came out in

dmesg pointing me to the URL for updated firmware.
I have complete current userspace as of yesterday's Ubuntu Hardy Heron

development archives.
One last thing. I've been nice to you. Please be nice to me. If you

can't manage that, then let another wireless developer take over.
You apparently think I'm an idiot. I'm not, and if necessary I could

supply a long list of credentials to prove I'm not an idiot. I'd

rather you just accepted my emails at face value and spent more effort

on trying to see how the bugs could be occurring rather than spending

effort on trying to prove that I'm an idiot.
Thanks.
Ray

--

I'm sorry. The patch that _you_ quoted fixes a blinking LED

and nothing else. It does _not_ fix loading of rfkill or b43 in any way.

It does, however, fix loading of rfkill-input. But the b43 module

operation does _not_ depend in any way on the rfkill-input module, except

the tiny LED that doesn't blink if it's not loaded.

I hope you understood now that the thread on bcm43xx-dev was NOT about
Ok. I will install a copy of Ubuntu Hardy Heron and check if I can

reproduce this.

However the fact that this does not happen on older Ubuntu platforms

and does not happen on Fedora leads to the conclusion that it

is a bug in Hardy Heron that I am not responsible for.
And you also do realise that Hardy Heron is the current development
If you simply stop blaming bugs on me that I am not responsible for

at all, that is a deal. What about filing a bug at the ubuntu bugzilla?
PS:

Note that Ubuntu is known to break the broadcom driver every now and then.

But I can not change that.
--

Greetings Michael.

--

*AGAIN*, please read your message here, in particular item number

seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
For the last fscking time, if rfkill and rfkill-input are not loaded,

not one line comes out in dmesg when b43 and ssb are loaded. In

particular, your pretty little message about needing newer firmware

also does not print. So, yeah, not loading rfkill{,-input} *does*

cause issues with b43 working, as there's no damn way to find out
I'm not asking you to do that, this particular bug will be fixed by
The kernel does not exist in a vacuum. It's the kernel's job to make

sure it works with properly written userspace. Broken userspace, sure,
Oy vay. I'm not an idiot. Yes, it's the current develoment version.

But tracking the latest kernel.org kernel has in the past required the

latest develoment version of the distribution, so I upgrade it as
I'm not blaming it on you. I'm merely reporting a fucking

incompatibility. Read my messages again from the top, and stop taking

this all so damn personally, will you?

--

Guy... .

I KNOW what the patch above does.

What do you think does the following line?

	err = request_module("rfkill-input");

Does it load the "rfkill-input" or the "rfkill" module.

That's the million dollar question. You only have one try.
This patch is NOT about the "rfkill" module. I don't know how

often I have to say that. It is _obvious_.
Let's also quote Larry's sevenths point here, that you referred to

now for the second time:

" (7) If rfkill-input is built as a module, it is not automatically loaded."
I am not sure how I can make this any more clear.

It does load the "rfkill-input" module from within b43.

It does NOT load "rfkill"

It does NOT load "rfkill-input" BEFORE b43 was loaded.
This patch does exactly ONE thing. It does make sure a LED does blink.

Nothing more.

I signed this patch off. So you can be 100% sure I know what it does.
Did you try that?

How can b43 load get fixed by a patch that adds a request_module()
I am running wireless-2.6 on feisty. So the kernel does _not_ require

an update of the distribution.
You are telling me that I don't understand patches that I sign off

and I should not take this personally?

That is challenging.
--

Greetings Michael.

--

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 way to the right. ) I ported the 2.4 kernel to a

custom ppc platform, including writing drivers for various hardware on

it ( http://patinc.com ). I'm the guy who did all the software for a

linux-based Voice over IP call center (

http://broncocommunications.com/ ).
So, *now* do you believe I'm not an idiot?
To answer your question, it requests the rfkill-input module. But

under the version I'm trying, rfkill-input is not automatically

loaded. I've pointed to the mailing list URL that proves that. So, I

loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't

necessary, I don't know, and I don't care. But once I did that, *then

and only then* did your damn b43 driver start printing out any

messages to dmesg at all, which then let me download the latest
I'm saying the patch you signed off on has a side-effect that will fix

my issue. And even if I *were* saying that, the most you should take

from it is that you are human and sometimes may make mistakes, just

like the rest of us. There's nothing challenging in that statement.
I've provided the bug report as many ways as I can think to. If you

don't agree, then I guess you'll just have to get the bug report from

someone else who can figure out exactly how to sugar coat the message

so that you'll listen to it.
Me, I'm done.

--

Nice. I am one of the main b43 developers and I wrote most of the code.

I know most of the code from the top of my head.
It is not an issue. You can even rmmod rfkill-input in FULL operation.

It will not disturb the operation, except that an LED stops working.
The b43 does print _nothing_ on modprobe. That is _correct_ behaviour.

b43 does print the firmware message after "ifconfig up".

Might it be possible that this was coincidence and you messed
Ok. So please revert that patch and try to reproduce the breakage.
I am inhuman. We all know that.

(That was a joke that you probably don't understand. But you can google

for "bcw vs. bcm43xx" :) )
Ray, I _do_ want to understand what is going on in your machine.

I _have_ to understand it. But I currently do not understand how the

quoted patch could fix modprobe of b43 or rfkill. I'd simply call that

impossible.

Impossible because the patch does change a few function called _inside_

of the b43 module. How could that fix load of the b43 module? (Note that

we are not changing some modprobe magic like the ID table).
So could you please try to reproduce the breakage by reverting that

patch again? Just to make really sure it is this patch fixing the issue

and not just some coincidence.
Thanks for your help.
--

Greetings Michael.

--

Then perhaps it is. Perhaps it's a race condition in my userspace

where something NetworkManager related is trying to up the interface,

I don't know. More below.
Regardless, I'm going to have to put off doing more debugging until

tomorrow. I've rebooted back into 2.6.23.0 as wireshark doesn't show

any packets using 2.6.24-rc3 (the version I've been testing), reported

elsewhere, and that's preventing me from doing actual work with my

system, as I'm in the middle of trying to enhance a network server for

a client.
Note, the wireshark issue is very much not a bcm43xx/b43 issue; I'm
I don't have the patch applied, so that's at least part of the

misunderstanding here. All I have is my sequence of "load b43, ssb,

nothing happens, unload them, load rfkill, rfkill-input, ssb, b43 and

something happens." I could very well be wrong. But I'm at the limit

of what I care to know about the b43 driver, and this is where I'm

asking for your help.
Hopefully tomorrow, I'll be able to build current tip and try this all

again, and I'll also try to do it with NetworkManager killed in the

background in case it was trying to bring the interfaces up behind my
Thanks for treating me like an adult.

--

^^^^^^^^^^^^^^
So the question seems to be why b43 needs version 4, when b43legacy and

bcm43x uses version 3?
Simon Holm Thøgersen
--

That's really a question, right?
Well. linux-2.4 doesn't work with the linux-2.6 modutils.

Windows Vista doesn't work with Windows 98 device drivers.

That leads to this assumption:

b43 doesn't work with version 3 firmware but needs version 4.
Newer drivers supporting newer hardware need newer firmware.
--

Greetings Michael.

--

Actually, can you explain why, from the technical point of view, the version 4

firware is better than version 3, please?
Rafael

--

I will be very interested in Michael's answer to this question; however, my experience is that it

doesn't make much difference if your device is supported by both V3 and V4 firmware. This impression

was obtained by comparing BCM4318 and BCM4311/1 devices with b43 and b43legacy.
Note that 802.11b and early BCM4306 devices are not supported by V4 firmware. Similarly, with

BCM4311/2 and newer devices V3 firmware fails. As Michael said "newer drivers supporting newer

hardware need newer firmware".
Larry

--

Could this be the reason my BCM94311MCG rev 1 receives such terrible

performance with b43 but works well with bcm43xx? The device is

802.11b/g but my router is 802.11b. I filed a report on this issue

here: https://bugzilla.redhat.com/show_bug.cgi?id=413291
I was told by Michael that I would have to fix it myself, and I am

trying, but the learning curve is a little steep. If this is relevant,

I might at least have some direction to go in.

--

No. On my BCM4311/1, my transfer rate peaked at about 12 Mbs with bcm43xx, but increased to 20 Mbs

with b43. These tests were done with iperf with a server running running on a second computer

connected by wire to my router. These rates are for 802.11g. When my interface was locked at 11 Mbs, 
I suspect that mac80211 is doing something that your router does not like. Do you have any chance to

capture the traffic between your computer and the router by using a second wireless computer running

kismet or wireshark? A look at the differences between b43 and bcm43xx should show the reason.
Larry
--

version 4 is the new firmware released by broadcom. They obviously won't

support and write any version 3 firmware anymore. So we are forced to

switch to version 4 firmware to support the newest hardware (like N-PHY

in the future). It's really as simple as that.

The difference between v3 and v4 is basically the driver API. It changed

a lot and it is nontrivial to support both v3 and v4 in one driver.

So we decided to stay with v3 for legacy devices and take v4 for any newer

devices. We have to live with that crap until someone comes up

with an opensource firmware. :)
--

Greetings Michael.

--

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.
Greetings,

Rafael

--

And I suspect that you are wrong until you show me one. :)
--

Greetings Michael.

--

The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power

control problem was "solved" in b43, there is very little difference. When I built my special system

to use the BCM4311 with b43legacy, there was no difference.
I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing

SoftMAC with mac80211. There is, of course, no comparison.
Larry
--

This was about version 3 firmware vs version 4 firmware.

I doubt the firmware makes any difference at all.
--

Greetings Michael.

--

h.
Impossible. The firmware is only the MAC.
johannes

OK
Thanks,

Rafael

--

I should probably mention though that of course it is (in theory!)

possible that the card works better with bcm43xx, it just never has

happened for all I know.
johannes

possibly forever, if you dont get obvious regressions like "my wlan does

not work" (reported in this very thread), resolved. Pushing the blame to

udev (in a rather unfriendly way) wont give users a working system and

wont get you many new testers for the new driver either.
	Ingo

--

It is true that Michael can be a little unpleasant at times.

The colloquialism that comes to mind is that he "does not suffer fools

lightly".  Hopefully he will take your counseling to heart and learn

to be a bit more moderate in his tone.  FWIW, he is still young. :-)
That said, it is also true that the b43[legacy] driver[s] do a more

than adequate job of replacing the old bcm43xx driver provided that

one (re-)installs the proper firmware.  And I know of no other driver

that goes to more trouble to tell you how to get the proper firmware

installed than this one.
The bcm43xx driver will be added to the feature removal schedule

in 2.6.25.  Proper judgment will be used in deciding the actual date

of its removal.  In the meantime hopefully every distribution will

have or obtain a working udev configuration.  If things don't work

out as planned then we will re-evaluate.
Let's stop this now please.
John

--

John W. Linville

linville@tuxdriver.com

--

Any pointers to the advantages of b43?
Harvey
--

http://www.linuxwireless.org/en/users/Drivers/b43
--

Greetings Michael.

--

When is the removal scheduled?
Daniel
--

$ grep -i bcm Documentation/feature-removal-schedule.txt

$
might make sense to update this file.
	Ingo

--

Patches are on their way.

I think it's scheduled to be removed after 2.6.25 was released.
--

Greetings Michael.

--

A patch w/ subject "bcm43xx: mark as obsolete and schedule for removal"

is queued in net-2.6.25 and waiting for the 2.6.25 merge window.

It includes this hunk:
--- a/Documentation/feature-removal-schedule.txt

+++ b/Documentation/feature-removal-schedule.txt

@@ -333,3 +333,12 @@ Why:	This driver has been marked obsolete for many years.

 Who:	Stephen Hemminger <shemminger@linux-foundation.org>
 ---------------------------

+

+What:	bcm43xx wireless network driver

+When:	2.6.26

+Files:	drivers/net/wireless/bcm43xx

+Why:	This driver's functionality has been replaced by the

+	mac80211-based b43 and b43legacy drivers.

+Who:	John W. Linville <linville@tuxdriver.com>

+

+---------------------------
Hth!
John

--

John W. Linville

linville@tuxdriver.com

--