function which in turn takes care of initializing that particular instance.
Keep in mind that you should code the driver to avoid storing state in global
-data as someone might want to hook up two of the same devices to one board. If
-the state is maintained as global data, it makes using both of those devices
-impossible.
+data as someone might want to hook up two of the same devices to one board.
+Any such information that is specific to an interface should be stored in a
+private, driver-defined data structure and pointed to by eth->priv (see below).
So the call graph at this stage would look something like:
board_init()
miiphy_register(dev->name, ape_mii_read, ape_mii_write);
#endif
- return 0;
+ return 1;
}
The exact arguments needed to initialize your device are up to you. If you
need to pass more/less arguments, that's fine. You should also add the
-prototype for your new register function to include/netdev.h. You might notice
-that many drivers seem to use xxx_initialize() rather than xxx_register().
-This is the old naming convention and should be avoided as it causes confusion
-with the driver-specific init function.
+prototype for your new register function to include/netdev.h.
+
+The return value for this function should be as follows:
+< 0 - failure (hardware failure, not probe failure)
+>=0 - number of interfaces detected
+
+You might notice that many drivers seem to use xxx_initialize() rather than
+xxx_register(). This is the old naming convention and should be avoided as it
+causes confusion with the driver-specific init function.
Other than locating the MAC address in dedicated hardware storage, you should
not touch the hardware in anyway. That step is handled in the driver-specific
The recv function should process packets as long as the hardware has them
readily available before returning. i.e. you should drain the hardware fifo.
-The common code sets up packet buffers for you already (NetRxPackets), so there
-is no need to allocate your own. For each packet you receive, you should call
-the NetReceive() function on it with the packet length. So the pseudo code
-here would look something like:
+For each packet you receive, you should call the NetReceive() function on it
+along with the packet length. The common code sets up packet buffers for you
+already in the .bss (NetRxPackets), so there should be no need to allocate your
+own. This doesn't mean you must use the NetRxPackets array however; you're
+free to call the NetReceive() function with any buffer you wish. So the pseudo
+code here would look something like:
int ape_recv(struct eth_device *dev)
{
int length, i = 0;
}
The halt function should turn off / disable the hardware and place it back in
-its reset state.
+its reset state. It can be called at any time (before any call to the related
+init function), so make sure it can handle this sort of thing.
So the call graph at this stage would look something like:
some net operation (ping / tftp / whatever...)