From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAphX-000534-6W for qemu-devel@nongnu.org; Sun, 20 Dec 2015 20:55:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAphU-0005Rv-0k for qemu-devel@nongnu.org; Sun, 20 Dec 2015 20:55:51 -0500 Date: Mon, 21 Dec 2015 12:56:24 +1100 From: David Gibson Message-ID: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kG2acDqmwoBDcCHP" Content-Disposition: inline In-Reply-To: <20151217094329.112a3bc9@bahia.local> 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: Greg Kurz Cc: Thomas Huth , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, "Michael S. Tsirkin" --kG2acDqmwoBDcCHP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > On Tue, 1 Dec 2015 22:48:38 +0100 > > Thomas Huth wrote: > >=20 > > > 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 SLO= F. > > > >=20 > > > > Before 1d2d974244c6: > > > >=20 > > > > 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 > > > >=20 > > > >=20 > > > > 7e5294b8 : /pci@800000020000000 > > > > 7e52b998 : |-- ethernet@0 > > > > 7e52c0c8 : |-- scsi@1 > > > > 7e52c7e8 : +-- unknown-legacy-device@2 ok > > > >=20 > > > > Since 1d2d974244c6: > > > >=20 > > > > 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 ] > > > >=20 > > > >=20 > > > > 7e5e8118 : /pci@800000020000000 > > > > 7e5ea6a0 : |-- unknown-legacy-device@2 > > > > 7e5eadb8 : |-- scsi@1 > > > > 7e5eb4d8 : +-- ethernet@0 ok > > > >=20 > > > > This behaviour change is not actually a bug since no assumptions sh= ould 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 elem= ents > > > > to the front of the FDT rather than adding them to the tail. > > > >=20 > > > > This patch reverts to the historical SLOF ordering by walking PCI d= evices in > > > > reverse order. > > >=20 > > > I've applied your patch here locally, and indeed, the device tree loo= ks > > > nicer to me, too, when the nodes are listed in ascending order. > > >=20 > > > Tested-by: Thomas Huth > > >=20 > > >=20 > >=20 >=20 > 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. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --kG2acDqmwoBDcCHP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWd1xIAAoJEGw4ysog2bOS8egQAK8Ap4JuU6SNfdLpkPYDju/M oozegn7REcIBbBVjYitzsHJapK4hJnJTENvcTMX58nDcT9VfcjaYLeVwZXQt90r5 Buys3rRXKJeqnG/iyPVs++nsTz+E0gOdC+naT8+IDYy/oybFgW9uOPH4JETWb2MF eNsU834+JGB9WcAi/mFTuycgku9L2bwkGA+EOxCS3zR6ROnllkZtRcltgI4gmguw r/43QYv1fPUhd2yAmNpjKFSpvcsOQ1IKBhR/uZQnOshmPj+RlulB2m2YVES7t9eY MxEhRspPFrSuSjfmNr/SDT5fa902xM7+bjb83GbAfYsUD3mEPBWcDDyQuVwpdiWN f+Fv/NneYocMNLvl2gl/RsbpO4XbuEfa+SJDXnvOCXAfzhUByZEQm/tWoaUWq8bR EKCl4uCsjfOhDO+g6i6/Rc3dPZxN+3oBuwVYydb+TnrUjKfxFRortQs6IhuJMGMO XdDiHOVWzFZZh0aPxe3BtTR+auvlRjRfQ9i5lUZrJCdfA0e8nxUyubHcJpiB9cq8 AFwG2Z7Roy/xjnTsYXkjTpHrjxiUdLB3VEk8Vunmyz4HgEh/iyL0cfV9IYsv4FFK isZFUUSq8pKkGm/NvnlzkFod+yoSAGifGm+iuyP0QG0JhvKVgcPr/QG/Y2thEIY7 SioBgw8MtHdWWqNjhlsF =N8vZ -----END PGP SIGNATURE----- --kG2acDqmwoBDcCHP--