From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpOXj-0002Wy-IH for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:37:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpOXi-0002Wc-O1 for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:37:06 -0400 Received: from [199.232.76.173] (port=35710 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpOXi-0002WV-H5 for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:37:06 -0400 Received: from batfish.pepperfish.net ([87.237.62.180]:46586 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 1KpOXh-0002DI-Rj for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:37:06 -0400 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 1KpOXg-0000pP-Eb for ; Mon, 13 Oct 2008 15:37:04 +0100 Subject: Re: [Qemu-devel] [PATCH] Davicom DM9000 emulation From: Daniel Silverstone In-Reply-To: <200810131534.18395.paul@codesourcery.com> References: <1223892743.30000.25.camel@petitemort> <1223906508.30000.34.camel@petitemort> <1223907613.30000.42.camel@petitemort> <200810131534.18395.paul@codesourcery.com> Content-Type: text/plain Date: Mon, 13 Oct 2008 15:37:03 +0100 Message-Id: <1223908623.30000.45.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-10-13 at 15:34 +0100, Paul Brook wrote: > > Also, it appears that some devices don't have the headers required for > > target_phys_addr_t included before they include devices.h so I had to > > use an #ifdef around the dm9000_init declaration. If this isn't right > > then I need to know what the right thing to include in such drivers is. > > It seems a bit unfortunate to force other drivers to include headers > > they were otherwise managing without. > Using target_phys_addr_t is a lie. Your device only implements 32 bits of > address space. The implementation only allows for the two registers to be up to a 32-bit address space apart, but it allows for the base of the device to be at any part of the target's physical address space. It's not unreasonable IMO. If you think it is, then I can reduce it to uint32_t but that loses semantic information regarding the base address (that it is physical). Regards, Daniel. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895