Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KzrJH-000496-MP for qemu-devel@nongnu.org; Tue, 11 Nov 2008 06:21:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KzrJF-00047a-Vc for qemu-devel@nongnu.org; Tue, 11 Nov 2008 06:21:27 -0500 Received: from [199.232.76.173] (port=49794 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KzrJF-00047O-AB for qemu-devel@nongnu.org; Tue, 11 Nov 2008 06:21:25 -0500 Received: from batfish.pepperfish.net ([87.237.62.180]:45395 helo=flounder.pepperfish.net) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KzrJF-0000fu-1e for qemu-devel@nongnu.org; Tue, 11 Nov 2008 06:21:25 -0500 Received: from cpc2-asht1-0-0-cust815.manc.cable.ntl.com ([80.5.55.48] helo=[10.19.3.101]) by flounder.pepperfish.net with esmtpsa (Exim 4.68 #1 (Debian)) id 1KzrJ2-0007PI-NT for ; Tue, 11 Nov 2008 11:21:12 +0000 Subject: Re: [Qemu-devel] [PATCH] DM9000 network card driver From: Daniel Silverstone In-Reply-To: References: <1225104596.24465.3.camel@petitemort> <1226313089.10490.3.camel@petitemort> Content-Type: text/plain Date: Tue, 11 Nov 2008 11:21:11 +0000 Message-Id: <1226402471.14868.5.camel@petitemort> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: dsilvers@simtec.co.uk, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, 2008-11-10 at 18:47 +0200, Blue Swirl wrote: > > I appreciate that you're all busy, so if the answer is simply "You're on > > the list, just it'll be a while" then at least I can carry that back to > > my boss who wants to know how it's going getting these patches to you. > Your patch looks very clean. I wouldn't use devices.h for the > prototype, but instead some board file (for example arm-misc.h). I think I was told to use devices.h quite a while back. It's not appropriate to put it in arm-misc.h since the device itself has no specific isolation in ARM stuff. Despite being made to put the HW in the ARM HW bits of the Makefile. > The device is not used by any board, so it's not possible even for the > maintainer to test the patch. It is used by the board I am trying to get all the patches up-to-snuff for. > As there is a reset function already, it should not be too difficult > to register that for system_reset use. Can you explain what you mean by that? > Save/load functions would be nice, though IIRC ARM boards/devices > don't have any yet. Some do, some don't -- a portion of what I have already has save/load support, but this is one device I've not done it for yet. I will continue to look at that. Thank you very much for your feedback. Hopefully if you can explain what this system_reset stuff is, I can get that done and punt a fresh patch to the list. Regards, Daniel. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895