On Sun, 27 Mar 2005, Adam Belay wrote: > Dynamic power management may require devices and drivers to transition > between various physical and logical states. I would like to start a > discussion on how these might be defined at the bus, driver, and class > levels. <snip> > Bus Level > ========= > At the bus level, there are two state attributes, power and > enable/disable. Enable/disable may mean different things on different > buses, but they generally refer to resource decoding. A device can only > be enabled during a non-off power state. <...> > Driver Level > ============ > At the driver level there are two areas of interest, physical and > logical state. There is an additional concern of transitioning between > these states multiple times. Because a driver acts as a bridge between > physical and logical components, I think separating these steps seems > natural. <...> > *attach - allocates data structures, creates sysfs entries, prepares driver > to handle the hardware. > > *start - Sets up device resources and configures the hardware. Loads > firmware, etc. > (physical) > > *open - engages the hardware, and makes it usable by the class device. > (logical and physical) > > *close - disengages the hardware, and stops class level access > (logical and physical) > > *stop - physically disables the hardware > (physical) > > *detach - tears down the driver and releases it from the "struct device" > You have a few things here that can easily conflict, and that will be developed at different paces. I like the direction that it's going, but how do you intend to do it gradually. I.e. what to do first? Pat