From: Alan Stern <stern@rowland.harvard.edu>
To: Chunfeng Yun <chunfeng.yun@mediatek.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Eddie Hung <eddie.hung@mediatek.com>,
Min Guo <min.guo@mediatek.com>,
Tianping Fang <tianping.fang@mediatek.com>,
Stable@vger.kernel.org
Subject: Re: [PATCH 1/2] usb: mtu3: fix ep0's stall of out data stage
Date: Wed, 28 Sep 2022 11:30:05 -0400 [thread overview]
Message-ID: <YzRofTAx+3pPCbrL@rowland.harvard.edu> (raw)
In-Reply-To: <20220928091721.26112-1-chunfeng.yun@mediatek.com>
On Wed, Sep 28, 2022 at 05:17:20PM +0800, Chunfeng Yun wrote:
> It happens when enable uvc function, the flow as below:
> the controller switch to data stage, then call
> -> foward_to_driver() -> composite_setup() -> uvc_function_setup(),
> it send out an event to user layer to notify it call
> -> ioctl() -> uvc_send_response() -> usb_ep_queue(),
> but before the user call ioctl to queue ep0's buffer, the host already send
> out data, but the controller find that no buffer is queued to receive data,
> it send out STALL handshake.
>
> To fix the issue, don't send out ACK of setup stage to switch to out data
> stage until the buffer is available.
You might find it is better to use the delayed_status routines already
present in the Gadget core. Instead of delaying the response to the
Setup packet of the second control transfer, delay the status response
to the first control transfer.
This approach has the advantage of working even when the second transfer
is not control but something else, such as bulk.
Also it agrees better with the way the USB spec intends control
transfers to work. The UDC is not supposed to complete the status stage
of a control transfer until the gadget has fully processed the
transfer's information and is ready to go forward.
Alan Stern
next prev parent reply other threads:[~2022-09-28 15:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 9:17 Chunfeng Yun
2022-09-28 9:17 ` [PATCH 2/2] usb: mtu3: fix failed runtime suspend in host only mode Chunfeng Yun
2022-09-28 13:43 ` AngeloGioacchino Del Regno
2022-09-28 13:43 ` [PATCH 1/2] usb: mtu3: fix ep0's stall of out data stage AngeloGioacchino Del Regno
2022-09-29 6:38 ` Chunfeng Yun
2022-09-28 15:30 ` Alan Stern [this message]
2022-09-29 6:30 ` Chunfeng Yun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzRofTAx+3pPCbrL@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=Stable@vger.kernel.org \
--cc=chunfeng.yun@mediatek.com \
--cc=eddie.hung@mediatek.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=min.guo@mediatek.com \
--cc=tianping.fang@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®