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

[Nikunj A Dadhania]

David Gibson <david at gibson.dropbear.id.au> writes:

> 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.

I liked your qemu patch that just uses _reverse variant of pci device
find.

>
> 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).

All this is coming from libvirt user not using boot_order in the
commandline. Once that is used there is no confusion over the order that
the user passes the devices.

Regards
Nikunj