lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 5 May 2016 16:21:23 +0300 From: Sergei Shtylyov <sergei.shtylyov@...entembedded.com> To: Bin Liu <b-liu@...com>, Yegor Yefremov <yegorslists@...glemail.com>, Maxim Uvarov <muvarov@...il.com>, kernel list <linux-kernel@...r.kernel.org>, linux-usb <linux-usb@...r.kernel.org>, Greg KH <gregkh@...uxfoundation.org> Subject: Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error 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@...glemail.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 meant that the interrupt is generated only on transition from 0 to 1.... > Regards, > -Bin. MBR, Sergei
Powered by blists - more mailing lists