Well, "enable" and "disable" are pretty obvious -- but what does
it mean to enable a device (say, a disk) that depends on another
device (say, a controller) unless you first enable the controller?
There are obvious ordering constraints here.

Of course, this argues that the en/dis-able *should* be in the
config tree, so that generic code can ensure that everything "upstream"
of a device is already on, or that the most-downstream device is turned
off first.  But one problem here is that existing hardware does not
cooperate properly: the power-on-auxXX sparcs, for instance, have
their ordering constraints independent of the "apparent tree", as
it were.

USB is likely to have similar oddities, but I have never dealt
with any USB hardware.

Also, for power management, there are already three states for
some devices: "full on", "standby", and "off".

The real danger, as always, is that if you generalize too soon,
you can come up with models that do not cover the interesting
cases.  For instance, you might come up with device trees, and
fail to handle disks with multipath controllers... :-)

Chris