> > We should seek to limit the limitations.
> > The only absolute limitation I see is not large
> > - you cannot do remote wake up
> > - you cannot detect pluggings during such suspension
> > - you cannot resume devices which have state unknown to the driver (sg etc.)
>
> I think this could be done, at the cost of requiring many drivers to add a
> significant amount of "reinitialization" code. It would be a big job.
>
> It would even be possible to detect connect changes during a power-off
> suspend, by comparing the "before" and "after" states of the hubs. Once
> the power has been restored for (say) 5 seconds, khubd could check whether
> any previously-connected ports are no longer connected and call
> usb_disconnect() for them. Also, during those 5 seconds khubd could
> monitor new connections to make sure they match the usb_devices that used
> to be on those ports -- sort of like usb_reset_device() does, comparing
> descriptors. It wouldn't be perfect, but it ought to work pretty well.
Simpler even. It's gone when resume() fails.
But think it through. If powering down always means that disconnect
has to be processed, then how is suspend ever going to work?
In logical consequence you would have to unmount the root fs.
In considering the current state of affairs to be correct you are
implicitly saying that there are two classes of busses. Those that
implement full suspend() semantics and those that do not.
It seems to me that you cannot treat power loss as disconnect
unconditionally. It's not just inconvinient but it is a failure to
correctly implement suspend/resume.
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
