Re: [PATCH 01/16] usb: musb: core: add clear_ep_rxintr() to musb_platform_ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux