Commit e5c5d9e0 authored by Mike Frysinger's avatar Mike Frysinger Committed by Ben Warren

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: 's avatarMike Frysinger <vapier@gentoo.org>
Signed-off-by: 's avatarBen Warren <biggerbadderben@gmail.com>
parent 497ab0ee
......@@ -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...)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment