Hi, Bin Liu <b-liu@xxxxxx> writes: >> 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? you could have used MUSB's first commit for Fixes :-) Then it becomes clear that the issue has always existed. Also, you could have mentioned after tear line (---) that the issue has always existed, but you only tested back to v4.1 and it's unlikely to have any users MUSB on older kernels anyway. -- 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
