I've been looking at v2 and v3 HT code. It seems like the biggest problem is that we changed the representation of the device tree and didn't change the code.
I think it would be best to have the dts match an lspci as closely as possible. That means the code has to be a little smarter so that it can fill in the missing information.
If we start with a dts which describes the Serengeti machine, we have:
/{ device_operations="serengeti"; mainboard_vendor = "AMD"; mainboard_name = "Serengeti"; cpus { }; apic@0 { }; domain@0 { /config/("northbridge/amd/k8/domain"); pci0@18,0 { /config/("northbridge/amd/k8/pci"); pci@0,0 { /config/("southbridge/amd/amd8111/pci.dts"); pci@1,0{ /config/("southbridge/amd/amd8111/nic.dts"); }; }; pci@1,0 { /config/("southbridge/amd/amd8111/lpc.dts"); }; pci@1,1 { /config/("southbridge/amd/amd8111/ide.dts"); }; pci@1,0{ /config/("southbridge/amd/amd8132/pcix.dts"); };
}; pci1@18,0 { /config/("northbridge/amd/k8/pci"); }; pci2@18,0 { /config/("northbridge/amd/k8/pci"); }; pci@18,1 {}; pci@18,2 {}; pci@18,3 {}; ioport@2e { /config/("superio/winbond/w83627hf/dts"); com1enable = "1"; }; }; };
It doesn't exactly match an lspci, because lspci doesn't care what link the devices are on. I think we have to keep that difference.
Then when the hypertransport enumeration code runs, the bridges appear to be siblings of their children. With v2 there was another layer of hierarchy so that the children of link 0 would just be the 8132 and the 8111.
So the new code should: 1. Scan the list of children for bridges 2. Assign the devices bus numbers and attach them correctly
Does that mean that we need to create dynamic bus devices or structures to hold that information? Probably not. We can just change pointer assignments.
I don't think we need to expand the dts to fix this, we just need to make the code match the structure.
Thanks, Myles