From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KpOna-00048R-Gr
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:53:30 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KpOnY-000458-Vz
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:53:30 -0400
Received: from [199.232.76.173] (port=38776 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KpOnY-00044v-OL
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:53:28 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:43736)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1KpOnX-0005ur-UY
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 10:53:28 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] Davicom DM9000 emulation
Date: Mon, 13 Oct 2008 15:53:24 +0100
References: <1223892743.30000.25.camel@petitemort>
	<200810131534.18395.paul@codesourcery.com>
	<1223908623.30000.45.camel@petitemort>
In-Reply-To: <1223908623.30000.45.camel@petitemort>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200810131553.24669.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, dsilvers@simtec.co.uk

On Monday 13 October 2008, Daniel Silverstone wrote:
> 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. 

No it doesn't.

+typedef struct {
+    uint32_t addr; /* address port */
[...]
+    state->addr = base_addr + addr_offset;

Will truncate the address to 32 bits.

On closer inspection I notice that the data member of the state structure is 
never used, and the device will respond to any accesses within the range you 
reserve, not just the data address.

Paul