[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