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

clarify eth driver halt/recv steps

Browse Source 
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 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 For each packet you receive, you should call the NetReceive() function on it
is no need to allocate your own. For each packet you receive, you should call along with the packet length. The common code sets up packet buffers for you
the NetReceive() function on it with the packet length. So the pseudo code already in the .bss (NetRxPackets), so there should be no need to allocate your
here would look something like: 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...)