On 29.08.2008 21:20, ron minnich wrote: > so let's do this. Use the new v2 device tree visualizer on serengeti > and see how it looks. > > The evolution of v2 device tree turned into a mess when the acpi and > domain stuff came in. i did the best I could with moving the code over > and trying to untangle it but obviously I did not do enough. At the > same time, I was trying very hard not to break v2 behaviour, since v2 > behaviour is "tricky", but tricky for very good reasons -- it is > working with lots of weird hardware. > > "There is only one link on this device, and it is always link 0."-- > that comment may have been introduced by me as I tried to puzzle > through the v2 device tree code. I am not sure. It is not there in v2. >
Having read the PCI Bridge spec a few minutes ago, this looks rather clear to me. - We want to be able to scan a bus and represent it in memory, so we have to store a struct bus for it. That would be dev_bus_0.link[0]. - We also want to be able to represent a bus in the device tree to be able to correlate it with the devices on that bus, so we have to keep a struct device around as container for it. That would be dev_bus. - We also need to represent the parent bus of a device and the parent of that bus. That means our model (at least for bus/bridge/device) is consistent and makes sense. However, I have yet to read up on PCI domains, so I won't comment on that. > Given the fragility of the device tree code I'd say be very careful > about big changes. Lots of people have broken the device tree code in > the past with trivial changes. Stefan was right, my ACK was probably a > mistake. > > This fragility is a reflection of how difficult device enumeration on > PCs is. There are lots of bugs and corner cases to cover in the > hardware, and it makes it hard to get it just right. Further, as > mentioned, the evolution of hardware had major impact on the code over > the last 8 years. > > I will review this discussion and try to understand the implications again. > > I would suggest our first step is a v3 tree visualizer like the one in > v2. This can be done with a mod to dtc. I think better understanding > should precede any further device code patches. It is clear from this > discussion that we need to know more, and that even core developers > don't always know all the complications. > By the way, I managed to break dtc while working on this: dtc only uses dev_fn as identifier for a PCI device. That gets us a name collision if we have the same dev_fn combination on multiple buses. Either we add a random unique ID to the struct name or we integrate the number of the parent bus as well. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
