On Mon, 25 Feb 2002, David S. Miller wrote:
>
> This is to announce the first test release of a new Broadcom Tigon3
> driver written by Jeff and myself. Get it at:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/davem/TIGON3/tg3.patch.gz
>
> The patch is against 2.4.18 but there is no reason it should be
> difficult to apply this patch to any other tree.
>
> It is meant to replace Broadcom's driver because frankly their driver
> is junk and would never be accepted into the tree. For an example of
> why their driver is junk, note that the resulting object file from our
> driver is less than half the size of Broadcom's. That kind of bloat
> is simply unacceptable. Next, Broadcom's driver is still way
> non-portable, ioremap() pointers are still dereferenced directly among
> other things. Finally, their driver is just plain buggy, they have
> code which tries to use page_address() on pages which are potentially
> in highmem and that is guarenteed to oops.
>
> There are other problems with their driver too, just ask as I'm in a
> good mood to grind my axe about this stuff :-)
>
> We would also like to give Broadcom a big "no thanks" because
> their lawyers refused to give Jeff the documentation for the Tigon3
> chipset using an NDA that would allow him to write a GPL'd driver
> based upon said documentation. This means that all that we know about
> the hardware has been reverse engineered from Broadcom's GPL'd driver
> plus some experimenting. It is why this driver has taken so long to
> finish, because it is hard to find incentive for this kind of brack
> breaking work when the vendor is totally uncooperative.
>
> I personally think Broadcom has some hidden agenda that requires that
> their driver be "the one". So instead of just complaining about such
> stupid policy, we've done something about it by doing our own driver
> with all the problems fixed.
>
> We'd really appreciate if people would test this thing out as hard
> as they can. I can tell you that I've personally only been able to
> test out the following scenerios so far:
>
> 1) Both big-endian and little-endian platforms.
> 2) 64-bit on big-endian side, 32-bit on little-endian side.
> 3) IOMMU based PCI dma platform on 64-bit/big-endian side,
> non-IOMMU based PCI dma platform on 32-bit little-endian side.
> 4) 10baseT half duplex, 100baseT full duplex
> 5) Copper based connectors, as that is all that Jeff and I have.
>
> Gigabit and fibre are the big areas where our testing has been
> lacking. We have also not done any tuning of the driver at all,
> although we do consider the driver feature complete.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/