Re: bcm4400 driver

[Pekka Pietikainen]

On Sat, Dec 25, 2004 at 07:24:51PM +0100, prem.de.ms wrote:
> Merry Christmas everyone,
> 
> I have a question concerning the bcm4400 driver: It is merged in the 
> kernel, but marked as experimental, so it does not work quite well. 
> Broadcom released their Linux drivers for this card under the GPL (see 
> http://www.broadcom.com/drivers/downloaddrivers.php). Is there a 
> specific reason why you don't use these drivers?
Hi

The following patch will make the driver work a lot better:

--- linux-2.6.9/drivers/net/Kconfig~	2004-12-26 00:45:22.692791880 +0200
+++ linux-2.6.9/drivers/net/Kconfig	2004-12-26 00:45:22.693791728 +0200
@@ -1326,8 +1326,8 @@
 	  called apricot.
 
 config B44
-	tristate "Broadcom 4400 ethernet support (EXPERIMENTAL)"
-	depends on NET_PCI && PCI && EXPERIMENTAL
+	tristate "Broadcom 4400 ethernet support"
+	depends on NET_PCI && PCI
 	select MII
 	help
 	  If you have a network (Ethernet) controller of this type, say Y and

Seriously, there are no known outstanding bugs in b44 (if there are, I'd
really like to know. Just sold my b44-based motherboard so don't have the
hardware to test things, though, so no promises about fixes :-) ). Two
remaining issues are missing Wake on LAN support and the use of lots of
GFP_DMA memory (which is unfortunately required to work around a hardware
bug which only shows up with non-standard memory layouts and > 1GB of
memory), which may result in out of memory errors if the module gets loaded
a long time after booting. That was the only way of fixing the bug, alas,
the bcm4400 driver doesn't have a fix mind you and will happily crash & burn
on 4:4 split kernels.

As for bcm4400 yes it does work (as long as you don't hit the hardware bug
:-) ). The problem is that it's not a Linux driver but a "generic" (windows?)
driver with abstraction on top (> 6000 lines of code vs. < 2500 for 
b44) and a glue layer to interface with Linux. 

Not really maintainable in the standard kernel tree where the idea is that
if someone changes some API (lets say PCI) they have to fix all the users of
the API as well. If all drivers look and smell the same the changes are
pretty easy to make and verify. If people have to look at 15 different
vendor abstraction layers and understand what requirements they have, this
is no longer the case.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/