Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

[Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 11/25/2013 09:41 PM, Alan Stern wrote:
> On Mon, 25 Nov 2013, Daniel Mack wrote:
> 
>>>>> What if you have a mounted file system on a pendrive ? Should we allow
>>>>> suspend in that case ?
>>>>
>>>> Well, I would have expected that, but in fact, the opposite is true.
>>>> With 3.12, mounting a filesystem on a USB media and accessing it after
>>>> resume was exactly my test case, and it worked just fine with that patch.
>>>
>>> so you had a mounted file system, suspend, resume, it was still mounted?
>>
>> Yes, exactly.
>>
>>> or did it reenumerate and you remounted it ?
>>
>> No, it did not reenumerate, but the core did a reset on it. See the
>> following log.
> 
> ...
>> [   32.030792] usb 1-1: reset high-speed USB device number 2 using
>> musb-hdrc <<<< !
> 
> Like I said, you get a reset-resume.

Yup. We can't avoid losing VBUS on this platform, and even if we could,
we wouldn't want that, in order to save as much power as possible.

>>> Try to do the same with transfers in flight, it's likely to corrupt your
>>> file system.
> 
> It's not so easy to suspend a system with USB mass-storage transfers in 
> flight.  For one thing, userspace gets frozen before the suspend 
> starts, so there's nothing to initiate new I/O requests (except perhaps 
> for dirty-block writebacks).
> 
> Also, the child SCSI device gets suspended before the USB device, so
> its I/O queue stops running.  In addition, the usb-storage suspend
> routine and the main I/O thread are mutually exclusive (they both grab
> the private mutex), so a suspend can't occur while a SCSI command is
> underway.

Thanks Alan for the explanation. That was my understanding as well.


Best regards,
Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html