summaryrefslogtreecommitdiffstats
path: root/drivers/net/tulip/Makefile
AgeCommit message (Collapse)Author
2011-05-09tulip: Convert uses of KERN_DEBUGJoe Perches
Convert logging messages to more current styles. Added -DDEBUG to Makefile to maintain current message logging. This could be converted to a specific CONFIG_TULIP_DEBUG option. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-03-17remove the obsolete xircom_tulip_cb driverAdrian Bunk
The xircom_tulip_cb driver has been replaced the xircom_cb driver, and since it depended on BROKEN_ON_SMP it e.g. was no longer present in many distribution kernels. This patch therefore removes it. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2005-07-29[netdrvr] add 'uli526x' driver (a tulip clone)Peer Chen
We want to extract our LAN card driver from tulip core driver and make a new file uli526x.c at tulip folder, because we have added some ethtool interface support and non-eprom support in our driver and may be other change in the futher. If our controllers support are still contained in the tulip core driver, I think it'll increase the complexity of maintenance, you know, tulip core driver include several files and support so many other controllers. Furthermore, I tested the newest kernel 2.6.12 and I found the tulip driver can not work on our lan controller, and I no time to debug it, so I aspired want to make a single uli526x.c file just for our controllers. Could you help us remove the ULi m5261/m5263 lan controller support from tulip core driver and add the new single uli526x.c file for us? Signed-off-by: Peer Chen <Peer.Chen@uli.com.tw> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!