Latest release of BCM5700 driver for PE2650 JACOB_LIBERMAN at
Wed Aug 6 10:09:01 CDT 2003


I agree with you %100. The best driver should be used. 

Unfortunately, I am not a driver developer, and neither are %99 of Dell's
customers. Most of Dell's customers are not even on this list. They don't
care which driver is "better." They just want a stable solution. 

In the past, I have seen many problems with both the tg3 AND bcm5700. In
some cases one driver would solve the problem, and in other cases the other
driver would solve the problem. Sometimes neither driver would work and we
had to send the customer cards from a different vendor. 

I have no agenda of promoting one driver over another. My ego is not tied to
which driver is ultimately adopted. All I care about is getting the customer
in production with a reliable configuration.

e100/eepro100 is a good example of a vendor supplied driver, but it is not
unique. aic7xxx_mod versus aic7xxx is another good example of the vendor
managing a fairly good driver. I hope that, as Linux continues to gain
acceptance, the hardware vendors will ultimately become responsible for
managing their drivers through the current system of peer development.



-----Original Message-----
From: Xose Vazquez Perez [mailto:xose at] 
Sent: Tuesday, August 05, 2003 4:13 PM
To: Linux-PowerEdge at
Subject: RE: Latest release of BCM5700 driver for PE2650

Steve_Boley wrote:

> Since they are actively supporting, why not merge the best of both and 
> go to one.  I was informed by a little birdy flying around that bcom 
> has actively engaged a kernel developer to clean up bcm5700 and that 
> is what redhat is supposed to officially support for Dell and broadcom 
> adapters in upcoming adv server errata kernels.

someone wrote about bcm5700 driver:

"The Broadcom Tigon3 boards arrived, but looking at their driver made me
want to scratch my eyeballs out. I think I'll write the 2.4.x driver from
scratch, thank you. At least, I can print out their driver and use that when
we run out of toilet paper here at the apartment."

> Officially I was told that we support bcm5700 on as 2.1 end of story. 
> I'm not going to divulge any names or anything but this is where the 
> info of broadcom utilizing kernel developer to clean the bcm and get 
> it back into the mainstream kernels at redhat came from.  I know you 
> work for redhat so is that the truth or not.  I voiced concerns that 
> different info keeps getting presented and now this still continues.

Work already has been done. bcm without shit = tg3 ;-)

> Jeff is broadcom going to integrate the codes and are you that 
> developer or am I getting incorrect information?
> I don't want to start any flames but this is a very confusing topic 
> for
> customers as well as what is working and what is not working.
> Steve

Documentation/SubmittingDrivers is very clear

What Criteria Do Not Determine Acceptance

Vendor:         Being the hardware vendor and maintaining the driver is
                often a good thing. If there is a stable working driver from
                other people already in the tree don't expect 'we are the
                vendor' to get your driver chosen. Ideally work with the
                existing driver author to build a single perfect driver.

Author:         It doesn't matter if a large Linux company wrote the driver,
                or you did. Nobody has any special access to the kernel
                tree. Anyone who tells you otherwise isn't telling the
                whole story.

I think that eepro100/e100 was a special case.

Software is like sex, it's better when it's bug free.

Linux-PowerEdge mailing list
Linux-PowerEdge at
Please read the FAQ at or search the list
archives at

More information about the Linux-PowerEdge mailing list