Re: [PATCH next] usb: usbfs: Add reset_resume for usbfs

[Hongyu Xie]

From: Hongyu Xie <xiehongyu1@xxxxxxxxxx>

On 2024/7/13 10:22, Alan Stern wrote:
> On Fri, Jul 12, 2024 at 11:10:57AM +0800, Hongyu Xie wrote:
> > From: Hongyu Xie <xiehongyu1@xxxxxxxxxx>
> >
> >
> >
> > On 2024/7/11 16:59, 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.
> > Sorry I don't understand your concern.
> > When will "a reset user space has not requested" happen if there is a
> > reset_resume in usbfs?
>
> That's what a reset-resume is: a reset that occurs when the device is
> resumed, rather than when the driver has requested a reset.
Right now this reset_resume did nothing, it's just an empty function to 
prevent rebind after resume.
Maybe I should filter out usbfs in usb_resume_interface when setting 
needs_binding to 1?
> Alan Stern
>
> > > I am sorry, but this implementation has some fundamental issues.
> > >
> > >       Regards
> > >           Oliver
> > Regards
> > Hongyu Xie