|
Linux Kernel
3.7.1
|
All Data Structures Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
|
Linux Kernel
3.7.1
|
#include <linux/module.h>#include <linux/kernel.h>#include <linux/fcntl.h>#include <linux/ioport.h>#include <linux/interrupt.h>#include <linux/string.h>#include <linux/errno.h>#include <linux/spinlock.h>#include <linux/ethtool.h>#include <linux/delay.h>#include <linux/bitops.h>#include <asm/uaccess.h>#include <asm/io.h>#include <linux/netdevice.h>#include <linux/etherdevice.h>#include <linux/skbuff.h>#include <linux/init.h>#include "3c501.h"Go to the source code of this file.
Macros | |
| #define | DRV_NAME "3c501" |
| #define | DRV_VERSION "2002/10/09" |
Functions | |
| struct net_device *__init | el1_probe (int unit) |
| MODULE_AUTHOR ("Donald Becker, Alan Cox") | |
| MODULE_DESCRIPTION ("Support for the ancient 3Com 3c501 ethernet card") | |
| MODULE_LICENSE ("GPL") | |
| #define DRV_NAME "3c501" |
DOC: 3c501 Card Notes
Some notes on this thing if you have to hack it. [Alan]
Some documentation is available from 3Com. Due to the boards age standard responses when you ask for this will range from 'be serious' to 'give it to a museum'. The documentation is incomplete and mostly of historical interest anyway.
The basic system is a single buffer which can be used to receive or transmit a packet. A third command mode exists when you are setting things up.
If it's transmitting it's not receiving and vice versa. In fact the time to get the board back into useful state after an operation is quite large.
The driver works by keeping the board in receive mode waiting for a packet to arrive. When one arrives it is copied out of the buffer and delivered to the kernel. The card is reloaded and off we go.
When transmitting lp->txing is set and the card is reset (from receive mode) [possibly losing a packet just received] to command mode. A packet is loaded and transmit mode triggered. The interrupt handler runs different code for transmit interrupts and can handle returning to receive mode or retransmissions (yes you have to help out with those too).
DOC: Problems
There are a wide variety of undocumented error returns from the card and you basically have to kick the board and pray if they turn up. Most only occur under extreme load or if you do something the board doesn't like (eg touching a register at the wrong time).
The driver is less efficient than it could be. It switches through receive mode even if more transmits are queued. If this worries you buy a real Ethernet card.
The combination of slow receive restart and no real multicast filter makes the board unusable with a kernel compiled for IP multicasting in a real multicast environment. That's down to the board, but even with no multicast programs running a multicast IP kernel is in group 224.0.0.1 and you will therefore be listening to all multicasts. One nv conference running over that Ethernet and you can give up.
|
read |
el1_probe - probe for a 3c501 : The device structure passed in to probe.
This can be called from two places. The network layer will probe using a device structure passed in with the probe information completed. For a modular driver we use init_module to fill in our own structure and probe for it.
Returns 0 on success. ENXIO if asked not to probe and ENODEV if asked to probe and failing to find anything.
| MODULE_AUTHOR | ( | "Donald | Becker, |
| Alan Cox" | |||
| ) |
| MODULE_LICENSE | ( | "GPL" | ) |
1.8.2