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@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? 'set' means from 0 to 1, 'clear' means 1
-> 0, right? 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
