Stefan Reinauer <stepan(a)suse.de> writes:
* Eric W. Biederman <ebiederman(a)lnxi.com>
think it's pretty easy doable if the bus number registers of the
bridges are filled reliably. Is this the case?
Yes. And the bus number values are also in the device tree. Which
is where it would be better to read them from. Just in case we have
a non-standard pci bus. Like the Opteron's multiple host bridges
off of one cpu.
in the openfirmware kind of view a device node vs node property
consideration. Does a single slot need more information than the fact
that it's there?
Yes. Which the irq routing information.
This information is also held in the pirq table. Can it be generated
from there or are there other caveats?
The pirq routing information has a slightly different flavor and
slightly different rules but in principle we want to generate it
from the same tree as well.
It would be nice if a new board
only needs an adapted pirq table, no matter whether it provides an
mptable or not.
There are boards that a pirq routing table simply does not work
for, because not all interrupts go through the pirq router. For those
boards we either we need to just go through the mptable, or we
need to pre route the irqs and fill in the routing in pci space.
Pre routing the irqs is the most compatible with multiple kernels and
Even in cases where pirq tables work there are not forced
correspondences from how an irq line is routed into a pirq router and
an ioapic. So we probably need separate routing information from
irq lines to the ioapics and to the pirq routers. With the
possibility for older boards of no router being present at all.
What is required in LinuxBIOS is enough information to do the
Once we get that we can figure out how to export that information
via the LinuxBIOS table, the mptable, and pirq table. I am tempted at
that point to move the mptable and pirq table generation code into
mkelfImage, and to start looking at having the kernel support the
LinuxBIOS table directly.
But for now need a way to represent that information.