PERFORCE change 43464 for review

[M. Warner Losh]

In message: <XFMail.20031209134426.jhb at FreeBSD.org>
            John Baldwin <jhb at FreeBSD.org> writes:
: 
: On 09-Dec-2003 M. Warner Losh wrote:
: > In message: <XFMail.20031208155247.jhb at FreeBSD.org>
: >             John Baldwin <jhb at freebsd.org> writes:
: >: 
: >: On 05-Dec-2003 Nate Lawson wrote:
: >: > On Fri, 5 Dec 2003, John Baldwin wrote:
: >: >> Change 43464 by jhb at jhb_blue on 2003/12/05 12:59:01
: >: >>
: >: >>      More updates.  Closer to working than I thought.  In theory
: >: >>      PCI devices should all just work now.
: >: > 
: >: > This handles PCI.  Are you ok with me adding the call to
: >: > acpi_pwr_switch_consumer() for non-PCI devices like the embedded
: >: > controller?  I think we need to do this at the top \\_SB level.  I'm a bit
: >: > confused as to the handoff between the general tree walk and the ACPI-PCI
: >: > driver though.
: >: 
: >: It won't hurt to switch a device on twice.  It should be ok to
: >: do a top-level tree walk of all device objects and turn them on
: >: before probing child devices I think.  ACPI shouldn't turn off
: >: devices that don't probe like PCI does though because ACPI has
: >: duplicate objects of things like the entire PCI device tree. :-/
: > 
: > Actually, there can be times when you don't want to turn on devices at
: > all.  Walking the whole tree turning them on might be the wrong to
: > do...
: > 
: > Sometimes I think that things in the newbus tree should have a pointer
: > to the acpi power methods that are used in coordination with the bus
: > code that is 'activating' the device before the 'probe' and 'attach'
: > happens.
: 
: I think having a 'bus_set_power_state()' method in the bus layer
: and having device_probe_and_attach() do 'bus_set_power_state(child, ON)'
: would be sufficient.  ACPI busses would then perform the correct hooks
: via their bus_set_power_state() methods.

That is very close to what I had in mind.  My only 'debate' was 0/1 or
0,1,2,3 or ????

Warner