[SLOF] [PATCH] pci: walk through the PCI DT in reverse order

[David Gibson]

On Thu, Nov 26, 2015 at 08:26:50PM +0100, Thomas Huth wrote:
> On 26/11/15 17:34, Greg Kurz wrote:
> > With the same set of devices, if QEMU does not do the PCI Enumeration (old
> > QEMU that doesn't set the qemu,phb-enumerated property), we get:
> > 
> > Populating /pci at 800000020000000
> >  Adapters on 0800000020000000
> >                      00 0800 (D) : 1af4 1000    virtio [ net ]
> >                      00 1000 (D) : 106b 003f    serial bus [ usb-ohci ]
> >                      00 1800 (D) : 1af4 1003    communication-controller*
> >                      00 2000 (D) : 1af4 1001    virtio [ block ]
> >                      00 2800 (D) : 1af4 1001    virtio [ block ]
> >                      00 3000 (D) : 1af4 1001    virtio [ block ]
> >                      00 3800 (D) : 1af4 1002    unknown-legacy-device*
> > 
> > but in the case of a newer QEMU, when SLOF walks through the DT, we get:
> > 
> > Populating /pci at 800000020000000
> >                      00 3800 (D) : 1af4 1002    unknown-legacy-device*
> >                      00 3000 (D) : 1af4 1001    virtio [ block ]
> >                      00 2800 (D) : 1af4 1001    virtio [ block ]
> >                      00 2000 (D) : 1af4 1001    virtio [ block ]
> >                      00 1800 (D) : 1af4 1003    communication-controller*
> >                      00 1000 (D) : 106b 003f    serial bus [ usb-ohci ]
> >                      00 0800 (D) : 1af4 1000    virtio [ net ]
> > 
> > This is a confusing behaviour change for users. This patch fixes that: we
> > push all the child nodes to the stack and configure them in reverse order.

Really?  I mean the change this causes in kernel discovery order I can
see the problem with, although you're not supposed to depend on
discovery order or default kernel naming.  Is the simple order of
listing the devices really important?

> With your patch, the output during boot is in the right order, but the
> nodes in the device tree are still ordered wrong (type "dev /" and then
> "ls" at the SLOF prompt).
> Where does the wrong order come from? Is it QEMU who's doing this wrong
> already? Then it should maybe be rather fixed there?

qemu did change the order things get emitted into the flattened tree
(because fdt_add_subnode() adds to the front of the list of children)
- but things are not supposed to rely on the order of things in the
fdt.  If you care about order you're supposed to sort them yourself
(on reg value, or whatever criterion makes sense).

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20151127/200c46fd/attachment.sig>