From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBcGv-0001qj-D7 for qemu-devel@nongnu.org; Wed, 23 Dec 2015 00:47:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBcGs-0002nA-64 for qemu-devel@nongnu.org; Wed, 23 Dec 2015 00:47:37 -0500 Received: from e28smtp01.in.ibm.com ([125.16.236.1]:52327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBcGr-0002m6-F9 for qemu-devel@nongnu.org; Wed, 23 Dec 2015 00:47:34 -0500 Received: from localhost by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 Dec 2015 11:17:28 +0530 From: Nikunj A Dadhania In-Reply-To: <20151221015624.GT3011@voom.redhat.com> References: <20151130104331.11064.57278.stgit@bahia.huguette.org> <565E15B6.60501@redhat.com> <20151203155317.46a4f446@bahia.local> <20151217094329.112a3bc9@bahia.local> <20151221015624.GT3011@voom.redhat.com> Date: Wed, 23 Dec 2015 11:17:16 +0530 Message-ID: <87r3id1ztn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] spapr/pci: populate PCI DT in reverse order List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , Greg Kurz Cc: Thomas Huth , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, "Michael S. Tsirkin" David Gibson writes: > On Thu, Dec 17, 2015 at 09:43:29AM +0100, Greg Kurz wrote: >> On Thu, 3 Dec 2015 15:53:17 +0100 >> Greg Kurz wrote: >> >> > On Tue, 1 Dec 2015 22:48:38 +0100 >> > Thomas Huth wrote: >> > >> > > On 30/11/15 11:45, Greg Kurz wrote: >> > > > Since commit 1d2d974244c6 "spapr_pci: enumerate and add PCI device tree", QEMU >> > > > populates the PCI device tree in the opposite order compared to SLOF. >> > > > >> > > > Before 1d2d974244c6: >> > > > >> > > > Populating /pci@800000020000000 >> > > > 00 0000 (D) : 1af4 1000 virtio [ net ] >> > > > 00 0800 (D) : 1af4 1001 virtio [ block ] >> > > > 00 1000 (D) : 1af4 1009 virtio [ network ] >> > > > Populating /pci@800000020000000/unknown-legacy-device@2 >> > > > >> > > > >> > > > 7e5294b8 : /pci@800000020000000 >> > > > 7e52b998 : |-- ethernet@0 >> > > > 7e52c0c8 : |-- scsi@1 >> > > > 7e52c7e8 : +-- unknown-legacy-device@2 ok >> > > > >> > > > Since 1d2d974244c6: >> > > > >> > > > Populating /pci@800000020000000 >> > > > 00 1000 (D) : 1af4 1009 virtio [ network ] >> > > > Populating /pci@800000020000000/unknown-legacy-device@2 >> > > > 00 0800 (D) : 1af4 1001 virtio [ block ] >> > > > 00 0000 (D) : 1af4 1000 virtio [ net ] >> > > > >> > > > >> > > > 7e5e8118 : /pci@800000020000000 >> > > > 7e5ea6a0 : |-- unknown-legacy-device@2 >> > > > 7e5eadb8 : |-- scsi@1 >> > > > 7e5eb4d8 : +-- ethernet@0 ok >> > > > >> > > > This behaviour change is not actually a bug since no assumptions should be >> > > > made on DT ordering. But it has no real justification either, other than >> > > > being the consequence of the way fdt_add_subnode() inserts new elements >> > > > to the front of the FDT rather than adding them to the tail. >> > > > >> > > > This patch reverts to the historical SLOF ordering by walking PCI devices in >> > > > reverse order. >> > > >> > > I've applied your patch here locally, and indeed, the device tree looks >> > > nicer to me, too, when the nodes are listed in ascending order. >> > > >> > > Tested-by: Thomas Huth >> > > >> > > >> > >> >> Ping ? > > Sorry I didn't reply. > > I'm still dubious about this. It seems like a fair bit of effort to > restore a behaviour that the client isn't supposed to be relying on > anyway. > > Plus, the version with the changed order is already released, so > applying this will mean a second behaviour change. The behaviour change was not intentional by me, so I would vote for restoring the old order. Reviewed-by: Nikunj A Dadhania Regards Nikunj