On Fri, 30 Jul 2010, David Young wrote: > On Thu, Jul 29, 2010 at 11:20:39AM +0300, Jukka Ruohonen wrote: > > A small note: focusing on isa(4), legacy drivers, and their configuration > > hides the real issue, which is that we need a 1:1 mapping between the normal > > and the ACPI device tree. This is not optional if we ever want to make any > > advances for instance in PCI power management. Another example: we have > > pending device drivers on the ACPI side that need to know about vga(4). > > What will be there for isa(4), should be there also for pci(4). > > I agree. The issue is larger: there also has to be coordination > between, on the one side, ISA Plug 'N' Play, PCI BIOS, ACPI, > OpenFirmware, and so on; and on the other side, isa(4) i2c(4), pci(4), > et cetera. > > Just for example, I'm trying to put PCI bus space under stricter control > of the kernel, and that requires coordinating the bus-space allocations > already made by PCI BIOS, for example, with allocations made by NetBSD. > On i386, device properties convey the PCI BIOS information to MI PCI > drivers. I reckon that on sparc64, the same device properties will > derive from OpenFirmware.
Yeah. That's why I think we should be using properties on the device node to pass locator information and all the other stuff we use the confg attach args structure for. When a device node is created, the creator (if it's explicitly creatd) attaches properties desccribing the node and things like bus tags, then the locator information is attached to the device node by config, and a MD routine should be called to so firmware properties can be added. That way drivers can query for MD information in a MI way, and you could potentially have one driver that could attach itself to many different buses without requiring bus-specific routines. Now I will save you from a rant about why I hate the existing PCI framwork and think it's badly broken. All the world is a PC. Eduardo
