From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLDqK-0005AS-Nn for qemu-devel@nongnu.org; Mon, 08 Oct 2012 09:58:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLDqF-0006yh-SO for qemu-devel@nongnu.org; Mon, 08 Oct 2012 09:58:00 -0400 Message-ID: <5072DBDD.7020600@suse.de> Date: Mon, 08 Oct 2012 15:57:49 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1349265000-23834-1-git-send-email-Bharat.Bhushan@freescale.com> <1349265000-23834-3-git-send-email-Bharat.Bhushan@freescale.com> <506D81B3.2040401@redhat.com> <6A3DF150A5B70D4F9B66A25E3F7C888D064B2BBD@039-SN2MPN1-022.039d.mgd.msft.net> <506DA3FA.2080404@redhat.com> <6A3DF150A5B70D4F9B66A25E3F7C888D064B30CC@039-SN2MPN1-022.039d.mgd.msft.net> <391CE0AF-0853-4EA5-9983-A9F0AC316C71@suse.de> <6A3DF150A5B70D4F9B66A25E3F7C888D064B410A@039-SN2MPN1-022.039d.mgd.msft.net> <6A3DF150A5B70D4F9B66A25E3F7C888D064B64E7@039-SN2MPN1-022.039d.mgd.msft.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-devel@nongnu.org qemu-devel" , "qemu-ppc@nongnu.org List" , Avi Kivity , Bhushan Bharat-R65777 Am 08.10.2012 10:50, schrieb Alexander Graf: >=20 > On 08.10.2012, at 10:23, Bhushan Bharat-R65777 wrote: >>>> @@ -307,6 +313,16 @@ static const VMStateDescription >>>> vmstate_ppce500_pci =3D { >>>> >>>> #include "exec-memory.h" >>>> >>>> +static int e500_pcihost_bridge_initfn(PCIDevice *d) { >>>> + bharat *b =3D DO_UPCAST(bharat, p, d); >>>> + >>>> + printf("Addr =3D %llx, size =3D %llx\n", ((MemoryRegion *)b->ba= r0)->addr, >>> (unsigned long long)int128_get64(((Me >>>> + pci_register_bar(d, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, >>>> + (MemoryRegion *)b->bar0); >>> >>> That one still has to call its parent initfn, no? >> >> I am really sorry, but I did not get. The object says its parent is TY= PE_PCI_DEVICE, so which function are you talking about? >=20 > In object oriented programming, every time you overload a class, your c= onstructor should call the overloaded class's constructor. I don't see th= is happening for other PCI device's init functions though. >=20 > Andreas, shouldn't parent class init be called for pci subclass devices= ? .class_init and .instance_init are called iteratively through the hierarchy, so no parent method needs to be called manually. This is different for user-coded methods like CPUState::reset. qdev initfns haven't changed in that respect to date - they are orthogonal to QOM. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg