On Fri, Jan 21, 2022 at 06:39:59PM +0530, Pratham Pratap wrote:
> Hi Alan,
>
> Thanks for reviewing.
>
> On 1/19/2022 10:59 PM, Alan Stern wrote:
> > On Wed, Jan 19, 2022 at 09:21:38PM +0530, Pratham Pratap wrote:
> > > When a FS device is following a suspend-reset-enumeration-data
> > > transfer sequence,
> > Such a sequence never happens. The kernel always does a resume before a
> > reset, if the port is suspended.
> >
> > I seem to recall reading something in the USB-2 spec saying that this was
> > required (i.e., a suspended port should never be reset without being
> > resumed first), but now I can't find it.
> What if resume failed and the driver ends up in reset resume path?
Use The Source, Luke. If the resume fails then
usb_reset_and_verify_device() will return -EINVAL immediately, without
performing a reset:
if (udev->state == USB_STATE_NOTATTACHED ||
udev->state == USB_STATE_SUSPENDED) {
dev_dbg(&udev->dev, "device reset not allowed in state %d\n",
udev->state);
return -EINVAL;
}
> Also, there can be a possibility of some class driver preforming
> reset-resume(based on quirks).
Despite its name, reset-resume involves performing a resume first and a
reset second. You can tell from the fact that the reset isn't performed
until finish_port_resume() tests the udev->reset_resume flag, which
occurs after the port has been resumed.
(Furthermore, the reset part of a reset-resume is carried out by calling
usb_reset_and_verify_device(), which as pointed out above, won't do
anything if the device is still suspended.)
Alan Stern
