On Wed, Jul 17, 2024 at 11:13:39AM +0800, Hongyu Xie wrote: > From: Hongyu Xie <xiehongyu1@xxxxxxxxxx> > > > > On 2024/7/17 10:05, Alan Stern wrote: > > I'm ignoring most of what you asked Oliver to focus on just one thing: > > > > On Wed, Jul 17, 2024 at 09:43:38AM +0800, Hongyu Xie wrote: > > > Even before usbfs->reset_resume is called (if there is one), the USB device > > > has already been reset and in a good state. > > > > You are wrong to think that being reset means the device is in a good > > state. > > > > The userspace driver may have very carefully put the device into some > > non-default state with special settings. All those settings will be > > lost when the device gets reset, and they will have to be reloaded > > before the device can function properly. But the userspace driver won't > > even know this has happened unless the kernel tells it somehow. > > > I was looking the whole thing from kernel's perspective. Thank you for > pointing it out for me. > > Oliver is pointing out that the kernel has to tell the userspace driver > > that all the settings have been lost, so the driver will know it needs > > to load them back into the device. Currently we have no way to send > > this information to the driver. That's why usbfs doesn't have a > > reset_resume callback now. > But I still think that there's no need to rebind for a USB device that was > using usbfs. Because rebinding doesn't fix settings lost. And it looks > strange from user-space's perspective. > What do you think? That's right, it should be possible to avoid rebinding. But we can't do this until we have some way to tell the userspace driver that a reset has occurred. Oliver's idea is to do this by returning a special error code for the next ioctl, and I can't think of anything better. Alan Stern
