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?
> > Ouch and BTW *right* value is _2_, today... because state_store() uses
> > value from user as a pm_message_t.event. We should at least supply
> > some hint that it is runtime suspend in pm_message_t.flags --
> > unfortunately we do not have pm_message_t.flags yet.
>
> And I don't think that we want it. I think that we want a completely
> different API for doing runtime PM. Using the same API will make the
> drivers more complicated by having to have a repeated control sequence for
> determing what state (and under what conditions) the device is entering.
>
> Also, recall that the actual states the device and driver support could be
> different than any other device or driver (even when the device or driver
> are the same). What we need is a way for a driver to easily export the
> states that it supports and a way to enter those exported states (e.g. an
> array or linked list of state names and callbacks, like has been mentioned
> a few times before).
>
> To that effect, the per-device power file and its semantics should go away
> completely and replaced with something that supports this new API.
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?
Pavel
--
Thanks, Sharp!
