On Tue, Jan 03, 2017 at 11:07:42AM -0600, Bin Liu wrote: > 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? > > I don't see other module maintainers doing this in their own patches, so > I am not sure how to do it properly. > > > > > > I believe this issue exists from day one of the musb driver, not caused > > > by any recent change. I saw those kernel logs before in a few cases, but > > > it was really hard to reproduce, only until recently with a use case > > > with FT4232H, which can trigger the issue constantly within a few > > > minutes. > > > > > > Since I only tested the patch back to v4.1, so I only cc'd stable for > > > 4.1+. > > > > Ok, that's great, say that! > > Yes, I should mention the reason of 'cc 4.1+'. That is what I am asking for, not the full history as you mention above, just a way to look at a single patch and know what is going on with it. thanks, greg k-h -- 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
