For example, to enable remote wakeup (whenever we start to
support that). I understand that a lot of USB hardware does
not work reliably if that's enabled much before a USB suspend.
If only SUSPEND_POWER_DOWN notification was delivered, that'd
have to be enabled at that point.
>>Why would you allocate memory on a resume transition?
One example comes to mind. There are systems that, rather
than supporting a "suspend to reduced power", are actually
set up so they "suspend to no power". Or in short, they
power off in cases when other systems don't ... saving even
more power. (I think that is the difference between D3hot
and D3cold, or somesuch, but there are so many different
names for the various states and contexts that I've been
known to get them wrong.)
In that case, a "resume" needs to be able to completely
re-initialize the hardware. As a rule, that's going to
want to be able to allocate memory.
... though FWIW I missed seeing anything that showed how
those API summaries would place constraints on allocating
memory, so I didn't assume there could be any.
What did seem to be missing was anything saying whether
those device methods would be called in_interrupt() or
whether instead they could sleep. I'd hope all of them
would be specified to allow blocking as needed, like their
current analogues in PCI and USB.
Also, there was some mention not that long ago about
desirability of some kind of device abort() call. That
would differ from the current remove() call because an
abort() would pass the explicit knowledge that hardware
was gone ... unplugged before driver shutdown, for one
example. That could also be achieved using some kind
of mode parameter to remove() -- perhaps three values,
saying whether the hardware was present, removed, or
in some indeterminate state.
- Dave
-
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/