Remove bcm43xx.
Signed-off-by: Stefano Brivio <[email protected]>
---
John,
I hope this is the last try, v2 was line wrapped. :) This is for 2.6.25.
Please also run:
git rm -r drivers/net/wireless/bcm43xx
---
Index: wireless-2.6/Documentation/networking/bcm43xx.txt
===================================================================
--- wireless-2.6.orig/Documentation/networking/bcm43xx.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-
- BCM43xx Linux Driver Project
- ============================
-
-Introduction
-------------
-
-Many of the wireless devices found in modern notebook computers are
-based on the wireless chips produced by Broadcom. These devices have
-been a problem for Linux users as there is no open-source driver
-available. In addition, Broadcom has not released specifications
-for the device, and driver availability has been limited to the
-binary-only form used in the GPL versions of AP hardware such as the
-Linksys WRT54G, and the Windows and OS X drivers. Before this project
-began, the only way to use these devices were to use the Windows or
-OS X drivers with either the Linuxant or ndiswrapper modules. There
-is a strong penalty if this method is used as loading the binary-only
-module "taints" the kernel, and no kernel developer will help diagnose
-any kernel problems.
-
-Development
------------
-
-This driver has been developed using
-a clean-room technique that is described at
-http://bcm-specs.sipsolutions.net/ReverseEngineeringProcess. For legal
-reasons, none of the clean-room crew works on the on the Linux driver,
-and none of the Linux developers sees anything but the specifications,
-which are the ultimate product of the reverse-engineering group.
-
-Software
---------
-
-Since the release of the 2.6.17 kernel, the bcm43xx driver has been
-distributed with the kernel source, and is prebuilt in most, if not
-all, distributions. There is, however, additional software that is
-required. The firmware used by the chip is the intellectual property
-of Broadcom and they have not given the bcm43xx team redistribution
-rights to this firmware. Since we cannot legally redistribute
-the firmware we cannot include it with the driver. Furthermore, it
-cannot be placed in the downloadable archives of any distributing
-organization; therefore, the user is responsible for obtaining the
-firmware and placing it in the appropriate location so that the driver
-can find it when initializing.
-
-To help with this process, the bcm43xx developers provide a separate
-program named bcm43xx-fwcutter to "cut" the firmware out of a
-Windows or OS X driver and write the extracted files to the proper
-location. This program is usually provided with the distribution;
-however, it may be downloaded from
-
-http://developer.berlios.de/project/showfiles.php?group_id=4547
-
-The firmware is available in two versions. V3 firmware is used with
-the in-kernel bcm43xx driver that uses a software MAC layer called
-SoftMAC, and will have a microcode revision of 0x127 or smaller. The
-V4 firmware is used by an out-of-kernel driver employing a variation of
-the Devicescape MAC layer known as d80211. Once bcm43xx-d80211 reaches
-a satisfactory level of development, it will replace bcm43xx-softmac
-in the kernel as it is much more flexible and powerful.
-
-A source for the latest V3 firmware is
-
-http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o
-
-Once this file is downloaded, the command
-'bcm43xx-fwcutter -w <dir> <filename>'
-will extract the microcode and write it to directory
-<dir>. The correct directory will depend on your distribution;
-however, most use '/lib/firmware'. Once this step is completed,
-the bcm3xx driver should load when the system is booted. To see
-any messages relating to the driver, issue the command 'dmesg |
-grep bcm43xx' from a terminal window. If there are any problems,
-please send that output to [email protected].
-
-Although the driver has been in-kernel since 2.6.17, the earliest
-version is quite limited in its capability. Patches that include
-all features of later versions are available for the stable kernel
-versions from 2.6.18. These will be needed if you use a BCM4318,
-or a PCI Express version (BCM4311 and BCM4312). In addition, if you
-have an early BCM4306 and more than 1 GB RAM, your kernel will need
-to be patched. These patches, which are being updated regularly,
-are available at ftp://lwfinger.dynalias.org/patches. Look for
-combined_2.6.YY.patch. Of course you will need kernel source downloaded
-from kernel.org, or the source from your distribution.
-
-If you build your own kernel, please enable CONFIG_BCM43XX_DEBUG
-and CONFIG_IEEE80211_SOFTMAC_DEBUG. The log information provided is
-essential for solving any problems.
Index: wireless-2.6/MAINTAINERS
===================================================================
--- wireless-2.6.orig/MAINTAINERS
+++ wireless-2.6/MAINTAINERS
@@ -821,15 +821,6 @@ L: [email protected]
W: http://linuxwireless.org/en/users/Drivers/b43
S: Maintained
-BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION)
-P: Larry Finger
-M: [email protected]
-P: Stefano Brivio
-M: [email protected]
-L: [email protected]
-W: http://bcm43xx.berlios.de/
-S: Maintained
-
BEFS FILE SYSTEM
P: Sergey S. Kostyliov
M: [email protected]
Index: wireless-2.6/drivers/net/wireless/Kconfig
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/Kconfig
+++ wireless-2.6/drivers/net/wireless/Kconfig
@@ -629,7 +629,6 @@ config ATH5K
source "drivers/net/wireless/iwlwifi/Kconfig"
source "drivers/net/wireless/hostap/Kconfig"
-source "drivers/net/wireless/bcm43xx/Kconfig"
source "drivers/net/wireless/b43/Kconfig"
source "drivers/net/wireless/b43legacy/Kconfig"
source "drivers/net/wireless/zd1211rw/Kconfig"
Index: wireless-2.6/drivers/net/wireless/Makefile
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/Makefile
+++ wireless-2.6/drivers/net/wireless/Makefile
@@ -37,7 +37,6 @@ obj-$(CONFIG_USB_ATMEL) += at76_
obj-$(CONFIG_PRISM54) += prism54/
obj-$(CONFIG_HOSTAP) += hostap/
-obj-$(CONFIG_BCM43XX) += bcm43xx/
obj-$(CONFIG_B43) += b43/
obj-$(CONFIG_B43LEGACY) += b43legacy/
obj-$(CONFIG_ZD1211RW) += zd1211rw/
--
Ciao
Stefano
On Monday, 19 of November 2007, Stefano Brivio wrote:
> Remove bcm43xx.
>
>
> Signed-off-by: Stefano Brivio <[email protected]>
>
> ---
>
> John,
> I hope this is the last try, v2 was line wrapped. :) This is for 2.6.25.
Well, are you 100% sure that everyone interested knows that this drivers is
going out in 2.6.25 and no one will object?
Rafael
On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, 20 of November 2007, Michael Buesch wrote:
> > It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to
> > replace bcm43xx. And we already do a parrallel release cycle with both drivers
> > included so people can switch. What else do you want?
>
> _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more.
> Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be
> dropped anyway after some time - when no one uses it any more. Still, it need
> not be (and IMHO it shouldn't be) your decision to drop it.
It is probably true that we haven't communicated this very well
outside the wireless team. We probably should have added bcm43xx to
the feature removal schedule before the 2.6.24 merge window closed.
How about if we mark bcm43xx as "Obsolete" in MAINTAINERS and add
an entry to Documentation/feature-removal-schedule.txt with a "When"
of 2.6.26? I think that should give everyone sufficient notice...?
John
--
John W. Linville
[email protected]
Stefano Brivio <[email protected]> writes:
> --- drivers/net/wireless/b43/main.c.orig 2007-11-20 01:12:12.1=
86524483 +0100
> +++ drivers/net/wireless/b43/main.c 2007-11-20 01:12:34.922702865=
+0100
> @@ -947,7 +947,7 @@
>
> while (1) {
> v0 =3D b43_read32(dev, B43_MMIO_XMITSTAT_0);
> - if (!(v0 & 0x00000001))
> + if (!v0)
> break;
> v1 =3D b43_read32(dev, B43_MMIO_XMITSTAT_1);
>
> (probably it's not the solution, I just want to see what happens then=
).
That didn't change anything.
> BTW, what firmware are you using?
It's 410.2160 from wl_ap.o.
Andreas.
--=20
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
John W. Linville wrote:
>
> It is probably true that we haven't communicated this very well
> outside the wireless team. We probably should have added bcm43xx to
> the feature removal schedule before the 2.6.24 merge window closed.
>
> How about if we mark bcm43xx as "Obsolete" in MAINTAINERS and add
> an entry to Documentation/feature-removal-schedule.txt with a "When"
> of 2.6.26? I think that should give everyone sufficient notice...?
This sounds good to me. Of course, we all understand that once 2.6.25 is released, _EVERY_
complaint/bug report for bcm43xx and SoftMAC will get the response "switch to 2.6.25"!
Larry
Signed-off-by: John W. Linville <[email protected]>
---
Documentation/feature-removal-schedule.txt | 9 +++++++++
MAINTAINERS | 2 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 20c4c8b..c057e36 100644
--- 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 <[email protected]>
---------------------------
+
+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 <[email protected]>
+
+---------------------------
diff --git a/MAINTAINERS b/MAINTAINERS
index 18b7c8e..2bfc23f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -828,7 +828,7 @@ P: Stefano Brivio
M: [email protected]
L: [email protected]
W: http://bcm43xx.berlios.de/
-S: Maintained
+S: Obsolete
BEFS FILE SYSTEM
P: Sergey S. Kostyliov
--
1.5.3.3
On Wednesday, 21 of November 2007, John W. Linville wrote:
> On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, 20 of November 2007, Michael Buesch wrote:
>
> > > It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to
> > > replace bcm43xx. And we already do a parrallel release cycle with both drivers
> > > included so people can switch. What else do you want?
> >
> > _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more.
> > Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be
> > dropped anyway after some time - when no one uses it any more. Still, it need
> > not be (and IMHO it shouldn't be) your decision to drop it.
>
> It is probably true that we haven't communicated this very well
> outside the wireless team. We probably should have added bcm43xx to
> the feature removal schedule before the 2.6.24 merge window closed.
>
> How about if we mark bcm43xx as "Obsolete" in MAINTAINERS and add
> an entry to Documentation/feature-removal-schedule.txt with a "When"
> of 2.6.26?
This is a very good idea IMO.
> I think that should give everyone sufficient notice...?
Please also state very clearly in the changelog that you'd like to drop the
driver entirely before 2.6.26.
Thanks,
Rafael
On Mon, 19 Nov 2007 23:36:44 +0100
Andreas Schwab <[email protected]> wrote:
> Stefano Brivio <[email protected]> writes:
>
> > On Mon, 19 Nov 2007 23:00:11 +0100
> > "Rafael J. Wysocki" <[email protected]> wrote:
> >
> >> Well, are you 100% sure that everyone interested knows that this
> >> drivers is going out in 2.6.25 and no one will object?
> >
> > The maintainers know. Having both drivers in 2.6.24 should help find
> > out if there's anything which should be ironed out with b43/b43legacy,
> > but right now they are already working a lot better than bcm43xx, and
> > they are more stable. So I couldn't find a reason why we shouldn't
> > remove bcm43xx in 2.6.25.
>
> b43 still does not work at all on ppc.
This is strange. Because it has been developed mainly on PPC. Plus, if you
could better define "does not work" as per
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html, it would be great.
--
Ciao
Stefano
Michael Buesch <[email protected]> writes:
> On Tuesday 20 November 2007 15:11:07 Andreas Schwab wrote:
>> Michael Buesch <[email protected]> writes:
>>=20
>> > On Monday 19 November 2007 23:36:44 Andreas Schwab wrote:
>> >> b43 still does not work at all on ppc.
>> >
>> > This is absolutely _wrong_.
>>=20
>> Of course it is wrong, but apparently the only way to get attention =
to a
>> blocker bug.
>
> I didn't hear about your bug before.
>
> Are you using latest driver from wireless-2.6 and the officially
> supported firmware version from
> http://www.linuxwireless.org/en/users/Drivers/b43
I have now downgraded the firmware (I was foolishly assuming that all
firmware versions recognized by b43-fwcutter are equally supported), an=
d
the error does not occur any more. Thanks for your help.
Andreas.
--=20
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
Michael Buesch <[email protected]> writes:
> On Monday 19 November 2007 23:36:44 Andreas Schwab wrote:
>> b43 still does not work at all on ppc.
>
> This is absolutely _wrong_.
Of course it is wrong, but apparently the only way to get attention to =
a
blocker bug.
Andreas.
--=20
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
On Monday, 19 of November 2007, Stefano Brivio wrote:
> On Mon, 19 Nov 2007 23:00:11 +0100
> "Rafael J. Wysocki" <[email protected]> wrote:
>
> > Well, are you 100% sure that everyone interested knows that this drivers
> > is going out in 2.6.25 and no one will object?
>
> The maintainers know.
I mean the users.
> Having both drivers in 2.6.24 should help find out if
> there's anything which should be ironed out with b43/b43legacy, but right
> now they are already working a lot better than bcm43xx, and they are more
> stable. So I couldn't find a reason why we shouldn't remove bcm43xx in
> 2.6.25.
Many people use the old driver and you are forcing them to switch in a rather
unfriendly fashion.
Moreover, the switch generally involves a configuration change (on my system
eth1 became wlan0) and is not _that_ seamless.
IMvHO, the schedule of the removal of this driver should be discussed on LKML.
Greetings,
Rafael
Signed-off-by: John W. Linville <[email protected]>
---
Amended based on suggestions from Stefano...
Documentation/feature-removal-schedule.txt | 9 +++++++++
MAINTAINERS | 2 +-
drivers/net/wireless/bcm43xx/Kconfig | 9 ++++++---
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 20c4c8b..c057e36 100644
--- 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 <[email protected]>
---------------------------
+
+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 <[email protected]>
+
+---------------------------
diff --git a/MAINTAINERS b/MAINTAINERS
index 18b7c8e..2bfc23f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -828,7 +828,7 @@ P: Stefano Brivio
M: [email protected]
L: [email protected]
W: http://bcm43xx.berlios.de/
-S: Maintained
+S: Obsolete
BEFS FILE SYSTEM
P: Sergey S. Kostyliov
diff --git a/drivers/net/wireless/bcm43xx/Kconfig b/drivers/net/wireless/bcm43xx/Kconfig
index ce397e4..0159701 100644
--- a/drivers/net/wireless/bcm43xx/Kconfig
+++ b/drivers/net/wireless/bcm43xx/Kconfig
@@ -1,12 +1,15 @@
config BCM43XX
- tristate "Broadcom BCM43xx wireless support"
+ tristate "Broadcom BCM43xx wireless support (DEPRECATED)"
depends on PCI && IEEE80211 && IEEE80211_SOFTMAC && WLAN_80211 && EXPERIMENTAL
select WIRELESS_EXT
select FW_LOADER
select HW_RANDOM
---help---
- This is an experimental driver for the Broadcom 43xx wireless chip,
- found in the Apple Airport Extreme and various other devices.
+ This is an experimental driver for the Broadcom 43xx wireless
+ chip, found in the Apple Airport Extreme and various other
+ devices. This driver is deprecated and will be removed
+ from the kernel in the near future. It has been replaced
+ by the b43 and b43legacy drivers.
config BCM43XX_DEBUG
bool "Broadcom BCM43xx debugging (RECOMMENDED)"
--
1.5.3.3
> > The maintainers know. Having both drivers in 2.6.24 should help find out if
> > there's anything which should be ironed out with b43/b43legacy, but right
> > now they are already working a lot better than bcm43xx, and they are more
> > stable. So I couldn't find a reason why we shouldn't remove bcm43xx in
> > 2.6.25.
>
> b43 still does not work at all on ppc.
That's completely false.
johannes
On Tuesday 20 November 2007 16:09:27 Larry Finger wrote:
> Andreas Schwab wrote:
> > Stefano Brivio <[email protected]> writes:
> >
> >> --- drivers/net/wireless/b43/main.c.orig 2007-11-20 01:12:12.186524483 +0100
> >> +++ drivers/net/wireless/b43/main.c 2007-11-20 01:12:34.922702865 +0100
> >> @@ -947,7 +947,7 @@
> >>
> >> while (1) {
> >> v0 = b43_read32(dev, B43_MMIO_XMITSTAT_0);
> >> - if (!(v0 & 0x00000001))
> >> + if (!v0)
> >> break;
> >> v1 = b43_read32(dev, B43_MMIO_XMITSTAT_1);
> >>
> >> (probably it's not the solution, I just want to see what happens then).
> >
> > That didn't change anything.
> >
> >> BTW, what firmware are you using?
> >
> > It's 410.2160 from wl_ap.o.
>
> Please try version 351.126 from http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2,
> which is the officially supported version.
There was some minor API change for newer firmware.
I think the TX and RX header layout slightly changed. I'll address that
later, as it's not too important now. (Or if someone else does want
to fix it, please send some patches...)
--
Greetings Michael.
On Wednesday 21 November 2007 00:26:48 Rafael J. Wysocki wrote:
> On Tuesday, 20 of November 2007, Michael Buesch wrote:
> > On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote:
> > > > Having both drivers in 2.6.24 should help find out if
> > > > there's anything which should be ironed out with b43/b43legacy, but right
> > > > now they are already working a lot better than bcm43xx, and they are more
> > > > stable. So I couldn't find a reason why we shouldn't remove bcm43xx in
> > > > 2.6.25.
> > >
> > > Many people use the old driver and you are forcing them to switch in a rather
> > > unfriendly fashion.
> > >
> > > Moreover, the switch generally involves a configuration change (on my system
> > > eth1 became wlan0) and is not _that_ seamless.
> > >
> > > IMvHO, the schedule of the removal of this driver should be discussed on LKML.
> >
> > Ok, so we are going to add Rafael J. Wysocki as the bcm43xx maintainer
> > and remove everyone else. I'm OK with that.
>
> [That wasn't nice.]
Exactly.
> _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more.
> Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be
> dropped anyway after some time - when no one uses it any more. Still, it need
> not be (and IMHO it shouldn't be) your decision to drop it.
Who is responsible to do that decision, if the driver authors that wrote all the
code aren't?
I'd be very happy to shift bcm43xx maintainership to someone else, but
there is _nobody_ who wants to do it. Face it. Nobody wants bcm43xx anymore.
And the only sane way to handle this is to run one release cycle with both
drivers included and remove the old driver after that.
bcm43xx is basically dropped since a year and everybody who cares knows that.
And nobody cares to maintain that piece of junk in the future.
--
Greetings Michael.
Rafael J. Wysocki wrote:
>
> Many people use the old driver and you are forcing them to switch in a rather
> unfriendly fashion.
>
> Moreover, the switch generally involves a configuration change (on my system
> eth1 became wlan0) and is not _that_ seamless.
That change is in udev and has nothing to do with the bcm43xx - b43 change. The renaming will happen
even though one stays with bcm43xx.
Larry
Stefano Brivio <[email protected]> writes:
> This is strange. Because it has been developed mainly on PPC. Plus, i=
f you
> could better define "does not work"
See <http://marc.info/?l=3Dlinux-wireless&m=3D119356497407301&w=3D2>.
Andreas.
--=20
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
Schedule softmac for for removal in the 2.6.26 development window.
Signed-off-by: John W. Linville <[email protected]>
---
Documentation/feature-removal-schedule.txt | 8 ++++++++
net/ieee80211/Kconfig | 5 +++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index c057e36..aeaa129 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -342,3 +342,11 @@ Why: This driver's functionality has been replaced by the
Who: John W. Linville <[email protected]>
---------------------------
+
+What: iee80211 softmac wireless networking component
+When: 2.6.26 (or after removal of bcm43xx and port of zd1211rw to mac80211)
+Files: net/ieee80211/softmac
+Why: No in-kernel drivers will depend on it any longer.
+Who: John W. Linville <[email protected]>
+
+---------------------------
diff --git a/net/ieee80211/Kconfig b/net/ieee80211/Kconfig
index 1438ade..bd50104 100644
--- a/net/ieee80211/Kconfig
+++ b/net/ieee80211/Kconfig
@@ -1,8 +1,9 @@
config IEEE80211
- tristate "Generic IEEE 802.11 Networking Stack"
+ tristate "Generic IEEE 802.11 Networking Stack (DEPRECATED)"
---help---
This option enables the hardware independent IEEE 802.11
- networking stack.
+ networking stack. This component is deprecated in favor of the
+ mac80211 component.
config IEEE80211_DEBUG
bool "Enable full debugging output"
--
1.5.3.3
Stefano Brivio <[email protected]> writes:
> On Mon, 19 Nov 2007 23:00:11 +0100
> "Rafael J. Wysocki" <[email protected]> wrote:
>
>> Well, are you 100% sure that everyone interested knows that this dri=
vers
>> is going out in 2.6.25 and no one will object?
>
> The maintainers know. Having both drivers in 2.6.24 should help find =
out if
> there's anything which should be ironed out with b43/b43legacy, but r=
ight
> now they are already working a lot better than bcm43xx, and they are =
more
> stable. So I couldn't find a reason why we shouldn't remove bcm43xx i=
n
> 2.6.25.
b43 still does not work at all on ppc.
Andreas.
--=20
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
On Tuesday, 20 of November 2007, Michael Buesch wrote:
> On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote:
> > > Having both drivers in 2.6.24 should help find out if
> > > there's anything which should be ironed out with b43/b43legacy, but right
> > > now they are already working a lot better than bcm43xx, and they are more
> > > stable. So I couldn't find a reason why we shouldn't remove bcm43xx in
> > > 2.6.25.
> >
> > Many people use the old driver and you are forcing them to switch in a rather
> > unfriendly fashion.
> >
> > Moreover, the switch generally involves a configuration change (on my system
> > eth1 became wlan0) and is not _that_ seamless.
> >
> > IMvHO, the schedule of the removal of this driver should be discussed on LKML.
>
> Ok, so we are going to add Rafael J. Wysocki as the bcm43xx maintainer
> and remove everyone else. I'm OK with that.
[That wasn't nice.]
I'm not qualified to maintain that code, sorry. Apart from this, I've switched
to b43. :-)
> It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to
> replace bcm43xx. And we already do a parrallel release cycle with both drivers
> included so people can switch. What else do you want?
_First_, mark bcm43xx as unmaintained. Then, it's not your problem any more.
Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be
dropped anyway after some time - when no one uses it any more. Still, it need
not be (and IMHO it shouldn't be) your decision to drop it.
Greetings,
Rafael
> Many people use the old driver and you are forcing them to switch in a rather
> unfriendly fashion.
> IMvHO, the schedule of the removal of this driver should be discussed on LKML.
We can post a patch to orphan it and then ignore it. We actually prefer
to remove it so people use b43 and we can fix any issues they had.
Face it, nobody is willing to maintain this old thing any more.
johannes
On Mon, 19 Nov 2007 23:00:11 +0100
"Rafael J. Wysocki" <[email protected]> wrote:
> Well, are you 100% sure that everyone interested knows that this drivers
> is going out in 2.6.25 and no one will object?
The maintainers know. Having both drivers in 2.6.24 should help find out if
there's anything which should be ironed out with b43/b43legacy, but right
now they are already working a lot better than bcm43xx, and they are more
stable. So I couldn't find a reason why we shouldn't remove bcm43xx in
2.6.25.
--
Ciao
Stefano
On Wednesday 21 November 2007 14:59:27 John W. Linville wrote:
> On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, 20 of November 2007, Michael Buesch wrote:
>
> > > It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to
> > > replace bcm43xx. And we already do a parrallel release cycle with both drivers
> > > included so people can switch. What else do you want?
> >
> > _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more.
> > Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be
> > dropped anyway after some time - when no one uses it any more. Still, it need
> > not be (and IMHO it shouldn't be) your decision to drop it.
>
> It is probably true that we haven't communicated this very well
> outside the wireless team. We probably should have added bcm43xx to
> the feature removal schedule before the 2.6.24 merge window closed.
>
> How about if we mark bcm43xx as "Obsolete" in MAINTAINERS and add
> an entry to Documentation/feature-removal-schedule.txt with a "When"
> of 2.6.26? I think that should give everyone sufficient notice...?
So, is SoftMAC already scheduled?
Otherwise, I think when we are about to remove bcm43xx in 2.6.25 someone
is going to complain that removal of softmac was not scheduled...
Btw: Does someone actually read that feature-removal-schedule.txt file?
--
Greetings Michael.
On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote:
> > Having both drivers in 2.6.24 should help find out if
> > there's anything which should be ironed out with b43/b43legacy, but right
> > now they are already working a lot better than bcm43xx, and they are more
> > stable. So I couldn't find a reason why we shouldn't remove bcm43xx in
> > 2.6.25.
>
> Many people use the old driver and you are forcing them to switch in a rather
> unfriendly fashion.
>
> Moreover, the switch generally involves a configuration change (on my system
> eth1 became wlan0) and is not _that_ seamless.
>
> IMvHO, the schedule of the removal of this driver should be discussed on LKML.
Ok, so we are going to add Rafael J. Wysocki as the bcm43xx maintainer
and remove everyone else. I'm OK with that.
It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to
replace bcm43xx. And we already do a parrallel release cycle with both drivers
included so people can switch. What else do you want?
--
Greetings Michael.
On Monday, 19 of November 2007, Andreas Schwab wrote:
> Stefano Brivio <[email protected]> writes:
>
> > On Mon, 19 Nov 2007 23:00:11 +0100
> > "Rafael J. Wysocki" <[email protected]> wrote:
> >
> >> Well, are you 100% sure that everyone interested knows that this drivers
> >> is going out in 2.6.25 and no one will object?
> >
> > The maintainers know. Having both drivers in 2.6.24 should help find out if
> > there's anything which should be ironed out with b43/b43legacy, but right
> > now they are already working a lot better than bcm43xx, and they are more
> > stable. So I couldn't find a reason why we shouldn't remove bcm43xx in
> > 2.6.25.
>
> b43 still does not work at all on ppc.
Well, in that case for ppc users the removal of bcm43xx will be a regression.
Greetings,
Rafael
On Tue, 20 Nov 2007 00:19:55 +0100
Andreas Schwab <[email protected]> wrote:
> Stefano Brivio <[email protected]> writes:
>
> > This is strange. Because it has been developed mainly on PPC. Plus, if
> > you could better define "does not work"
>
> See <http://marc.info/?l=linux-wireless&m=119356497407301&w=2>.
It looks like we don't get a valid txstatus even if the txstatus indicator
register told us we could read it. The only difference I can see between
bcm43xx and b43 here is that in bcm43xx we allowed the whole register to be
non-zero, while in b43 we check a bit only (as per v4 specs). Would you
mind to try this:
--- drivers/net/wireless/b43/main.c.orig 2007-11-20 01:12:12.186524483 +0100
+++ drivers/net/wireless/b43/main.c 2007-11-20 01:12:34.922702865 +0100
@@ -947,7 +947,7 @@
while (1) {
v0 = b43_read32(dev, B43_MMIO_XMITSTAT_0);
- if (!(v0 & 0x00000001))
+ if (!v0)
break;
v1 = b43_read32(dev, B43_MMIO_XMITSTAT_1);
(probably it's not the solution, I just want to see what happens then).
BTW, what firmware are you using? Michael, any clue?
--
Ciao
Stefano
Andreas Schwab wrote:
> Stefano Brivio <[email protected]> writes:
>
>> --- drivers/net/wireless/b43/main.c.orig 2007-11-20 01:12:12.186524483 +0100
>> +++ drivers/net/wireless/b43/main.c 2007-11-20 01:12:34.922702865 +0100
>> @@ -947,7 +947,7 @@
>>
>> while (1) {
>> v0 = b43_read32(dev, B43_MMIO_XMITSTAT_0);
>> - if (!(v0 & 0x00000001))
>> + if (!v0)
>> break;
>> v1 = b43_read32(dev, B43_MMIO_XMITSTAT_1);
>>
>> (probably it's not the solution, I just want to see what happens then).
>
> That didn't change anything.
>
>> BTW, what firmware are you using?
>
> It's 410.2160 from wl_ap.o.
Please try version 351.126 from http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2,
which is the officially supported version.
Larry
On Tue, 20 Nov 2007, Andreas Schwab wrote:
> Michael Buesch <[email protected]> writes:
>
>> On Tuesday 20 November 2007 15:11:07 Andreas Schwab wrote:
>>> Michael Buesch <[email protected]> writes:
>>>
>>>> On Monday 19 November 2007 23:36:44 Andreas Schwab wrote:
>>>>> b43 still does not work at all on ppc.
>>>>
>>>> This is absolutely _wrong_.
>>>
>>> Of course it is wrong, but apparently the only way to get attention to a
>>> blocker bug.
>>
>> I didn't hear about your bug before.
>>
>> Are you using latest driver from wireless-2.6 and the officially
>> supported firmware version from
>> http://www.linuxwireless.org/en/users/Drivers/b43
>
> I have now downgraded the firmware (I was foolishly assuming that all
> firmware versions recognized by b43-fwcutter are equally supported), and
> the error does not occur any more. Thanks for your help.
It sounds like b43-fwcutter will extract firmware that is not maximally
compatible with the b43 driver. If that's right, then it would be way
nice to print a notice to the user that he's extracting a
less-than-perfectly-supported firmware.
Yes, I'm willing to write this patch if people will point me to a table of
which firmware is maximally-supported. (If someone else writes it
instead, I'd prefer that, but if no one will then I can.)
I haven't actually been using a bcm43xx chip for wireless for about a
year, but I've been enjoying the list mail so I stayed on and read mails
casually. It sounds like there's one specific firmware that's
recommended; if so, then printing "Congratulations, you're using the
best-supported firmware as of ${RELEASE_DATE_OF_THIS_FWCUTTER}" in that
case would be easy, as well as "Warning! You're not using the
best-supported firmware as of ${RELEASE_DATE_OF_THIS_FWCUTTER}".
If it already does that now, then sorry for the noise!
-- Asheesh.
--
Positive, adj.:
Mistaken at the top of one's voice.
-- Ambrose Bierce, "The Devil's Dictionary"
> This sounds good to me. Of course, we all understand that once 2.6.25 is released, _EVERY_
> complaint/bug report for bcm43xx and SoftMAC will get the response "switch to 2.6.25"!
Nah. That'll even happen with .24 :)
johannes
Michael Buesch <[email protected]> writes:
> Are you using latest driver from wireless-2.6 and the officially
> supported firmware version from
> http://www.linuxwireless.org/en/users/Drivers/b43
Please see the other mails in the thread.
Andreas.
--=20
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
On Wed, 21 Nov 2007 10:26:18 -0500
"John W. Linville" <[email protected]> wrote:
> Signed-off-by: John W. Linville <[email protected]>
Acked-by: Stefano Brivio <[email protected]>
--
Ciao
Stefano
On Monday 19 November 2007 23:36:44 Andreas Schwab wrote:
> b43 still does not work at all on ppc.
This is absolutely _wrong_.
--
Greetings Michael.
On Tuesday 20 November 2007 15:11:07 Andreas Schwab wrote:
> Michael Buesch <[email protected]> writes:
>
> > On Monday 19 November 2007 23:36:44 Andreas Schwab wrote:
> >> b43 still does not work at all on ppc.
> >
> > This is absolutely _wrong_.
>
> Of course it is wrong, but apparently the only way to get attention to a
> blocker bug.
I didn't hear about your bug before.
Are you using latest driver from wireless-2.6 and the officially
supported firmware version from
http://www.linuxwireless.org/en/users/Drivers/b43
--
Greetings Michael.