On Tue, Jan 03, 2017 at 07:37:18PM +0200, Felipe Balbi wrote: > > Hi Bin, > > Bin Liu <b-liu@xxxxxx> writes: > > On Tue, Jan 03, 2017 at 05:28:22PM +0100, Greg KH wrote: > >> On Tue, Jan 03, 2017 at 09:47:47AM -0600, Bin Liu wrote: > >> > On Tue, Jan 03, 2017 at 04:34:48PM +0100, Greg KH wrote: > >> > > On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu wrote: > >> > > > During dma teardown for dequque urb, musb might generate bogus rx ep > >> > > > interrupt even when the rx fifo is flushed. As mentioned in the current > >> > > > inline comment, clearing ep interrupt in the teardown path avoids the > >> > > > bogus interrupt. > >> > > > > >> > > > Before this change, any of the follow log messages could happen when > >> > > > musb load is high. > >> > > > >> > > What "change" caused this? > >> > > > >> > > > > >> > > > musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0 > >> > > > > >> > > > musb_host_rx 1936: RX3 dma busy, csr 2020 > >> > > > > >> > > > cc: stable@xxxxxxxxxxxxxxx # 4.1+ > >> > > > >> > > Do you have a git commit id that caused this issue? > >> > > >> > This patch was posted in [1]. > >> > >> Then say that! > > > > Greg, please bear with me, but I am really confused here, due to my > > dual-role in the community. > > > > I, as a kernel hacker, first posted the patches such as in [1] for review; > > then later, as a module maintainer, sent a patch set including the > > posted patches to you for merge. Do you expect me to include the posting > > history in the corresponding patches in the later patch bomb? If so, > > should I add the log into the commit message or below '---' so the > > message only for your review but does not get into commit message? > > Greg is not asking you when you have sent the fix, rather he is asking Yeah, it is clear to me now ;) Thanks. > rather he is asking > which commit should be blamed for the problem. Is this something that > has always been broken or can we find a commit to blame? No, the code which is modified in this patch exists since the initial musb support added. Once the issue is understood, I believe it exists since day one. The issue is only reported on DSPS glue, I guess it is due to the hookup between CPPI and MUSB, which causes MUSB EP does not teardown properly when CPPI channel is disabled in the teardown path, then the bogus EP interrupt is triggered. > > IOW, since you're Ccing stable, you consider this to be a > regression. Then the question reads as: "Are you missing a 'Fixes: foo > bar baz' in your commit log?" I think it is difficult to find out the commit to blame, so I used 'cc stable' tag, not 'Fixes:...'. Any recommendation for better logging it? Regards, -Bin. > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
