LM
/
u-boot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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>
This commit is contained in:
Mike Frysinger 2009-11-01 22:39:56 -05:00 committed by Ben Warren
parent 497ab0eec5
commit e5c5d9e083
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
doc/README.drivers.eth
View File

@ -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
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;
@ -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
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...)