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

[Alan Stern]

On Thu, 5 Jan 2006, Patrick Mochel wrote:

> On Fri, 6 Jan 2006, Pavel Machek wrote:
> 
> > On 05-01-06 16:04:07, Patrick Mochel wrote:
> 
> > > A better point, and one that would actually be useful, would be to remove
> > > the file altogether. Let Dominik export a power file, with complete
> > > control over the values, for each pcmcia device. Then you never have to
> > > worry about breaking PCMCIA again.
> >
> > Fine with me.
> 
> ACK, you beat me to it.
> 
> And, appended is a patch to export PM controls for PCI devices. The file
> "pm_possible_states" exports the states a device supports, and "pm_state"
> exports the current state (and provides the interface for entering a
> state).
> 
> Eventually, some drivers will want to fix up those values so that it can
> mask of states that it doesn't support, as well as offer possible device-
> specific states.
> 
> What's interesting is that with this patch, I can see that two more
> devices on my system support D1 and D2 -- the cardbus controllers, which
> are actually bridges whose PM capabilities aren't exported via lspci.

This trend is extremely alarming!!

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).

Alan Stern


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