On Thu, Jun 11, 2015 at 05:36:06PM +0300, Marcel Apfelbaum wrote: > On 06/11/2015 05:24 PM, Kevin O'Connor wrote: > >On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote: > >>On 06/11/2015 04:58 PM, Kevin O'Connor wrote: > >>>On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote: > >>>>The fixes solves the following issue: > >>>>The PXB device exposes a new pci root bridge with the > >>>>fw path: /pci-root@4/..., in which 4 is the root bus number. > >>>>Before this patch the fw path was wrongly computed: > >>>> /pci-root@1/pci@i0cf8/... > >>>>Fix the above issues: Correct the bus number and remove the > >>>>extra host bridge description. > >>> > >>>Why is that wrong? The previous path looks correct to me. > >>The prev path includes both the extra root bridge and *then* the usual host > >>bridge. > >> /pci-root@1/pci@i0cf8/ ... > >> ^ new ^ regular ^ devices > >> > >>Since the new pci root bridge (and bus) is on "paralel" with the regular > >>one. > >>it is not correct to add it to the path. > >> > >>The architecture is: > >> /<host bridge>/devices... > >> /extra root bridge/devices... > >> /extra root bridge/devices... > >>And not > >>/extra root bridge//<host bridge>/devices > > > >Your patch changed both the "/extra root bridge/devices..." part and > >the "@1" part. The change of the "@1" in "/pci-root@1/" is not > >correct IMO. > Why? @1 should be the unit address which is the text representation > of the physical address, in our case the slot. Since the bus number > in our case is 4, I think /pci-root@4/ is the 'correct' address.
On real machines, the firmware assigns the 4 - it's not a physical address; it's a logical address (like all bus numbers in PCI). The firmware might assign a totally different number on the next boot. -Kevin