Re: [PATCH 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

Hi,

On Sat, Dec 27, 2014 at 01:24:03PM +0530, Amit Virdi wrote:
> On Mon, Dec 22, 2014 at 9:36 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Fri, Dec 19, 2014 at 12:40:16PM +0530, Amit Virdi wrote:
> >> When SG is used, there are two loops iterating to prepare TRBs:
> >>  - Outer loop over the request_list
> >>  - Inner loop over the SG list
> >>
> >> The driver must stop preparing TRBs when the max TRBs have been prepared. The
> >> code was missing break to get out of the outer loop.
> >>
> >> Signed-off-by: Amit Virdi <amit.virdi@st.com>
> >
> > which bug is this fixing ? Which kernels are affected ? This need to be
> > backported to which kernel ? Which commit introduced this bug ? How can
> > I validate this to be a valid fix ?
> >
> 
> Problem description:
> DWC3 gadget sets up a pool of 32 TRBs for each EP during
> initialization. This means, the max TRBs that can be submitted for an
> EP is fixed to 32. Since the request queue for an EP is a linked list,
> any number of requests can be queued to it by the gadget layer.
> However, the dwc3 driver must not submit TRBs more than the pool it
> has created for. This limit wasn't respected when SG was used
> resulting in submitting more than the max TRBs, eventually leading to
> non-transfer of the TRBs submitted over the max limit.

this would become a much, much better commit log than the one you
provided. It's a much more verbose description of the issue.

> Commit that introduced this bug:
> This bug is present from the day support for sg list was added to dwc3
> gadget., i.e. since commit eeb720fb21d61dfc3aac780e721150998ef603af
> ("usb: dwc3: gadget: add support for SG lists") - kernel version
> v3.2-rc7, hence v3.2
> 
> Kernels affected:
> It is best to backport this fix to kernel v3.8+ as there were many
> enhancements/bug fixes from v3.2..v3.8
> 
> Generic setup to reproduce/test this fix:
> This bug is reproduced whenever the number of TRBs that need to be
> submitted to the hardware from the software queue (request_list)
> becomes more than 32 on bulk endpoint. eg. if num_mapped_sgs is 2 and
> the request_list has 17 entries (hence, 34 potential TRBs), the
> scenario is reproduced.
> 
> My setup details:
> For reproducing and testing the patches [1/4 and 2/4], I used an
> inhouse developed user space application that run on device side. This
> user space application interacts with the customized uvc webcam gadget
> to submit the video data to the DWC3 driver. The host side was running
> standard webcam application (cheese).

oh, so this is something I can't easily reproduce myself. Then I'll need
full boot logs, register dump and full trace output of dwc3 running and
exhibiting the problem. Also, make sure you use either v3.18 or v3.19rc1
to validate your changes.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]