MUSB interrupt storm on device removal

[Bin Liu <b-liu@ti.com>]

Hi Johan,

On Tue, Jan 22, 2019 at 02:16:30PM -0600, Bin Liu wrote:
> On Tue, Jan 22, 2019 at 05:19:39PM +0000, Måns Rullgård wrote:
> > Bin Liu <b-liu@ti.com> writes:
> > 
> > > On Mon, Jan 21, 2019 at 09:20:52PM +0000, Måns Rullgård wrote:
> > >> Bin Liu <b-liu@ti.com> writes:
> > >> 
> > >> > On Fri, Jan 18, 2019 at 08:15:02PM +0000, Måns Rullgård wrote:
> > >> >> Bin Liu <b-liu@ti.com> writes:
> > >> >> 
> > >> >> > On Mon, Dec 17, 2018 at 09:36:17PM +0000, Måns Rullgård wrote:
> > >> >> >> Bin Liu <b-liu@ti.com> writes:
> > >> >> >> 
> > >> >> >> > On Mon, Dec 17, 2018 at 07:16:08PM +0000, Måns Rullgård wrote:
> > >> >> >> >> Bin Liu <b-liu@ti.com> writes:
> > >> >> >> >> 
> > >> >> >> >> > Hi,
> > >> >> >> >> >
> > >> >> >> >> > On Mon, Dec 17, 2018 at 03:13:12PM +0000, Måns Rullgård wrote:
> > >> >> >> >> >> I have a strange problem with the musb driver in host mode on AM3358
> > >> >> >> >> >> (beaglebone) hardware.  If I connect a multi-port serial adapter and
> > >> >
> > >> > Is this on beaglebone or beagleboneblack?
> > >> 
> > >> We've seen it with Beaglebone Enhanced [1] and BeagleCore [2] based
> > >> devices.  Both are based on the AM3358 and mostly compatible with the
> > >> Beaglebone Black.
> > >> 
> > >> [1] https://elinux.org/SanCloud_BeagleBoneEnhanced
> > >> [2] http://beaglecore.com/products/bcm1str.html
> > >
> > > Okay, now I see you have a hub on the board. I just reproduced the
> > > console lockup after added a hub in my setup. I will find some time to
> > > debug this.
> > >
> > > FYI, there was a similar issue in a few years ago, which was that the
> > > hub routine never got called during the storm then the device disconnect
> > > event never got populated from the hub driver. I am wondering if this is
> > > the same issue pops up again...
> > 
> > Now that you mentioned the hub, I tried connecting the serial adapter to
> > the OTG port (in host mode) on the Beaglebone Enhanced (it's not
> > normally used in this product).  When connected directly, the disconnect
> > indeed works properly.  With a hub in between, it breaks.
> 
> Please use the following hack as a workaround for now. I will think more
> about it.
> 
> Regards,
> -Bin.
> 
> --------8<----------
> diff git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index b59ce9ad14ce..3719f6d9b26c 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -1811,7 +1811,7 @@ void musb_host_rx(struct musb *musb, u8 epnum)
>         } else if (rx_csr & MUSB_RXCSR_H_ERROR) {
>                 musb_dbg(musb, "end %d RX proto error", epnum);
>  
> -               status = -EPROTO;
> +               status = -EPIPE;
>                 musb_writeb(epio, MUSB_RXINTERVAL, 0);
>  
>                 rx_csr &= ~MUSB_RXCSR_H_ERROR;

When a usb serial device is detached, the musb controller driver returns
-EPROTO in urb giveback, then usb_serial_generic_read_bulk_callback()
re-submit the urb, this circle causes interrupt storm, and the hub
driver workqueue never got a chance to run to populate the device
disconnect event, the whole console locks up. Do you think
usb_serial_generic_read_bulk_callback() should handle -EPROTO as well?


Regards,
-Bin.

diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 2274d9625f63..8c2a6e55de3a 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -397,6 +397,7 @@ void usb_serial_generic_read_bulk_callback(struct urb *urb)
                                                        __func__, status);
                return;
        case -EPIPE:
+       case -EPROTO:
                dev_err(&port->dev, "%s - urb stopped: %d\n",
                                                        __func__, status);
                return;