[PATCH] usb/fsl_udc: fix dequeuing a request in progress
Li Yang-R58472
r58472 at freescale.com
Wed Nov 23 19:20:54 EST 2011
>-----Original Message-----
>From: Peter Chen [mailto:hzpeterchen at gmail.com]
>Sent: Wednesday, November 23, 2011 11:02 AM
>To: Li Yang-R58472
>Cc: Chen Peter-B29397; balbi at ti.com; gregkh at suse.de; linux-
>usb at vger.kernel.org; linuxppc-dev at lists.ozlabs.org
>Subject: Re: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
>
>On Tue, Nov 22, 2011 at 7:48 PM, Peter Chen <hzpeterchen at gmail.com> wrote:
>>>>It seems to can't get the correct qh pointer, you may still need to
>>>>use below code to get it
>>>> int i = ep_index(ep) * 2 + ep_is_in(ep);
>>>> struct ep_queue_head *dQH = &ep->udc->ep_qh[i];
>>>
>>> Thanks for trying. It will be much easier if we can dereference QH
>from the ep structure. It is really strange that the ep->qh pointer is
>not working somehow.
>>>
>>
>> Seems only ep0-out's qh pointer is assigned at ep structure.
>> At probe:
>> /* setup udc->eps[] for ep0 */
>> struct_ep_setup(udc_controller, 0, "ep0", 0);
>>
>>
>>> We have initialized it in struct_ep_setup():
>>> ep->qh = &udc->ep_qh[index];
>>>
>>> Can you do me a favor on investigating why it's failing?
>>>
>Leo, I have debugged this issue at my board just now, the reason of
>failure is we only have one ep struct for ep0, so when talking about ep0,
>it always pointers to udc->ep[0]. So even we initialize the current qh
>address for ep0in at probe, it still can't get the ep0in's qh address
>through ep structure, as ep0 is always udc->ep[0].
Oops. I forgot the fact that we used a single ep structure to handle both IN and OUT ep0 because the gadget layer only knows about one ep0 structure.
I guess currently we have no other way out unless the gadget layer do honor ep0 with direction. IMHO, it is a limitation to current gadget APIs that each udc driver need to take too much care of the protocol related stuff on ep0.
Thanks,
Leo
More information about the Linuxppc-dev
mailing list