Am Montag, 28. Juni 2004 17:50 schrieb Alan Stern:
> On Mon, 28 Jun 2004, Oliver Neukum wrote:
>
> > > > Then we must refuse any sleep states that want to power down the bus.
> > >
> > > No, if the bus powers off the call sequence seen by that driver
> > > will be suspend()->disconnect() rather than suspend()->resume().
> >
> > This will do horrible things if the attached device has considerable state.
> > With usb-storage it will lead to data loss.
>
> What sort of data loss are you referring to?
>
> Data in filesystem buffers not yet flushed to the device?
> Such data are lost whenever a device is disconnected before
> unmounting, no matter whether it is suspended first.
Entirely right. But suspension alone by any method must not lead to it.
> Data in the device buffers not yet written to the medium?
> If it is written properly, the high-level SCSI driver
> will tell the device to flush its caches when the suspend
> notification arrives.
Right.
> Maybe the problem here is one of semantics. It seems to me that the only
> way to make power-off suspend work is if it is a whole-system suspend.
Why? A system in a throtteled power state _should_ switch off all
peripheral busses not in use right now. Power management is not necessarily
without gray areas.
> In such situations filesystem data could be fully flushed and other sorts
> of preventative action taken. But suspending a single device by removing
> its power isn't a suspend at all -- it's a disconnect.
Why? And why only a single device? Switching off the bus has the same
consequences. I don't understand your reasoning here.
But the problem exists in a full system suspend, too. Suppose I have
an editor with a text file open and go to a full suspend. The file must
remain open after the resumption. I don't see how you can do that if
you call disconnect().
Regards
Oliver
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
