Re: [linux-pm] [patch] pm: fix runtime powermanagement's /sys interface

[Alan Stern <stern@rowland.harvard.edu>]

On Sat, 7 Jan 2006, Adam Belay wrote:

> In short I'm suggesting the following:
> 
> 1.) Every bus and device has its own unique PM mechanisms and specifications.
> Representing this in a single unified model of any sort is nearly impossible.
> Therefore, it may be best to allow each bus to define its own PM
> infustructure and sysfs files (perhaps in a way similar to Pat's recent
> patch).

Bus and/or driver.  However even though the mechanisms and specifications 
are all different, that doesn't mean the user interfaces have to be 
different.  Using simple character string names (like Pat did and like I 
did several months ago) should be general enough to work everywhere.

Similarly, the sysfs files themselves should be uniform (even if their
contents aren't).  The core should provide the user interface mechanism
and infrastructure, while leaving it up to the bus and the device drivers
to interpret the meanings of the strings.

> 2.) Device drivers on the other hand exist at a more abstract level and,
> as a result, we have greater flexability and more options.  Therefore, I
> think this is an excellent place to define power states and driver core PM
> infustructure.

It's a good place to define and implement power states.  But the driver 
core PM infrastructure obviously should be defined and implemented in the 
core, not in the drivers.

> 3.) System suspend and runtime power management are not even close to
> similar.  Trying to use the same ->suspend and ->resume API is
> ridiculious because it prevents intermediate power states and doesn't
> properly perpare devices and device classes for a runtime environment.
> Therefore, I'm in favor of a seperate interface tailored specifically for
> runtime power management.

Personally I don't care much one way or another.  The APIs can be kept 
separate or overlapped somehow; it doesn't really matter.  Just so long as 
it's done the same way in all drivers and in the core.

> 4.) If we're going to make any meaningful progress, we need to also
> focus on device classes and class orriented power policy.  For example,
> the "net" device class should provide infustructure and helper functions
> for runtime power management of that flavor.  This might include some
> generic "net" PM sysfs files.

Can you think of device classes other than "net" requiring this special
approach?  Network interfaces already get special treatment in some ways
(for example, they don't have entries in /dev).  This could just be
another form of special treatment for them.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/