Mike Frysinger <vap...@gentoo.org> writes: > 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.
Ok. Sure, that's not a problem for me, I just noted the README doesn't talk about this. >> - 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() Let's look... The code does NetSetHandler(TftpHandler). I think NetReceive() calls (*packetHandler)() = TftpHandler and this one may call NetStartAgain(). > 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 see. Thanks for your mail. -- Krzysztof Halasa _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
