On Tue, 8 May 2012, Greg Kroah-Hartman wrote: > On Mon, May 07, 2012 at 10:39:32PM -0400, Alan Stern wrote: > > On Mon, 7 May 2012, Greg Kroah-Hartman wrote: > > > > > > It looks like you're replacing a reset_resume method with a regular > > > > resume method. Is that really the right thing to do? > > > > > > As only 2 usb-serial drivers have ever implemented reset_resume, and > > > they both did the same exact thing that their resume functions did, I > > > think it is safe as resume will be called if reset_resume is not set, > > > right? > > > > Actually no. If the device is going through a reset-resume and a > > driver's reset_resume method pointer isn't set, the driver will be > > unbound and then later rebound. It's not a matter of just calling the > > resume method instead. > > > > Although maybe for serial devices it doesn't make much difference. > > Maybe for the sierra device it might matter. So, should we just have a > reset_resume callback in the usbserial driver structure? If that is > set, then we can set the usb_driver field as well, which should keep > things working properly I think. I don't know how much difference it makes in the end. Even if we add a reset_resume callback to usb-serial, if the lower serial drivers don't know how to reinitialize the hardware then the operation probably won't work. Settings that should be retained (like the current baud rate) won't be. Overall I suspect it's best for now just not to have reset-resume support in usb-serial. Of the two drivers that claimed to implement it, only ch341 actually did something at all reasonable (it called ch341_configure()). The sierra driver did not try to reinitialize anything. 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
