[CC: list trimmed slightly] On Wed, 9 May 2012, Oliver Neukum wrote: > Am Dienstag, 8. Mai 2012, 16:39:05 schrieb Alan Stern: > > How can you keep a connection up if the serial device gets reset > > (probably dropping the DTR and RTS signals in the process) and then > > can't even remember the old baud rate? > > > > This question is perhaps more meaningful when there is no connection. > > If some program is holding the device file open, then reset-resume > > would allow it to keep on using that file instead of closing the file > > and opening a new one. > > Furthermore, user space must assume that a new device file > may belong to a different device. IIRC NM would reconnect, but > only if the file stayed usable. > > > Still, without proper support in the lower drivers, it's not clear how > > well this can work. That's why we originally decided to unbind drivers > > that don't support reset-resume. > > But sierra has this support. No, it doesn't. It has a reset-resume routine, but that routine doesn't actually restore the device's settings. It just logs an error message and then tries to do a normal resume. By contract, the ch341 driver really did have valid reset-resume support, which has been lost as a result of the recent flurry of changes. But it was the only example. I guess the right approach is to add a .reset_resume field into struct usb_serial_driver. Then when usb_serial_register_drivers() creates the dynamic usb_driver structure, it can skip setting the reset_resume pointer if any of the serial drivers doesn't support reset-resume. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
