On Thu, 13 Dec 2001, David Brownell wrote:
> > To summarise, we can either have firmware handling in user
> > space or power management, but not both.
>
> What specific devices that have this problem?
Any storage or communication device that is buspowered and needs
a firmware download.
> They'd seem "broken". Are they important enough that
> they deserve to torque the USB subsystem in this way?
> Why are they discarding their firmware, when they've been
> sitting around with power applied? (If they haven't kept
> power, they are not resumable.)
Unfortunately they can't keep power, if the host powers down,
as they are buspowered. And simply call them nonresumable is an
excuse because you don't like the remedy which is a simple clean
device driver.
> I don't recall a good response to my "don't expect such
> devices to resume, make them re-enumerate" suggestion.
> That doesn't torque things at all; we already know that the
> USB subsystem needs to support per-device suspend
> and resume processing.
You simple can't. You end up with a nonfunctional system if you
switch ethernet interfaces or hard drives. To goal of resumption is
simply resumption. You must not change the system configuration.
> > In fact, no user space task should run until devices involved
> > in paging have resumed operation.
>
> Does Linux PM have hooks into the VM subsystem to expose
> such constraints? Some of this doesn't relate to USB at all.
It's a power management issue.
The sane sequence is:
system wakes -> resume() through the tree is called -> tasks are enabled
That you can only do GFP_NOIO allocations in the resume methods is
fundamental. There's nothing you can do.
If you simply don't have a resume method in a vm related driver you kill
all tasks that have or have files on it mmaped.
This solution will not fly.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
