On 15.07.24 03:13, Hongyu Xie wrote:
From: Hongyu Xie <xiehongyu1@xxxxxxxxxx>
When will "a reset user space has not requested" happen if there is a
reset_resume in usbfs?
The literal answer to your question is: during resumption
of the device or when power was restored to it.
Before reset_resume() is called.
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?
Strictly speaking this is true. But it overlooks that at that
point something has already been done to the device. Either it has
literally been reset by instructing the hub it is connected to
to reset a port or by interrupting the power supply.
The important point in terms of semantics is that the device state
has been lost. And it has been potentially lost within user space
knowing about it.
There is an inevitable race between a suspend/resume cycle and the
next usbfs operation. Therefore After a suspend()/reset_resume()
cycle the next usbfs operation must not be executed and an error
returned to user space.
At present that error is ENODEV.
Regards
Oliver
