From mboxrd@z Thu Jan 1 00:00:00 1970 From: Krzysztof Halasa Date: Mon, 02 Nov 2009 16:08:00 +0100 Subject: [U-Boot] Net driver questions In-Reply-To: <200911012232.11058.vapier@gentoo.org> (Mike Frysinger's message of "Sun, 1 Nov 2009 23:32:10 -0400") References: <200911012232.11058.vapier@gentoo.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Mike Frysinger 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