Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

2018-01-26 Thread Tomas Paukrt

Hi Maxim,

unfortunately we cannot test the latest kernel right now, because we 
have custom drivers and additional changes that need to be ported, but 
the MUSB driver in our kernel should contain all fixes from 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/usb/musb


Best regards

Tomas


Dne 25.1.2018 v 17:24 Maxim Uvarov napsal(a):

[1] says that issue is with back ported driver to 3.12.10. Can the
latest kernel be tested on the same hw?

Maxim.

2018-01-25 18:45 GMT+03:00 Bin Liu :

Hi Yegor and Max,

On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote:

On Tue, May 3, 2016 at 3:48 PM, Bin Liu  wrote:

Hi,

On Tue, May 03, 2016 at 12:03:52PM +0200, Yegor Yefremov wrote:

On Thu, Apr 28, 2016 at 4:37 PM, Bin Liu  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 

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.

Sorry for bringing up this old thread, but it seems to be too aggressive
to stop scheduling further urbs on errors [1]. So is it possible for you
to re-test your usecase by reverting commit

 dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one 
failed")

to see if only commit

 b5801212229f ("usb: musb: host: clear rxcsr error bit if set")

itself solves your issue?

I know you have tested the patch in [2], which is similar to commit
b5801212229f, but tha latter doesn't have 'goto finish' which does dma
cleanup on errors, it makes more sense to me. But I'd like to have you
tested with reverting dbac5d07d13e to be sure.

[1] https://marc.info/?l=linux-usb&m=151689238420622&w=2
[2] https://marc.info/?l=linux-kernel&m=146185425805967&w=2

thanks,
-Bin.






--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: MUSB patch (don't start next rx urb if current one failed)

2018-01-25 Thread Tomas Paukrt

Hi Bin,

thanks. I have reverted commit 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/musb/musb_host.c?id=dbac5d07d13e330e6706813c9fde477140fb5d80 
and communication with both RT2800 and SMSC9500 was much more stable, 
but we still had less frequent issues with SMSC9500, so I looked at 
usbnet and smsc95xx drivers and found out that execution of 
*usb_clear_halt* is not enough if stalling endpoint is detected (bit 
MUSB_TXCSR_H_RXSTALL is set) and the chip must be reset, but none of 
these two drivers do it. The reset is mentioned in Microship's 
documentation and also used in their driver, so maybe someone can adapt 
smsc95xx driver to reset the chip properly. I also found out that 
execution of *unlink_urbs* from *usbnet_deferred_kevent * often leads to 
various errors ("queue 0 timed out", "Could not flush host TX2 fifo") or 
even system freeze, so it seems that MUSB driver still has some issue 
with fifo flushing.


Best regards

Tomas


Dne 25.1.2018 v 15:59 Bin Liu napsal(a):

+ cc:linux-usb

Hi Tomas,

It is always a good idea to cc linux-usb list when sending emails to an
individual. (otherwise, for example in my setup the emails go to the
Junk folder if a mailing list is not in to/cc.)

On Thu, Jan 18, 2018 at 03:47:12PM +0100, Tomas Paukrt wrote:

Hi Bin,

I have found out that your patch 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/musb/musb_host.c?id=dbac5d07d13e330e6706813c9fde477140fb5d80
is causing at least issues with SMSC9500 Ethernet chips and RT2800
WiFi chips. Error EPROTO sometimes happens during communication with
these chips and it leads to stopping communication.

We have kernel 3.12.10 with backported selected patches including
yours. Do we miss some patch that should restart sending URBs? In
our situation sending URBs just stop after first failure and is not
resumed unless we execute for example "ifconfig eth2 down" and
"ifconfig eth2 up".

Sorry for causing the regression. I will loop you in another email
thread to try to find a solution.

Regards,
-Bin.
.



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html