Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1395134

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

From Bin Liu <b-liu@ti.com>
Newsgroups linux.kernel
Subject Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error
Date 2016-05-05 15:50 +0200
Message-ID <rvrPc-Wp-31@gated-at.bofh.it> (permalink)
References (5 earlier) <rvalj-1lA-1@gated-at.bofh.it> <rvav0-1pG-29@gated-at.bofh.it> <rvrvR-MH-41@gated-at.bofh.it> <rvrFw-S0-15@gated-at.bofh.it> <rvrFw-S0-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, May 05, 2016 at 04:39:06PM +0300, Sergei Shtylyov wrote:
> On 5/5/2016 4:31 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?
> 
>    Of course.
> 
> >'set' means from 0 to 1, 'clear' means 1 -> 0, right?
> 
>    Well, in my understanding "set" means 1 and "clear" means 0.

This is right. I didn't mean raising or falling edge when mentioning
0->1 or 1->0. We don't know when exactly the controller generates the
interrupt when CSR bit changes, and we/driver don't care.

> 
> >I don't see you have any misunderstanding.
> 
> >>>Regards,
> >>>-Bin.
> 
> MBR, Sergei
> 

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-04-28 16:40 +0200
  Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Yegor Yefremov <yegorslists@googlemail.com> - 2016-05-03 12:10 +0200
    Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-03 15:50 +0200
      Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Yegor Yefremov <yegorslists@googlemail.com> - 2016-05-03 16:30 +0200
        Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-03 16:40 +0200
          Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Yegor Yefremov <yegorslists@googlemail.com> - 2016-05-04 17:00 +0200
            Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-04 21:00 +0200
              Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-05-04 21:10 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-04 21:20 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Greg KH <gregkh@linuxfoundation.org> - 2016-05-04 22:20 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-04 22:50 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-05-05 15:30 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-05 15:40 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-05-05 15:40 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-05 15:50 +0200

csiph-web