On So 07-01-06 02:58:51, Adam Belay wrote:

On Sat, Jan 07, 2006 at 01:08:26AM +0100, Pavel Machek wrote:

quoted

On Pá 06-01-06 10:42:24, Alan Stern wrote:

quoted

On Thu, 5 Jan 2006, Patrick Mochel wrote:
It's a very bad idea to make bus drivers export and manage the syfs power 
interface.  It means that lots of code gets repeated and different buses 
do things differently.

Already we have PCI exporting "pm_possible_states" and "pm_state" while 
PCMCIA exports "suspend".  How many other different schemes are going to 
crop up?  How much bus-specific information will have to be built into a 
user utility?

If possible states are represented as arrays of pointers to strings, then 
the PM core can easily supply the sysfs interface.  If Patrick's patch 
were re-written so that the sysfs interface were moved into the PM core, 
leaving only the PCI-specific portions in the PCI drivers, I would be much 
happier.  This would also mean that Dominik's patch could be replaced by 
something a good deal smaller.

And it wouldn't hurt to add some mechanism for indicating which of the 
possible states is the generic "suspend" state (usually D3 for PCI 
devices, but not necessarily).

I think we should start with string-based interface, with just two
states ("on" and "off"). That is easily extensible into future, and
suits current PCMCIA nicely. It also allows us to experiment with PCI
power management... I can cook up a patch, but it will be simple
reintroduction of .../power file under different name.

The driver core can provide some infustructure, but let's leave the states
up to the drivers.  Afterall, some drivers might only be interested in "on"
during runtime.  Also, drivers might support some sort of partial-off
but not "off".

Then they map "off" to "as much off as I can". Big deal.

And no, this does not allow us to experiment with PCI power
management.

Well, suse was already doing experiments with 2.6.14 sysfs...

Also there's nothing "runtime" about the PCMCIA PM API.  It's much more
like calling ->remove() as it disabled the device all together.  

It looks enough runtime to me.

I'm more
interested in saving power without crippling functionality.

You are on wrong mailing list, then. Seriously. If you can save power
without affecting functionality, then just doing, you don't need any
userland interface.
							Pavel

-- 
Thanks, Sharp!