On Mon, Feb 14, 2022 at 12:29:49PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 08:08:52PM +0900, Daehwan Jung wrote:
> > It always sets DWC3_EP_END_TRANSFER_PENDING in dwc3_stop_active_transfer
> > even if dwc3_send_gadget_ep_cmd fails. It can cause some problems like
> > skipping clear stall commmand or giveback from dequeue. We fix to set it
> > only when ep cmd success. Additionally, We clear DWC3_EP_TRANSFER_STARTED
> > for next trb to start transfer not update transfer.
> 
> So is this two different changes?
> 
> > 
> > Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
> 
> What commit id does this fix?
> 
> thanks,
> 
> greg k-h
> 

Hi greg,

Below is commit id to fix.

commit c58d8bfc77a2c7f6ff6339b58c9fca7ae6f57e70
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Dec 18 18:14:44 2019 -0800

    usb: dwc3: gadget: Check END_TRANSFER completion

    While the END_TRANSFER command is sent but not completed, any request
    dequeue during this time will cause the driver to issue the END_TRANSFER
    command. The driver needs to submit the command only once to stop the
    controller from processing further. The controller may take more time to
    process the same command multiple times unnecessarily. Let's add a flag
    DWC3_EP_END_TRANSFER_PENDING to check for this condition.

    Fixes: 3aec99154db3 ("usb: dwc3: gadget: remove DWC3_EP_END_TRANSFER_PENDING")
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Wesley may have run into same issue and I think it's better for us to discuss.

https://protect2.fireeye.com/v1/url?k=9d423b69-fc3fd32e-9d43b026-74fe485fff30-77a099b52659410d&q=1&e=20b4d9f5-2599-4f57-8b6a-7c4ec167d228&u=https%3A%2F%2Flore.kernel.org%2Flinux-usb%2F20220203080017.27339-1-quic_wcheng%40quicinc.com%2F

Best Regards,
Jung Daehwan