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