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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
