Commit Graph

8 Commits

Author SHA1 Message Date
Ben Hutchings
4d907069bc dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
The Davicom DM9100 and DM9102 chips are used on the motherboards of
some SPARC systems (supported by the tulip driver) and also in PCI
expansion cards (supported by the dmfe driver).  There is no
difference in the PCI device ids for the two different configurations,
so these drivers both claim the device ids.  However, it is possible
to distinguish the two configurations by the presence of Open Firmware
properties for them, so we do that.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 17:27:31 -08:00
Risto Suominen
b77e522884 de2104x: support for systems lacking cache coherence
Add a configurable Descriptor Skip Length for systems that lack cache
coherence.

(akpm: I think this should be done as a module parameter, not a
compile-tinme option)

Signed-off-by: Risto Suominen <Risto.Suominen@gmail.com>
Cc: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-11 02:32:41 -07:00
Adrian Bunk
fa6557aff4 remove the obsolete xircom_tulip_cb driver
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>
2008-03-17 07:49:23 -04:00
Adrian Bunk
57ce45dd16 [NET]: Remove references to net-modules.txt.
When I removed net-modules.txt because it only contained ancient
information I missed that many Kconfig entries pointed to this ancient
information.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-12 21:03:58 -08:00
Randy Dunlap
bf45abeb1d NAPI: kconfig prompt and deleted doc file
- make the kconfig NAPI option prompt consistent across all net drivers
  (other than EXPERIMENTAL; can it now be removed also, or is the new
  napi_struct implementation now EXPERIMENTAL ?)
- remove comment about the now-deleted NAPI_HOWTO.txt file
- clean up typos in Tulip NAPI & Interrupt Mitigation

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-19 23:00:02 -04:00
Jan Engelhardt
d1c0a65fb5 Use menuconfig objects II - netdev (general+100mbit)
CONFIG_NETDEVICES, CONFIG_NET_ETHERNET:
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.

CONFIG_SMC9194:
Move it so that it appears correctly in menuconfig.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-07-08 22:16:40 -04:00
Peer Chen
4689ced99b [netdrvr] add 'uli526x' driver (a tulip clone)
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-07-29 15:33:58 -04:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00