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

Thomas Huth thuth at redhat.com
Fri Nov 27 19:45:59 AEDT 2015


On 27/11/15 09:37, Greg Kurz wrote:
> On Thu, 26 Nov 2015 20:26:50 +0100
> Thomas Huth <thuth at redhat.com> 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 ]
[...]
>> Where does the wrong order come from? Is it QEMU who's doing this wrong
>> already? Then it should maybe be rather fixed there?
> 
> As David mentioned in another mail, the root cause is fdt_add_subnode() inserting
> to the front rather than adding to the end of the list... Since libfdt doesn't
> make it possible, it would be up to QEMU to loop through PCI devices with a
> pci_for_each_device_reverse() function... makes sense ?

IMHO yes, sounds like a better solution to this problem than trying to
fix this in SLOF.

 Thomas



More information about the SLOF mailing list