[coreboot] [PATCH] v3: fix PCI bus scan / device tree interaction
c-d.hailfinger.devel.2006 at gmx.net
Fri Aug 29 22:36:38 CEST 2008
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.
- 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 means our model (at least for bus/bridge/device) is consistent and
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
> 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.
More information about the coreboot