Fw: PERFORCE change 101080 for review

[John Baldwin]

On Sunday 09 July 2006 04:22, M. Warner Losh wrote:
> 
> John,
> 
> I think the following change is good reguardless of how the current
> discussions about how to get acpi devices wired falls out.  It
> modifies devclass unit number assignment to treat a pre-existing
> device as 'taken' as well as one that just might be hinted at.
> 
> It has the nice side effect of obviating the need for device_set_unit,
> which I added holding my nose a long time ago.  The reason I didn't go
> with this approach was that at the time (4.x or maybe 3.x) there
> wasn't the hints infrastructure we have today, and I never went back
> to revisit this kludge to remove it.
> 
> Please let me know what you think of this.

Well, I think perhaps you think my wiring stuff is just about serial
ports, but it really would allow us to generically wire unit numbers
based on properties of the device that the bus driver can verify
(resources, location, etc.)  Basically, I want the bus driver to decide
if it wants to "claim" a hint device.  That is, each time we go to probe
a device, if there are any hint-enumerated devices for the child driver
we are probing, we pass the device_t to the parent (bus) device_t and use
a new bus_if.m method to ask the parent bus if it's ok for this device_t
to "take over" the hint device (e.g. if the resources specified in the
hint are a subset of the ACPI or PNPBIOS-enumerated resources).  Since
each bus is free to implement whatever algorithm it wants, we can also
add creative things like:

hint.foo.0.at="pci:0:4:0"  (a PCI bus/device/function)

or

hint.foo.0.at="_SB_.PCI0.ISA0.FOO0"  (an ACPI device name)

because the bus (and not the MI subr_bus.c code) is determines what the
hints mean.

-- 
John Baldwin