[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGm1_ksaa8P1fs03-DSsjvVQu_=cg4yqw7xumb9Gbm+t19O01w@mail.gmail.com>
Date: Tue, 3 May 2016 12:03:52 +0200
From: Yegor Yefremov <yegorslists@...glemail.com>
To: Bin Liu <b-liu@...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>,
sergei.shtylyov@...entembedded.com
Subject: Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error
On Thu, Apr 28, 2016 at 4:37 PM, Bin Liu <b-liu@...com> wrote:
> Hi,
>
> On Thu, Apr 28, 2016 at 09:51:37AM +0300, Maxim Uvarov wrote:
>
> [snip]
>
>> Hello Bin,
>>
>> 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>
>> That I think a key thing, which is done in other error. If that change
>> is good for you than I'm also happy with it.
>
> We need to understand why the controller keeps generating the same
> interrupt to come out a proper fix.
>
> I will take a look. But I can only use my spare time on this, so be
> patient.
>
>>
>> I also not sure if musb_writeb(epio, MUSB_RXINTERVAL, 0); is needed.
>> In my case it's the same result with it and without it.
>> In other scenarios might be reasonable...
>
> It disables NAK timeout.
>
>>
>>
>> > First of all, I don't like the idea of merging the two branches, it
>> > makes the code ugly.
>>
>> Yes, I don't like that function at all, it's too long and difficult to
>> read if you first look on it first time. It will be good to split it
>> on 3 small functions for each big if.
>
> This particular function is not that hard to understand, but the driver
> in general is messy. But I am not sure if anyone in the community can
> refactory this driver. The community had some effort in the past to
> clean up this driver, but it always broke usecases on different
> platforms.
>
> Regards,
> -Bin.
Powered by blists - more mailing lists