> Well, what I was _thinking_ of achieving (in a rather inadequate
> faint-hearted way) was to find a way of preventing disaster when there was
> a mounted filesystem on media that got removed or exchanged during the
> suspend. But there really is no way to prevent disaster when that
> happens, is there? It's no different from what would happen if the user
> changed the media while the system was running. The important thing is
> for _some_ layer to recognize that something has changed, so the system
> doesn't go ahead blindly assuming the old media is still present.
Again, not our problem.
> All right, the whole point is moot. But it does raise an interesting
> question. The USB subsystem has no way to preserve the existence of
> devices across power-off. If people want to keep their mounted
> filesystems on a USB disk during suspend-to-disk we'll need to add
> an appropriate facility. How should it work?
As it works for other subsystems. If I do a swsusp on my laptop
it keeps its IP.
> What I've learned from this discussion is that there needs to be
> another PM device state, or really a pseudo-state. Let's call it
> PM_SUSPEND_IDLE. Devices in this state must not perform DMA or issue
> interrupt requests, but there's no requirement as to how much power they
> consume. Drivers _should_ be able to place devices into an idle state
> starting from any PM state, and they _must_ be able to place fully resumed
> devices into an idle state.
If it is not a state, don't pretend it were. We should define a proper
method for that in the generic device methods. If you need full quiet
here, there will be devices that can't do it unless fully awake.
> When resuming an idle device, it's best for drivers not to assume very
> much about the actual state the device is in. If the driver supports
> multiple idle states (varying, say, according to the power level before
> the device was idled), then the device might be in any of them -- and not
> necessarily the last one the driver remembers placing it in. If the
> driver isn't compiled into the kernel, the device might even be in its
> default or virgin state.
Why wouldn't it be known? Either the kernel has a driver from boot on,
then the device is fully awake or the driver is read back in, then it's
a virgin case. The difference is known at compile time.
Or it is on a bus with multiple hosts, that's a special case anyhow.
But best be prepared for everything.
> The fact that PM_SUSPEND_IDLE doesn't refer to a power level makes it
> difficult to fit into the scheme already established. Maybe its numerical
> value should be larger than any of the other states, reflecting the fact
> that a driver should be able to idle its device regardless of the current
> power level. The only legal transition out of PM_SUSPEND_IDLE to back to
> the full-power state.
>
>
> When you put everything all together, does this sound like a workable
> approach to power management?
Please see the discussion on lkml. ANd perhaps you might contact Pavel Machek.
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
