[U-Boot] Net driver questions

[Mike Frysinger]

On Sunday 01 November 2009 18:07:43 Krzysztof Halasa wrote:
> I'm trying to port the Ethernet driver for Intel IXP4xx CPU from Linux
> (I know there is Intel's code already ported). I've read the
> doc/README.drivers.eth. I came across some problems:
> - dev->halt() seems to be called before the first call to
>   dev->init() (i.e., before the hardware is initialized). Is it on
>   purpose?

it's on purpose because it makes the code simpler -- no need to maintain 
state.  drivers have to be able to handle halt() irregardless of init().  i 
dont see this being a problem for anyone.

> - dev->recv() seems to be called recursively, for example while doing
>   "dhcp" or "bootp" (ping is ok). dev->recv() in my driver calls
>   NetReceive(), which in turn (without returning to the caller, i.e.,
>   dev->recv(), first) reinitializes the driver on error (calls
>   dev->halt() and dev->init()). This makes a lot of mess in the driver,
>   should it stay this way? Perhaps we should queue the received packets
>   and process them on return from dev->recv()? Or maybe return all those
>   packets together?

where exactly do you see that call path ?  i dont see it anywhere ...

NetReceive() may call eth_send(), but that only expands into dev->send()

> - dev->recv() is provided with RX packet buffers. IXP4xx can only
>   receive to already allocated memory so the driver has to provide it's
>   own buffers prior to dev->recv(). I assume it's common situation with
>   all hardware recent enough. Does the driver have to copy data to
>   NetRxPackets[], or is it ok to simply call NetReceive using driver's
>   buffers?

the NetRxPackets[] are set up for you by default and are merely a convenience.  
you can use them or not, it doesnt really matter.  after all, your driver is 
what calls NetReceive() and the first argument there is the buffer that you're 
receiving.  none of the internal network code relies on these pointers.

i'll send out a patch to cover some of the finer details in the drivers doc.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091101/d705474f/attachment.pgp