On Wed, May 09, 2012 at 08:35:48AM -0700, Greg Kroah-Hartman wrote: > On Wed, May 09, 2012 at 10:50:47AM -0400, Alan Stern wrote: > > [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. > > Yes, I'll work on that later today, and add in the resume/suspend > support of the opticon.c driver, which we missed in the last round of > conversions. Ok, fixed up the opticon.c driver now. But, for the reset_resume callback, I only want to set that in the usb_driver structure if the usb_serial driver supports it, otherwise the usb core will do different things if it is not set, right? I can't just always set it, like we have for the suspend/resume callback from what I can tell. Or is that incorrect? thanks, greg k-h -- 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
