On Sat, Oct 16, 2010 at 03:22:52PM +0300, Jukka Ruohonen wrote: > On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote: > > The main difference that I understood seems to be what you call virtual > > and natural device trees: in OF world we guide the whole autoconfig tree > > along the OF device tree, with differences close to the leafs (i.e. the > > scsibus der Mouse mentioned). At every point during autoconfig we can > > make sure to have enough OF information already available during the > > device_register() call. The only problem we ran into so far, IIRC, is the > > id of FC disks for boot device detection, but we worked around that pretty > > easily. > > This seems to be what is needed on x86 as well. The only way to eliminate > such things as PCI_BUS_FIXUP etc. and several existing bus_space(9) > conflicts is probably to parse the firmware tree as the first thing, and > then utilize this information at each attachment step. This is exactly what > I meant by noting that we tend to think this backwards; perhaps ACPI should > drive the autoconfiguration, not vice versa. It is problematic to think > that we can continue as business as usual, and then ACPI drivers go and seek > their real counterparts that have been attached without using ACPI in the > first place.
It sounds like your idea of ACPI's role in autoconfiguration is not too different from Martin's and mine, but you may be using different language to describe it. I think that ACPI should definitely guide autoconfiguration, if ACPI is available. > Another thing is the actual device tree. For instance, currently, even with > the fine work done with pmf(9), in some corner cases we may power off a > device before its children are turned off because the device tree is > partially arbitrary. What devices do you have in mind? Dave -- David Young OJC Technologies [email protected] Urbana, IL * (217) 278-3933
