Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"

[Felipe Balbi <balbi@ti.com>]

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


Hi,

Heikki Krogerus <heikki.krogerus@linux.intel.com> writes:
> On Mon, Oct 12, 2015 at 01:37:40PM -0500, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Felipe Balbi <balbi@ti.com> writes:
>> > On Wed, Sep 02, 2015 at 05:09:39PM +0900, Masakazu Mokuno wrote:
>> >> Hi,
>> >> 
>> >> On Mon, 31 Aug 2015 11:54:13 -0500
>> >> Felipe Balbi <balbi@ti.com> wrote:
>> >> 
>> >> > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrjala@linux.intel.com wrote:
>> >> > > From: Ville Syrj舁・<ville.syrjala@linux.intel.com>
>> >> > > 
>> >> > > This reverts commit 8f2c9544aba636134303105ecb164190a39dece4.
>> >> > > 
>> >> > > As it breaks g_ether on my Baytrail FFRD8 device. Everything starts out
>> >> > > fine, but after a bit of data has been transferred it just stops
>> >> > > flowing.
>> >> > > 
>> >> > > Note that I do get a bunch of these "NOHZ: local_softirq_pending 08"
>> >> > > when booting the machine, but I'm not really sure if they're related
>> >> > > to this problem.
>> >> > 
>> >> > I have a feeling your problem is elsewhere. We *are* completing one TRB
>> >> > at a time. 
>> >> 
>> >> If usb_request.no_interrupt is flagged, it seems dwc3 does not set IOC
>> >> on the corresponding TRB.  Does it break the assumption every TRB
>> >> (without SG) will trigger one corresponding EP event?
>> >> u_ether is the function module that utilizes 'no_interrupt' flag.
>> >
>> > XferInProgress should still trigger. Besides, I tested with the exact
>> > same setup (different SoC though), just look at the thread.
>> 
>> I found a way to reproduce this on my end. What I was missing was the
>> use of request.no_interrupt. We won't get XferInProgress for all TRBs if
>> IOC isn't set in all of them.
>> 
>> I'll apply this patch ASAP as it fixes the problem I managed to
>> reproduce (ping -s 40000 makes it fail here)
>
> I can see the commit in your next branch, but shouldn't it go in as a
> fix? I guess it should also be tagged with the stable tag.
>
> I got an other guy who hit this issue who I think is using the stable
> tree.

it was kinda late to merge it during the -rc.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]