Am Dienstag, 17. Januar 2006 21:54 schrieb Pete Zaitcev:
> On Tue, 17 Jan 2006 15:34:33 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > There's a certain danger of getting a reset followed by a secondary reset
> > as an error treatment, followed by ... Could you do a real disconnect in
> > theses cases?
>
> The semantics of a disconnect are different, because the physical devices
> are not carried over a disconnect. So, suppose you have a serial adapter
A disconnect severs the connection of driver and interface. Nothing more,
nothing less. Physical disconnection is just the commonest cause. However,
it is perfectly valid to trigger a disconnect in software. Usbfs has been
allowing this a long time.
> as an interface, like on IBM RSA-II, and you have a shell on it. If the
> usb-storage resets the other interface, then a disconnect on the serial
> side will cause the shell to get SIGHUP, which is a pain if you were in
> vi at that time... But a reset is a reset, the shell would not even notice
> anything unless the screen was being repainted right that moment.
I suppose a change of baud rate and other settings wouldn't be noticed?
If this is really the case, very simple stubs that do nothing can be used.
> The two-signal reset bothers me too, because it has to interact well
> with actual disconnect, and generally I do not like this sort of thing.
> And I hoped that at least the first of these callbacks could be indicated
> simply by a return code of an URB. But I suppose Alan knows what he's doing.
It would be an inferior way to do this because a drivers might want to
wait until the current operation is completed or quiesce the device, eg.
in a serial driver by asserting flow control lines.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
