Re: Runtime device power management in userspace

[Pavel Machek <pavel@suse.cz>]

On Út 27-12-05 10:59:44, Patrick Mochel wrote:
> 
> On Mon, 26 Dec 2005, Pavel Machek wrote:
> 
> > On Po 26-12-05 12:43:43, Patrick Mochel wrote:
> > > > Is there enough locking in driver core to make this safe?
> > >
> > > The issue I stated is actually orthogonal to locking the device; but the
> > > answer to your question is: probably not. We should probably be taking the
> > > per-device semaphore to prevent against competing events that are trying
> > > to add/remove a device or driver.
> >
> > Ok, thanks. That means that some races are still there, but they
> > probably don't matter for non-hotpluggable stuff like PCI, right?
> 
> Well, the semapohre blocks against driver probing and removing, too.

Ahha, so rmmod while banging .../power is not a good idea. Ok.

> > Noone uses .../power API just now (except Holger :-), so I think we
> > can still change it. Currently it is horribly broken -- taking 0/2 and
> > passing it directly to pm_message_t.event. I don't think we can solve
> > worlds hunger today... but what about at least changing interface so
> > that it lists two states ("on" and "suspend") that are more or less
> > common to all drivers?
> 
> I don't think we want to do something from the core that is common to all
> drivers in that area. The PM values and semantics are so different across
> that I don't think we could effectively abstract something for
> everything.

Well... at least "fully-on" and
"power-down-hardware-as-much-as-possible" are common to all the
drivers. And Ben on ppc does not freeze userspace while doing suspend,
so we are not really exposing anything new.

> What we could do is remove the file from being added in the core, and have
> the PCI core add it for all PCI devices that have PM capabilities and show
> all the states that appear in the config space. From there, we could
> start

I don't really think we want complexity of putting PCI device into
D0/D1/D2/D3hot/D3cold. All that userspace should care about is device
working/device suspended, and we could not test all 5 states, anyway.

								Pavel
-- 
Thanks, Sharp!