Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hi, Heikki Krogerus writes: > On Mon, Oct 12, 2015 at 01:37:40PM -0500, Felipe Balbi wrote: >> >> Hi, >> >> Felipe Balbi 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 wrote: >> >> >> >> > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com >> >> > wrote: >> >> > > From: Ville Syrj舁・ >> >> > > >> >> > > 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 4 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 signature.asc Description: PGP signature
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On Fri, Nov 06, 2015 at 02:48:00PM +0200, Heikki Krogerus wrote: > On Mon, Oct 12, 2015 at 01:37:40PM -0500, Felipe Balbi wrote: > > > > Hi, > > > > Felipe Balbi 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 wrote: > > >> > > >> > On Mon, Aug 31, 2015 at 07:48:28PM +0300, > > >> > ville.syrj...@linux.intel.com wrote: > > >> > > From: Ville Syrj舁・ > > >> > > > > >> > > 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 4 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. It does have the "Cc: sta...@vger.kernel.org". Sorry about the noise :-). Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On Mon, Oct 12, 2015 at 01:37:40PM -0500, Felipe Balbi wrote: > > Hi, > > Felipe Balbi 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 wrote: > >> > >> > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com > >> > wrote: > >> > > From: Ville Syrj舁・ > >> > > > >> > > 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 4 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. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hi, Felipe Balbi 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 wrote: >> >> > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com >> > wrote: >> > > From: Ville Syrj舁・ >> > > >> > > 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 4 makes it fail here) -- balbi signature.asc Description: PGP signature
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On Mon, Sep 07, 2015 at 09:56:06AM +0300, Heikki Krogerus wrote: > Hi, > > On Tue, Sep 01, 2015 at 06:37:54PM +0300, Ville Syrjälä wrote: > > On Tue, Sep 01, 2015 at 10:17:59AM -0500, Felipe Balbi wrote: > > > Hi, > > > > > > On Tue, Sep 01, 2015 at 05:39:28PM +0300, Ville Syrjälä wrote: > > > > On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote: > > > > > Hi, > > > > > > > > > > On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrjälä wrote: > > > > > > On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrjälä wrote: > > > > > > > > On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote: > > > > > > > > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, > > > > > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > > > > > > > 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. By reverting that commit you're just masking the > > > > > > > > > real problem > > > > > > > > > and I'd rather get that one fixed. > > > > > > > > > > > > > > > > > > How do you reproduce your issue ? > > > > > > > > > > > > > > > > Just boot the system, it gets an IP from dnsmasq on my host, > > > > > > > > then I ssh > > > > > > > > into it and do something to produce a bit of console output, > > > > > > > > after which > > > > > > > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. > > > > > > > > > > > > > > which kernel version ? > > > > > > > > > > > > Anything since the patch went in, so 4.1-rc > > > > > > > > > > > > > Running as USB2 or USB3 ? > > > > > > > > > > > > speed:480, so USB2 I presume? > > > > > > > > > > > > > Have you tried > > > > > > > linux-next ? > > > > > > > > > > > > Tried it now (next-20150901). Equally bad as the rest. > > > > > > > > > > > > > I just did 1000 dmesg iterations over ssh with g_ether and > > > > > > > saw no issues. > > > > > > > > > > > > > > Can you enable dwc3 tracepoints and try again ? (use some very > > > > > > > large > > > > > > > trace buffer, something around 2 or 4 MiB should be enough). > > > > > > > > > > > > Attached one trace from linux-next, and another one with the revert > > > > > > on > > > > > > top. > > > > > > > > > > are you sure these come from next ? > > > > > > > > Yep. > > > > > > > > > It makes zero sense :-) Here's an > > > > > odd snippet: > > > > > > > > > > | sshd-1719 [000] d.s342.579785: dwc3_ep_queue: > > > > > ep1in: req 880077afa540 length 822/1514 ==> 0 > > > > > | sshd-1719 [000] d.s342.580075: dwc3_ep_queue: > > > > > ep1in: req 880077afa6c0 length 0/334 ==> -108 > > > > > | systemd-network-1618 [003] d.s342.754796: dwc3_ep_queue: > > > > > ep1in: req 880077afa780 length 0/120 ==> -108 > > > > > > > > > > your requests are queued with -ESHUTDOWN!! > > > > > > > > Looking at the code the tracepoint is before the request is queued, so > > > > maybe there's just stale junk in req->status before it gets overwritten > > > > by __dwc3_gadget_ep_queue()? > > > > > > right, something touched usb_request.status before and the request has > > > been recycled. > > > > > > > > more requests are queued and that's it. No further traffic. It just > > > > > stopped working. No further IRQs, nothing. > > > > > > > > > > mine looks very much different (see attached). I don't have any > > > > > -ESHUTDOWNs. How did you load g_ether ? Did you pass any extra > > > > > options ? > > > > > > > > g_ether is builtin, and I just pass g_ether.dev_addr= via kernel > > > > cmdline. > > > > > > > > > Which IP version are you running ? > > > > > > > > ipv4 > > > > > > I mean the SNPS IP :-) (it's 2.10a, see below) > > > > It's all Greek to me :) > > > > > > > > > GSBUSCFG0 = 0x0006 > > > > GSBUSCFG1 = 0x0f00 > > > > GTXTHRCFG = 0x230a > > > > GRXTHRCFG = 0x2280 > > > > GCTL = 0x45802002 > > > > GEVTEN = 0x > > > > GSTS = 0x3e82 > > > > GSNPSID = 0x5533210a > > > > > > this could be a bug with 2.10a where completion IRQs are missed. Any > > > chance you can look for you Errata document and see if any exist ? I'm > > > using 2.40a. > > > > Ugh. USB
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hi, On Tue, Sep 01, 2015 at 06:37:54PM +0300, Ville Syrjälä wrote: > On Tue, Sep 01, 2015 at 10:17:59AM -0500, Felipe Balbi wrote: > > Hi, > > > > On Tue, Sep 01, 2015 at 05:39:28PM +0300, Ville Syrjälä wrote: > > > On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote: > > > > Hi, > > > > > > > > On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrjälä wrote: > > > > > On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote: > > > > > > Hi, > > > > > > > > > > > > On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrjälä wrote: > > > > > > > On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote: > > > > > > > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, > > > > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > > > > > 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. By reverting that commit you're just masking the > > > > > > > > real problem > > > > > > > > and I'd rather get that one fixed. > > > > > > > > > > > > > > > > How do you reproduce your issue ? > > > > > > > > > > > > > > Just boot the system, it gets an IP from dnsmasq on my host, then > > > > > > > I ssh > > > > > > > into it and do something to produce a bit of console output, > > > > > > > after which > > > > > > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. > > > > > > > > > > > > which kernel version ? > > > > > > > > > > Anything since the patch went in, so 4.1-rc > > > > > > > > > > > Running as USB2 or USB3 ? > > > > > > > > > > speed:480, so USB2 I presume? > > > > > > > > > > > Have you tried > > > > > > linux-next ? > > > > > > > > > > Tried it now (next-20150901). Equally bad as the rest. > > > > > > > > > > > I just did 1000 dmesg iterations over ssh with g_ether and > > > > > > saw no issues. > > > > > > > > > > > > Can you enable dwc3 tracepoints and try again ? (use some very large > > > > > > trace buffer, something around 2 or 4 MiB should be enough). > > > > > > > > > > Attached one trace from linux-next, and another one with the revert on > > > > > top. > > > > > > > > are you sure these come from next ? > > > > > > Yep. > > > > > > > It makes zero sense :-) Here's an > > > > odd snippet: > > > > > > > > | sshd-1719 [000] d.s342.579785: dwc3_ep_queue: ep1in: > > > > req 880077afa540 length 822/1514 ==> 0 > > > > | sshd-1719 [000] d.s342.580075: dwc3_ep_queue: ep1in: > > > > req 880077afa6c0 length 0/334 ==> -108 > > > > | systemd-network-1618 [003] d.s342.754796: dwc3_ep_queue: ep1in: > > > > req 880077afa780 length 0/120 ==> -108 > > > > > > > > your requests are queued with -ESHUTDOWN!! > > > > > > Looking at the code the tracepoint is before the request is queued, so > > > maybe there's just stale junk in req->status before it gets overwritten > > > by __dwc3_gadget_ep_queue()? > > > > right, something touched usb_request.status before and the request has > > been recycled. > > > > > > more requests are queued and that's it. No further traffic. It just > > > > stopped working. No further IRQs, nothing. > > > > > > > > mine looks very much different (see attached). I don't have any > > > > -ESHUTDOWNs. How did you load g_ether ? Did you pass any extra options ? > > > > > > g_ether is builtin, and I just pass g_ether.dev_addr= via kernel > > > cmdline. > > > > > > > Which IP version are you running ? > > > > > > ipv4 > > > > I mean the SNPS IP :-) (it's 2.10a, see below) > > It's all Greek to me :) > > > > > > GSBUSCFG0 = 0x0006 > > > GSBUSCFG1 = 0x0f00 > > > GTXTHRCFG = 0x230a > > > GRXTHRCFG = 0x2280 > > > GCTL = 0x45802002 > > > GEVTEN = 0x > > > GSTS = 0x3e82 > > > GSNPSID = 0x5533210a > > > > this could be a bug with 2.10a where completion IRQs are missed. Any > > chance you can look for you Errata document and see if any exist ? I'm > > using 2.40a. > > Ugh. USB isn't my thing, so I'm definitely not going to start hunting down > any obscure docs. > > Cc:ing Mathias and Heikki since it looks like they've touched this beast > before. You guys have any docs and/or clue as to what's happening here? I don't, but maybe David knows something. I believe he has worked with your board in the past. Thanks, -- heikki -- To unsubscribe
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
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 wrote: > > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrj舁・ > > > > > > 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. -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hi, On Mon, 31 Aug 2015 11:54:13 -0500 Felipe Balbi wrote: > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrj舁\xE7 > > > > 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. -- Masakazu Mokuno -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On Tue, Sep 01, 2015 at 10:17:59AM -0500, Felipe Balbi wrote: > Hi, > > On Tue, Sep 01, 2015 at 05:39:28PM +0300, Ville Syrjälä wrote: > > On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote: > > > Hi, > > > > > > On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrjälä wrote: > > > > On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote: > > > > > Hi, > > > > > > > > > > On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrjälä wrote: > > > > > > On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote: > > > > > > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, > > > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > > > 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. By reverting that commit you're just masking the real > > > > > > > problem > > > > > > > and I'd rather get that one fixed. > > > > > > > > > > > > > > How do you reproduce your issue ? > > > > > > > > > > > > Just boot the system, it gets an IP from dnsmasq on my host, then I > > > > > > ssh > > > > > > into it and do something to produce a bit of console output, after > > > > > > which > > > > > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. > > > > > > > > > > which kernel version ? > > > > > > > > Anything since the patch went in, so 4.1-rc > > > > > > > > > Running as USB2 or USB3 ? > > > > > > > > speed:480, so USB2 I presume? > > > > > > > > > Have you tried > > > > > linux-next ? > > > > > > > > Tried it now (next-20150901). Equally bad as the rest. > > > > > > > > > I just did 1000 dmesg iterations over ssh with g_ether and > > > > > saw no issues. > > > > > > > > > > Can you enable dwc3 tracepoints and try again ? (use some very large > > > > > trace buffer, something around 2 or 4 MiB should be enough). > > > > > > > > Attached one trace from linux-next, and another one with the revert on > > > > top. > > > > > > are you sure these come from next ? > > > > Yep. > > > > > It makes zero sense :-) Here's an > > > odd snippet: > > > > > > | sshd-1719 [000] d.s342.579785: dwc3_ep_queue: ep1in: > > > req 880077afa540 length 822/1514 ==> 0 > > > | sshd-1719 [000] d.s342.580075: dwc3_ep_queue: ep1in: > > > req 880077afa6c0 length 0/334 ==> -108 > > > | systemd-network-1618 [003] d.s342.754796: dwc3_ep_queue: ep1in: > > > req 880077afa780 length 0/120 ==> -108 > > > > > > your requests are queued with -ESHUTDOWN!! > > > > Looking at the code the tracepoint is before the request is queued, so > > maybe there's just stale junk in req->status before it gets overwritten > > by __dwc3_gadget_ep_queue()? > > right, something touched usb_request.status before and the request has > been recycled. > > > > more requests are queued and that's it. No further traffic. It just > > > stopped working. No further IRQs, nothing. > > > > > > mine looks very much different (see attached). I don't have any > > > -ESHUTDOWNs. How did you load g_ether ? Did you pass any extra options ? > > > > g_ether is builtin, and I just pass g_ether.dev_addr= via kernel > > cmdline. > > > > > Which IP version are you running ? > > > > ipv4 > > I mean the SNPS IP :-) (it's 2.10a, see below) It's all Greek to me :) > > > GSBUSCFG0 = 0x0006 > > GSBUSCFG1 = 0x0f00 > > GTXTHRCFG = 0x230a > > GRXTHRCFG = 0x2280 > > GCTL = 0x45802002 > > GEVTEN = 0x > > GSTS = 0x3e82 > > GSNPSID = 0x5533210a > > this could be a bug with 2.10a where completion IRQs are missed. Any > chance you can look for you Errata document and see if any exist ? I'm > using 2.40a. Ugh. USB isn't my thing, so I'm definitely not going to start hunting down any obscure docs. Cc:ing Mathias and Heikki since it looks like they've touched this beast before. You guys have any docs and/or clue as to what's happening here? -- Ville Syrjälä Intel OTC -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hi, On Tue, Sep 01, 2015 at 05:39:28PM +0300, Ville Syrjälä wrote: > On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote: > > Hi, > > > > On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrjälä wrote: > > > On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote: > > > > Hi, > > > > > > > > On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrjälä wrote: > > > > > On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote: > > > > > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, > > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > 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. By reverting that commit you're just masking the real > > > > > > problem > > > > > > and I'd rather get that one fixed. > > > > > > > > > > > > How do you reproduce your issue ? > > > > > > > > > > Just boot the system, it gets an IP from dnsmasq on my host, then I > > > > > ssh > > > > > into it and do something to produce a bit of console output, after > > > > > which > > > > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. > > > > > > > > which kernel version ? > > > > > > Anything since the patch went in, so 4.1-rc > > > > > > > Running as USB2 or USB3 ? > > > > > > speed:480, so USB2 I presume? > > > > > > > Have you tried > > > > linux-next ? > > > > > > Tried it now (next-20150901). Equally bad as the rest. > > > > > > > I just did 1000 dmesg iterations over ssh with g_ether and > > > > saw no issues. > > > > > > > > Can you enable dwc3 tracepoints and try again ? (use some very large > > > > trace buffer, something around 2 or 4 MiB should be enough). > > > > > > Attached one trace from linux-next, and another one with the revert on > > > top. > > > > are you sure these come from next ? > > Yep. > > > It makes zero sense :-) Here's an > > odd snippet: > > > > | sshd-1719 [000] d.s342.579785: dwc3_ep_queue: ep1in: req > > 880077afa540 length 822/1514 ==> 0 > > | sshd-1719 [000] d.s342.580075: dwc3_ep_queue: ep1in: req > > 880077afa6c0 length 0/334 ==> -108 > > | systemd-network-1618 [003] d.s342.754796: dwc3_ep_queue: ep1in: req > > 880077afa780 length 0/120 ==> -108 > > > > your requests are queued with -ESHUTDOWN!! > > Looking at the code the tracepoint is before the request is queued, so > maybe there's just stale junk in req->status before it gets overwritten > by __dwc3_gadget_ep_queue()? right, something touched usb_request.status before and the request has been recycled. > > more requests are queued and that's it. No further traffic. It just > > stopped working. No further IRQs, nothing. > > > > mine looks very much different (see attached). I don't have any > > -ESHUTDOWNs. How did you load g_ether ? Did you pass any extra options ? > > g_ether is builtin, and I just pass g_ether.dev_addr= via kernel cmdline. > > > Which IP version are you running ? > > ipv4 I mean the SNPS IP :-) (it's 2.10a, see below) > GSBUSCFG0 = 0x0006 > GSBUSCFG1 = 0x0f00 > GTXTHRCFG = 0x230a > GRXTHRCFG = 0x2280 > GCTL = 0x45802002 > GEVTEN = 0x > GSTS = 0x3e82 > GSNPSID = 0x5533210a this could be a bug with 2.10a where completion IRQs are missed. Any chance you can look for you Errata document and see if any exist ? I'm using 2.40a. -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote: > Hi, > > On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrjälä wrote: > > On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote: > > > Hi, > > > > > > On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrjälä wrote: > > > > On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote: > > > > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > From: Ville Syrjälä > > > > > > > > > > > > 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. By reverting that commit you're just masking the real > > > > > problem > > > > > and I'd rather get that one fixed. > > > > > > > > > > How do you reproduce your issue ? > > > > > > > > Just boot the system, it gets an IP from dnsmasq on my host, then I ssh > > > > into it and do something to produce a bit of console output, after which > > > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. > > > > > > which kernel version ? > > > > Anything since the patch went in, so 4.1-rc > > > > > Running as USB2 or USB3 ? > > > > speed:480, so USB2 I presume? > > > > > Have you tried > > > linux-next ? > > > > Tried it now (next-20150901). Equally bad as the rest. > > > > > I just did 1000 dmesg iterations over ssh with g_ether and > > > saw no issues. > > > > > > Can you enable dwc3 tracepoints and try again ? (use some very large > > > trace buffer, something around 2 or 4 MiB should be enough). > > > > Attached one trace from linux-next, and another one with the revert on > > top. > > are you sure these come from next ? Yep. > It makes zero sense :-) Here's an > odd snippet: > > | sshd-1719 [000] d.s342.579785: dwc3_ep_queue: ep1in: req > 880077afa540 length 822/1514 ==> 0 > | sshd-1719 [000] d.s342.580075: dwc3_ep_queue: ep1in: req > 880077afa6c0 length 0/334 ==> -108 > | systemd-network-1618 [003] d.s342.754796: dwc3_ep_queue: ep1in: req > 880077afa780 length 0/120 ==> -108 > > your requests are queued with -ESHUTDOWN!! Looking at the code the tracepoint is before the request is queued, so maybe there's just stale junk in req->status before it gets overwritten by __dwc3_gadget_ep_queue()? > > | -0 [000] d.h342.877628: dwc3_readl: addr > c940040c value 0004 > | -0 [000] d.h342.877635: dwc3_readl: addr > c9400408 value 0100 > | -0 [000] d.h342.877638: dwc3_writel: addr > c9400408 value 8100 > | irq/22-dwc3-753 [002] d..242.878300: dwc3_event: event 00c4 > > so you had an IRQ, fine. > > | irq/22-dwc3-753 [002] d..242.878312: dwc3_gadget: ep1out: reason > Transfer Not Active > | irq/22-dwc3-753 [002] d..242.878328: dwc3_gadget_ep_cmd: ep1out: > cmd 'Start Transfer' [6] params 77ad9030 > > a transfer is started. > > | irq/22-dwc3-753 [002] d..242.878332: dwc3_writel: addr > c9400828 value > | irq/22-dwc3-753 [002] d..242.878336: dwc3_writel: addr > c9400824 value 77ad9030 > | irq/22-dwc3-753 [002] d..242.878339: dwc3_writel: addr > c9400820 value > | irq/22-dwc3-753 [002] d..242.878342: dwc3_writel: addr > c940082c value 0406 > | irq/22-dwc3-753 [002] d..242.878345: dwc3_readl: addr > c940082c value 00050006 > | irq/22-dwc3-753 [002] d..242.878348: dwc3_gadget: Command > Complete --> 0 > | irq/22-dwc3-753 [002] d..242.878350: dwc3_readl: addr > c940082c value 00050006 > | irq/22-dwc3-753 [002] d..242.878353: dwc3_writel: addr > c940040c value 0004 > | irq/22-dwc3-753 [002] d..242.878356: dwc3_readl: addr > c9400408 value 8100 > | irq/22-dwc3-753 [002] d..242.878358: dwc3_writel: addr > c9400408 value 0100 > | -0 [000] d.h342.878839: dwc3_readl: addr > c940040c value 0004 > | -0 [000] d.h342.878865: dwc3_readl: addr > c9400408 value 0100 > | -0 [000] d.h342.878873: dwc3_writel: addr > c9400408 value 8100 > | irq/22-dwc3-753 [002] d..242.879081: dwc3_event: event 6044 > > another IRQ > > | irq/22-dwc3-753 [002] d..242.879086: dwc3_complete_trb:
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On 8/31/2015 10:21 PM, Sergei Shtylyov wrote:
From: Ville Syrjälä
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.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/usb/dwc3/gadget.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0..9a5de54 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1859,27 +1859,32 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
unsigned inti;
intret;
-req = next_request(&dep->req_queued);
-if (!req) {
-WARN_ON_ONCE(1);
-return 1;
-}
-i = 0;
do {
-slot = req->start_slot + i;
-if ((slot == DWC3_TRB_NUM - 1) &&
+req = next_request(&dep->req_queued);
+if (!req) {
+WARN_ON_ONCE(1);
+return 1;
+}
+i = 0;
+do {
+slot = req->start_slot + i;
+if ((slot == DWC3_TRB_NUM - 1) &&
usb_endpoint_xfer_isoc(dep->endpoint.desc))
-slot++;
-slot %= DWC3_TRB_NUM;
-trb = &dep->trb_pool[slot];
+slot++;
+slot %= DWC3_TRB_NUM;
+trb = &dep->trb_pool[slot];
+
+ret = __dwc3_cleanup_done_trbs(dwc, dep, req, trb,
+event, status);
+if (ret)
+break;
+}while (++i < req->request.num_mapped_sgs);
Space needed after }. And this *do {} while* loop seems replaceable with
*foor* loop...
Sorry, didn't realize it was a revert. :-/
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hello.
On 08/31/2015 07:48 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
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.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/usb/dwc3/gadget.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0..9a5de54 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1859,27 +1859,32 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
unsigned inti;
int ret;
- req = next_request(&dep->req_queued);
- if (!req) {
- WARN_ON_ONCE(1);
- return 1;
- }
- i = 0;
do {
- slot = req->start_slot + i;
- if ((slot == DWC3_TRB_NUM - 1) &&
+ req = next_request(&dep->req_queued);
+ if (!req) {
+ WARN_ON_ONCE(1);
+ return 1;
+ }
+ i = 0;
+ do {
+ slot = req->start_slot + i;
+ if ((slot == DWC3_TRB_NUM - 1) &&
usb_endpoint_xfer_isoc(dep->endpoint.desc))
- slot++;
- slot %= DWC3_TRB_NUM;
- trb = &dep->trb_pool[slot];
+ slot++;
+ slot %= DWC3_TRB_NUM;
+ trb = &dep->trb_pool[slot];
+
+ ret = __dwc3_cleanup_done_trbs(dwc, dep, req, trb,
+ event, status);
+ if (ret)
+ break;
+ }while (++i < req->request.num_mapped_sgs);
Space needed after }. And this *do {} while* loop seems replaceable with
*foor* loop...
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hi, On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote: > > > > From: Ville Syrjälä > > > > > > > > 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. By reverting that commit you're just masking the real problem > > > and I'd rather get that one fixed. > > > > > > How do you reproduce your issue ? > > > > Just boot the system, it gets an IP from dnsmasq on my host, then I ssh > > into it and do something to produce a bit of console output, after which > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. > > which kernel version ? Running as USB2 or USB3 ? Have you tried > linux-next ? I just did 1000 dmesg iterations over ssh with g_ether and > saw no issues. > > Can you enable dwc3 tracepoints and try again ? (use some very large > trace buffer, something around 2 or 4 MiB should be enough). you need this fix to avoid the WARN you'll see: https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=d5d0c75c3663b019063253a498fcc5ceec8dad7d -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
Hi, On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrjälä wrote: > On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote: > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > 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. By reverting that commit you're just masking the real problem > > and I'd rather get that one fixed. > > > > How do you reproduce your issue ? > > Just boot the system, it gets an IP from dnsmasq on my host, then I ssh > into it and do something to produce a bit of console output, after which > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. which kernel version ? Running as USB2 or USB3 ? Have you tried linux-next ? I just did 1000 dmesg iterations over ssh with g_ether and saw no issues. Can you enable dwc3 tracepoints and try again ? (use some very large trace buffer, something around 2 or 4 MiB should be enough). cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote: > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > 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. By reverting that commit you're just masking the real problem > and I'd rather get that one fixed. > > How do you reproduce your issue ? Just boot the system, it gets an IP from dnsmasq on my host, then I ssh into it and do something to produce a bit of console output, after which g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. Here's what I have in my .config: CONFIG_USB_OTG=y CONFIG_USB_OTG_FSM=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GADGET=y CONFIG_USB_DWC3_PCI=y CONFIG_USB_PHY=y CONFIG_NOP_USB_XCEIV=y CONFIG_USB_GPIO_VBUS=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2 CONFIG_USB_LIBCOMPOSITE=y CONFIG_USB_U_ETHER=y CONFIG_USB_F_ECM=y CONFIG_USB_F_SUBSET=y CONFIG_USB_ETH=y -- Ville Syrjälä Intel OTC -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > 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. By reverting that commit you're just masking the real problem and I'd rather get that one fixed. How do you reproduce your issue ? -- balbi signature.asc Description: Digital signature
[PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"
From: Ville Syrjälä
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.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/usb/dwc3/gadget.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0..9a5de54 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1859,27 +1859,32 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
unsigned inti;
int ret;
- req = next_request(&dep->req_queued);
- if (!req) {
- WARN_ON_ONCE(1);
- return 1;
- }
- i = 0;
do {
- slot = req->start_slot + i;
- if ((slot == DWC3_TRB_NUM - 1) &&
+ req = next_request(&dep->req_queued);
+ if (!req) {
+ WARN_ON_ONCE(1);
+ return 1;
+ }
+ i = 0;
+ do {
+ slot = req->start_slot + i;
+ if ((slot == DWC3_TRB_NUM - 1) &&
usb_endpoint_xfer_isoc(dep->endpoint.desc))
- slot++;
- slot %= DWC3_TRB_NUM;
- trb = &dep->trb_pool[slot];
+ slot++;
+ slot %= DWC3_TRB_NUM;
+ trb = &dep->trb_pool[slot];
+
+ ret = __dwc3_cleanup_done_trbs(dwc, dep, req, trb,
+ event, status);
+ if (ret)
+ break;
+ }while (++i < req->request.num_mapped_sgs);
+
+ dwc3_gadget_giveback(dep, req, status);
- ret = __dwc3_cleanup_done_trbs(dwc, dep, req, trb,
- event, status);
if (ret)
break;
- } while (++i < req->request.num_mapped_sgs);
-
- dwc3_gadget_giveback(dep, req, status);
+ } while (1);
if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
list_empty(&dep->req_queued)) {
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
