[U-Boot] [PATCH] usb: gadget: ci_udc: fix suspend/resume of USB Mass Storage

[Marek Vasut]

On 08/24/2016 07:25 AM, John Tobias wrote:
> Hi Marek,

Hi!

> On Tue, Aug 23, 2016 at 8:29 PM, Marek Vasut <marex at denx.de> wrote:
>> On 08/24/2016 03:30 AM, John Tobias wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Tue, Aug 23, 2016 at 5:18 PM, Marek Vasut <marex at denx.de> wrote:
>>>> On 08/24/2016 12:49 AM, Fabio Estevam wrote:
>>>>> Adding Marek on Cc
>>>>
>>>> Thanks
>>>>
>>>>> On Mon, Aug 22, 2016 at 4:38 PM, John Tobias <john.tobias.ph at gmail.com> wrote:
>>>>>> When the host machine went to suspend mode and then wake it up, it send
>>>>>> a USB_REQ_GET_STATUS.
>>>>
>>>> Can you expand on this ? It is not clear what the conditions to
>>>> replicate this are. Please do so in detail.
>>>
>>>
>>> For MacOS Yosemite:
>>>
>>> Connect your board into your host machine and run UMS. Once, the icon
>>> pop-up on your host machine (MacOS), put it in sleep mode (by clicking
>>> sleep in the menu under apple icon on the upper left corner of the
>>> screen). Then, once, you're sure that the host machine is in sleep
>>> mode, just wake it up.
>>>
>>>     1.0 If you load the uboot without the said patch, you should see a
>>> message "Disk Not Ejected Properly", the icon disappeared and the
>>> drive is no longer available.
>>>     1.1 If you load the uboot with the said patch, you should be able
>>> to access the drive after the host woke-up.
>>>
>>> For Windows (I've only tested in Windows 7):
>>> Similar procedures, after the icon pop-up on the screen, put the host
>>> machine in sleep mode (by clicking sleep under "Shut down" menu). The
>>> behavior should similar to 1.0 and 1.1.
>>
>> OK, I see, now it's clearer . This really should be in the commit message.
> 
> I'll resend v2 to include it.

Thanks, but please hold on a bit before we finish this discussion.

>>> Btw, if you are testing it in Windows, connect your device directly
>>> into the USB port of your host machine, not in the HUB.
>>
>> I think I'll have to trust you on all this.
>>
>> Do you know which usb request arrives which throws the code off ?
> 
> USB_REQ_GET_STATUS.
> 
> I tried to following combinations below but, the return
> SETUP(r.bRequestType, r.bRequest) doesn't match at all.
> 
> SETUP(USB_DIR_IN | USB_RECIP_DEVICE, USB_REQ_GET_STATUS)
> SETUP(USB_RECIP_DEVICE, USB_REQ_GET_STATUS)
> SETUP(USB_DIR_IN, USB_REQ_GET_STATUS)

So you get bRequest = USB_REQ_GET_STATUS request with bRequestType set
to what exactly to trigger this bug ?

>> I don't think it's correct to remove the bRequestType checking altogether.
> 
> Looking at the fsl_udc_core.c
> http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/fsl_udc_core.c#L1405
> looks identical.

That doesn't imply it's correct .

[...]

-- 
Best regards,
Marek Vasut