On Thu, Jul 11, 2024 at 10:59:56AM +0200, Oliver Neukum wrote: > > > On 11.07.24 10:43, Hongyu Xie wrote: > > During hibernation, usb_resume_interface will set needs_binding to 1 if > > the usb_driver has no reset_resume implimentation. The USB interface > > will be rebind after usb_resume_complete. > > > > Normally, that's fine. But if a USB interface has a matched kernel > > driver, and a userspace driver or application is using this USB > > interface through usbfs during hibernation, usbfs will be > > detatched with the USB interface after resume. And this USB interface > > will be bind with a kernel driver instead of usbfs. > > > > So add reset_resume to fix this. > > The device has lost all settings, yet we continue like nothing > changed. That strikes me as a very bad idea. If a device has undergone > a reset user space has not requested, we need to return an error upon > the next interaction. > > I am sorry, but this implementation has some fundamental issues. Agreed, but the solution is pretty simple. Because the device was suspended, the userspace driver must have enabled suspend via the USBDEVFS_ALLOW_SUSPEND ioctl. At that point, although the driver _could_ try to do some I/O to the device, the safest approach is for the driver to call the USBDEVFS_WAIT_FOR_RESUME or USBDEVFS_FORBID_SUSPEND ioctl. So those two places are where we can return a specific error code to indicate that the device was reset while resuming. Alan Stern
