From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRrFC-0007ju-Mm for qemu-devel@nongnu.org; Fri, 17 Jul 2009 13:29:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRrFB-0007jT-Uc for qemu-devel@nongnu.org; Fri, 17 Jul 2009 13:29:14 -0400 Received: from [199.232.76.173] (port=49359 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRrFB-0007jN-Ls for qemu-devel@nongnu.org; Fri, 17 Jul 2009 13:29:13 -0400 Received: from fg-out-1718.google.com ([72.14.220.156]:17882) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MRrFB-00014J-A5 for qemu-devel@nongnu.org; Fri, 17 Jul 2009 13:29:13 -0400 Received: by fg-out-1718.google.com with SMTP id d23so391141fga.8 for ; Fri, 17 Jul 2009 10:29:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A60899E.6020108@codemonkey.ws> References: <200907171104.n6HB4EDY011438@d01av04.pok.ibm.com> <4A60899E.6020108@codemonkey.ws> From: Blue Swirl Date: Fri, 17 Jul 2009 20:28:52 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [Qemu-commits] [COMMIT e813376] Sparc32: fix fdc io_base List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "qemu-devel@nongnu.org" On Fri, Jul 17, 2009 at 5:24 PM, Anthony Liguori wro= te: > Anthony Liguori wrote: >> >> From: Blue Swirl >> >> On some Sparc32 machines, fdc is located above 4G limit, so uint32_t is >> not >> appropriate type for io_base. >> >> Signed-off-by: Blue Swirl >> >> diff --git a/hw/fdc.c b/hw/fdc.c >> index fa154a3..4ad5e5e 100644 >> --- a/hw/fdc.c >> +++ b/hw/fdc.c >> @@ -33,6 +33,7 @@ >> =C2=A0#include "qemu-timer.h" >> =C2=A0#include "isa.h" >> =C2=A0#include "sysbus.h" >> +#include "qdev-addr.h" >> =C2=A0=C2=A0/********************************************************/ >> =C2=A0/* debug Floppy devices */ >> @@ -1972,7 +1973,7 @@ static SysBusDeviceInfo fdc_info =3D { >> =C2=A0 =C2=A0 .qdev.props =3D (Property[]) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .name =3D "io_base", >> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.info =3D &qdev_prop_uint32, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.info =3D &qdev_prop_taddr, >> > > fdc probably shouldn't use target_phys_addr_t and instead should just use= a > uint64_t for io_base. =C2=A0target_phys is a CPU type, devices shouldn't = depend > on it. > > What do you think? Actually, currently target_phys_addr_t is used by most devices as the machine bus address type. It's tied to CPU type but not as tightly as for example TARGET_PAGE_SIZE or target_ulong. In this case, uint64_t would work too.