Hi Bin, Bin Liu <b-...@ti.com> 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: sta...@vger.kernel.org # 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 which commit should be blamed for the problem. Is this something that has always been broken or can we find a commit to blame? 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?" -- balbi -- 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
