Re: [PATCH] implement pm_ops.valid for everybody

[Dmitry Krivoschekov <dmitry.krivoschekov@gmail.com>]

David Brownell wrote:
> On Friday 23 March 2007 1:39 pm, Rafael J. Wysocki wrote:
>
>> 	After we have frozen tasks, we need to
>> call something like device_suspend(some_argument) where the argument should
>> tell drivers what to do. 
>
> That parameter can't suffice, since the exact details depend on
> system-dependent context.  Example, on one system a given sleep
> state will allow a given device to issue wakeups ... on another,
> it won't.
>
What do you mean? Capability of h/w to be a wakeup source or
design decisions, when wakeup capability of a given device
is disabled intentionally for some reason?

System may have a number of devices that all are able to wakeup
the system from *all* sleep (low power) states the system
supports.Normally, such devices should be marked as "can_wakeup"
to demonstrate the capability, then, user may select these
devices as a wakeup source(s) from a given sleep state.
He(she) sets "should_wakeup" flag for this. For example,
I may want to wakeup the system via USB, MMC and keypad,
but when I put  the system into deeper sleep state I may want
to wakeup it only via keypad and do not bother it via MMC
and USB.


So, it is reasonable idea to permit some devices to be
wakeup sources for one system-wide state but restrict
the wakeup ability for another system-wide state.
But, it seems not quite reasonable to hardcode this
in platform-specific code, unless your platform is
designed for very specific needs. In general,
every wakeup source (which is capable to wakeup
at any system state) should be available via sysfs
(../power/wakeup interface of device)

> You seem to have overlooked the clk_must_disable() patches I
> recently re-sent.  In conjunction with the driver model wakeup
> flags, that can solve the problem on every SOC platform I've
> had a reason to look at ... see how it works for AT91 USB.

As I pointed above, user may want to choose between wakeup
sources and he(she) must be sure the choice won't be ignored,
but your changes for atmel_serial.c and at91_udc.c,
seems restrict user with that.



Thanks,
Dmitry