Browse Source

clarify eth driver halt/recv steps

The dev->halt() func can be called at any time, and the dev->recv() func
does not need to use NetRxPackets[] when calling NetReceive().

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Mike Frysinger 15 years ago
parent
commit
e5c5d9e083
1 changed files with 8 additions and 5 deletions
  1. 8 5
      doc/README.drivers.eth

+ 8 - 5
doc/README.drivers.eth

@@ -122,10 +122,12 @@ function can be called multiple times in a row.
 
 
 The recv function should process packets as long as the hardware has them
 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.
 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 ape_recv(struct eth_device *dev)
 {
 {
 	int length, i = 0;
 	int length, i = 0;
@@ -145,7 +147,8 @@ int ape_recv(struct eth_device *dev)
 }
 }
 
 
 The halt function should turn off / disable the hardware and place it back in
 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:
 So the call graph at this stage would look something like:
 some net operation (ping / tftp / whatever...)
 some net operation (ping / tftp / whatever...)