On Mon, Jan 5, 2015 at 5:41 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 5 January 2015 at 16:14, alvise rigo <a.r...@virtualopensystems.com> wrote: >> On Mon, Jan 5, 2015 at 4:36 PM, Peter Maydell <peter.mayd...@linaro.org> >> wrote: >>> Sorry, I think I must have missed this series first time around. >>> I'm not convinced -- I don't see any reason why we should treat >>> the PCI host controller differently from other devices in the >> >> The reason for this is that the PCI host controller needs to generate >> its device node after all the PCI devices have been added to the bus >> (also those specified with the -device option). >> This is required by the interrupt-map node property, that specifies >> for each PCI device an interrupt map entry. Since we have one device >> requiring this 'postponed' node generation, this patch allows also >> other devices to do the same. > > What? This doesn't sound right -- you can have hot-plugged PCI > devices, for a start. Device tree is only supposed to be > needed for the bits of hardware that can't be probed, and > we can rely on PCI itself to probe the other devices.
OK, I see. > > interrupt-map as far as I can tell just specifies how the > interrupt lines are mapped for each PCI slot; it won't > change based on whether devices are present or not. The > example in the wiki: > http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping > cares about number of slots, but that's all. So I suppose we need to define a fixed number of PCI slots according to the number of interrupts available in mach-virt. In this regard, should this number be a qdev property? Thank you, alvise > > thanks > -- PMM
