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@xxxxxxxxxxxxxx>
> >>>>>>>>>
> >>>>>>>>>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
>
--
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
