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

[Pavel Machek <pavel@ucw.cz>]

On Pá 06-01-06 10:42:24, Alan Stern wrote:
> 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 scares me a bit, too. 

> 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.
								Pavel
-- 
Thanks, Sharp!
-
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/