lkml.org 
[lkml]   [2016]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv2] musb_host: fix lockup on rxcsr_h_error
    Hi,

    On Thu, May 05, 2016 at 04:21:23PM +0300, Sergei Shtylyov wrote:
    > Hello.
    >
    > On 5/4/2016 10:17 PM, Bin Liu wrote:
    >
    > >>>>>>>>>>yes, it also works with that reset and go to finish:
    > >>>>>>>>>>
    > >>>>>>>>>>diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
    > >>>>>>>>>>index c3d5fc9..8cd98e7 100644
    > >>>>>>>>>>--- a/drivers/usb/musb/musb_host.c
    > >>>>>>>>>>+++ b/drivers/usb/musb/musb_host.c
    > >>>>>>>>>>@@ -1599,6 +1599,10 @@ void musb_host_rx(struct musb *musb, u8 epnum)
    > >>>>>>>>>> status = -EPROTO;
    > >>>>>>>>>> musb_writeb(epio, MUSB_RXINTERVAL, 0);
    > >>>>>>>>>>
    > >>>>>>>>>>+ rx_csr &= ~MUSB_RXCSR_H_ERROR;
    > >>>>>>>>>>+ musb_writew(epio, MUSB_RXCSR, rx_csr);
    > >>>>>>>>>>+
    > >>>>>>>>>>+ goto finish;
    > >>>>>>>>>> } else if (rx_csr & MUSB_RXCSR_DATAERROR) {
    > >>>>>>>>>>
    > >>>>>>>>>> if (USB_ENDPOINT_XFER_ISOC != qh->type) {
    > >>>>>>>>>>
    > >>>>>>>>>
    > >>>>>>>>>Thanks for testing it.
    > >>>>>>>>
    > >>>>>>>>Have tested your patch and now both FT4232 and Huawei don't freeze on removal.
    > >>>>>>>>
    > >>>>>>>>Bin, Max thanks for fixing this issue.
    > >>>>>>>>
    > >>>>>>>>Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
    > >>>>>>>
    > >>>>>>>Thanks for testing.
    > >>>>>>>
    > >>>>>>>Can you please test the patch [1] instead? I'd like to use it as the
    > >>>>>>>fix.
    > >>>>>>>
    > >>>>>>>[1] http://marc.info/?l=linux-usb&m=146222355213935&w=2
    > >>>>>>
    > >>>>>>The patch behaves the same as the previous one.
    > >>>>>>
    > >>>>>>Kernel: 4.6-rc6
    > >>>>>
    > >>>>>Thanks for testing. I will add your Tested-by.
    > >>>>
    > >>>>If you'll resend this patch, it would be good to add it to stable
    > >>>>kernels. I've tested 3.18.32 and it fixes the error too.
    > >>
    > >>>Thanks for testing.
    > >>>
    > >>>My plan is to not rush it into stable, but let it sit in v4.7 for a
    > >>>while first.
    > >>
    > >> Are you serious? Fixing interrupt storm due to not cleared
    > >>interrupt bit will only be done in 4.7?
    > >
    > >Well, I am new to maintianer's role, and thought there is only one week
    > >away to v4.7 merge window, there is no big difference to let this patch
    > >get into v4.7-rc1. If getting the fix into upstream as soon as possible
    > >is important, I will send it for 4.6-rc7.
    > >
    > >BTY, the issue is not because of not clearing interrupt bit, but the hub
    > >has no chance to report the disconnect event, which causes the
    > >controller keeps generating the interrupt for every new rx urb.
    >
    > Sorry, looking at the Mentor manuals, I got the impression that
    > whenever the RXCSR.Error is set, there's interrupt. Probably they

    This is my understanding of the manual too.

    > meant that the interrupt is generated only on transition from 0 to
    > 1....

    What transition? the RXCSR bit? 'set' means from 0 to 1, 'clear' means 1
    -> 0, right? I don't see you have any misunderstanding.

    >
    > >Regards,
    > >-Bin.
    >
    > MBR, Sergei
    >

    \
     
     \ /
      Last update: 2016-05-05 15:41    [W:3.774 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site