Before starting to write the network driver become completely
familiar with the programmer's view of the device.
The following points list some of the details of the
device that must be understood before a driver can be written.
Does the device use DMA to transfer packets to and from
memory or does the processor have to
copy packets to and from memory on the device?
If the device uses DMA, is it capable of forming a single
outgoing packet from multiple fragments scattered in separate
memory buffers?
If the device uses DMA, is it capable of chaining multiple
outgoing packets, or does each outgoing packet require
intervention by the driver?
Does the device automatically pad short frames to the minimum
64 bytes or does the driver have to supply the padding?
Does the device automatically retry a transmission on detection
of a collision?
If the device uses DMA, is it capable of buffering multiple
packets to memory, or does the receiver have to be restarted
after the arrival of each packet?
How are packets that are too short, too long, or received with
CRC errors handled? Does the device automatically continue
reception or does the driver have to intervene?
How is the device Ethernet address set? How is the device
programmed to accept or reject broadcast and multicast packets?
What interrupts does the device generate? Does it generate an
interrupt for each incoming packet, or only for packets received
without error? Does it generate an interrupt for each packet
transmitted, or only when the transmit queue is empty? What
happens when a transmit error is detected?
In addition, some controllers have specific questions regarding
board specific configuration. For example, the SONIC Ethernet
controller has a very configurable data bus interface. It can
even be configured for sixteen and thirty-two bit data buses. This
type of information should be obtained from the board vendor.
BSP and Device Driver Development Guide