qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PULL 00/22] ppc patch queue 2011-10-30


From: Anthony Liguori
Subject: Re: [Qemu-ppc] [Qemu-devel] [PULL 00/22] ppc patch queue 2011-10-30
Date: Wed, 02 Nov 2011 15:11:12 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 11/02/2011 02:59 PM, Blue Swirl wrote:
On Tue, Nov 1, 2011 at 21:41, Anthony Liguori<address@hidden>  wrote:
On 11/01/2011 04:05 PM, Blue Swirl wrote:

Thanks, pulled and reverted libfdt patch.

Er, this broke the build:

  CC    ppc64-softmmu/spapr_pci.o
/home/anthony/git/qemu/hw/spapr_pci.c: In function ‘find_dev’:
/home/anthony/git/qemu/hw/spapr_pci.c:54:9: error: ‘struct ChildrenHead’ has
no member named ‘lh_first’
/home/anthony/git/qemu/hw/spapr_pci.c:54:9: error: ‘struct<anonymous>’ has
no member named ‘le_next’
/home/anthony/git/qemu/hw/spapr_pci.c: In function
‘spapr_populate_pci_devices’:
/home/anthony/git/qemu/hw/spapr_pci.c:400:5: error: ‘struct ChildrenHead’
has no member named ‘lh_first’
/home/anthony/git/qemu/hw/spapr_pci.c:400:5: error: ‘struct<anonymous>’ has
no member named ‘le_next’
make[1]: *** [spapr_pci.o] Error 1
make: *** [subdir-ppc64-softmmu] Error 2

This is from commit:

commit 3384f95c59e5db381cf3e605c8acec71baf0e6b8
Author: David Gibson<address@hidden>
Date:   Sun Oct 30 17:16:46 2011 +0000

    pseries: Add partial support for PCI

And specifically:

        QLIST_FOREACH(qdev,&phb->host_state.bus->qbus.children, sibling) {
            PCIDevice *dev = (PCIDevice *)qdev;
            if (dev->devfn == devfn) {
                return dev;
            }
        }

QBus::children is a QTAILQ, not a QLIST.

Was this code tested at all?

I built it and ran a quick test for PPC.
7f7623662781fa152c5aa39fd63a2e8766516a2c still builds fine here.
Though I don't have libfdt and no test for pseries.

Yeah, libfdt isn't packaged widely still so it's understandable. We run into this a lot.

Pulling it in as a submodule is probably a good idea.

Regards,

Anthony Liguori



reply via email to

[Prev in Thread] Current Thread [Next in Thread]