Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Bin Liu <b-liu@ti.com>,
	Yegor Yefremov <yegorslists@googlemail.com>,
	Maxim Uvarov <muvarov@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-usb <linux-usb@vger.kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>
Subject: Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error
Date: Thu, 5 May 2016 16:21:23 +0300	[thread overview]
Message-ID: <c7ea3886-f63b-8513-4c6a-7bca9a27d912@cogentembedded.com> (raw)
In-Reply-To: <20160504191715.GA6727@uda0271908>

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 meant that the 
interrupt is generated only on transition from 0 to 1....

> Regards,
> -Bin.

MBR, Sergei