Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1390268 > unrolled thread

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Started byBin Liu <b-liu@ti.com>
First post2016-04-28 16:40 +0200
Last post2016-05-05 15:50 +0200
Articles 15 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-04-28 16:40 +0200
    Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Yegor Yefremov <yegorslists@googlemail.com> - 2016-05-03 12:10 +0200
      Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-03 15:50 +0200
        Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Yegor Yefremov <yegorslists@googlemail.com> - 2016-05-03 16:30 +0200
          Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-03 16:40 +0200
            Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Yegor Yefremov <yegorslists@googlemail.com> - 2016-05-04 17:00 +0200
              Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-04 21:00 +0200
                Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-05-04 21:10 +0200
                  Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-04 21:20 +0200
                    Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Greg KH <gregkh@linuxfoundation.org> - 2016-05-04 22:20 +0200
                      Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-04 22:50 +0200
                    Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-05-05 15:30 +0200
                      Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-05 15:40 +0200
                        Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-05-05 15:40 +0200
                          Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error Bin Liu <b-liu@ti.com> - 2016-05-05 15:50 +0200

#1390268 — Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

FromBin Liu <b-liu@ti.com>
Date2016-04-28 16:40 +0200
SubjectRe: [PATCHv2] musb_host: fix lockup on rxcsr_h_error
Message-ID<rsVgL-4Ob-51@gated-at.bofh.it>
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.

> 
> 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.

[toc] | [next] | [standalone]

#1393271

FromYegor Yefremov <yegorslists@googlemail.com>
Date2016-05-03 12:10 +0200
Message-ID<ruFrc-6jc-7@gated-at.bofh.it>
In reply to#1390268
On Thu, Apr 28, 2016 at 4:37 PM, Bin Liu <b-liu@ti.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@googlemail.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.

[toc] | [prev] | [next] | [standalone]

#1393427

FromBin Liu <b-liu@ti.com>
Date2016-05-03 15:50 +0200
Message-ID<ruIS7-Hw-23@gated-at.bofh.it>
In reply to#1393271
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 <b-liu@ti.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@googlemail.com>

Thanks for testing.

Can you please test the patch [1] instead? I'd like to use it as the
fix.

Regards,
-Bin.

[1] http://marc.info/?l=linux-usb&m=146222355213935&w=2

[toc] | [prev] | [next] | [standalone]

#1393448

FromYegor Yefremov <yegorslists@googlemail.com>
Date2016-05-03 16:30 +0200
Message-ID<ruJuO-1iW-5@gated-at.bofh.it>
In reply to#1393427
On Tue, May 3, 2016 at 3:48 PM, Bin Liu <b-liu@ti.com> 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 <b-liu@ti.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@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

Yegor

[toc] | [prev] | [next] | [standalone]

#1393460

FromBin Liu <b-liu@ti.com>
Date2016-05-03 16:40 +0200
Message-ID<ruJEu-1mn-15@gated-at.bofh.it>
In reply to#1393448
Hi,

On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote:
> On Tue, May 3, 2016 at 3:48 PM, Bin Liu <b-liu@ti.com> 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 <b-liu@ti.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@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.

Regards,
-Bin.

[toc] | [prev] | [next] | [standalone]

#1394413

FromYegor Yefremov <yegorslists@googlemail.com>
Date2016-05-04 17:00 +0200
Message-ID<rv6rn-5XA-1@gated-at.bofh.it>
In reply to#1393460
On Tue, May 3, 2016 at 4:35 PM, Bin Liu <b-liu@ti.com> wrote:
> Hi,
>
> On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote:
>> On Tue, May 3, 2016 at 3:48 PM, Bin Liu <b-liu@ti.com> 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 <b-liu@ti.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@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.

Yegor

[toc] | [prev] | [next] | [standalone]

#1394632

FromBin Liu <b-liu@ti.com>
Date2016-05-04 21:00 +0200
Message-ID<rvabE-Yb-7@gated-at.bofh.it>
In reply to#1394413
Hi,

On Wed, May 04, 2016 at 04:49:50PM +0200, Yegor Yefremov wrote:
> On Tue, May 3, 2016 at 4:35 PM, Bin Liu <b-liu@ti.com> wrote:
> > Hi,
> >
> > On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote:
> >> On Tue, May 3, 2016 at 3:48 PM, Bin Liu <b-liu@ti.com> 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 <b-liu@ti.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@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.

Regards,
-Bin.

[toc] | [prev] | [next] | [standalone]

#1394636

FromSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date2016-05-04 21:10 +0200
Message-ID<rvalj-1lA-1@gated-at.bofh.it>
In reply to#1394632
Hello.

On 05/04/2016 09:56 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?

> Regards,
> -Bin.

MBR, Sergei

[toc] | [prev] | [next] | [standalone]

#1394648

FromBin Liu <b-liu@ti.com>
Date2016-05-04 21:20 +0200
Message-ID<rvav0-1pG-29@gated-at.bofh.it>
In reply to#1394636
Hi,

On Wed, May 04, 2016 at 10:02:16PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 05/04/2016 09:56 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.

Regards,
-Bin.

> 
> >Regards,
> >-Bin.
> 
> MBR, Sergei
>

[toc] | [prev] | [next] | [standalone]

#1394688

FromGreg KH <gregkh@linuxfoundation.org>
Date2016-05-04 22:20 +0200
Message-ID<rvbr3-2fh-3@gated-at.bofh.it>
In reply to#1394648
On Wed, May 04, 2016 at 02:17:15PM -0500, Bin Liu wrote:
> Hi,
> 
> On Wed, May 04, 2016 at 10:02:16PM +0300, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 05/04/2016 09:56 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.

No, your original idea of getting it into 4.7-rc1 first is the best, I
will not take this for 4.6-final right now, it's not a regression.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1394711

FromBin Liu <b-liu@ti.com>
Date2016-05-04 22:50 +0200
Message-ID<rvbU5-2vN-7@gated-at.bofh.it>
In reply to#1394688
Hi,

On Wed, May 04, 2016 at 01:19:27PM -0700, Greg KH wrote:
> On Wed, May 04, 2016 at 02:17:15PM -0500, Bin Liu wrote:
> > Hi,
> > 
> > On Wed, May 04, 2016 at 10:02:16PM +0300, Sergei Shtylyov wrote:
> > > Hello.
> > > 
> > > On 05/04/2016 09:56 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.
> 
> No, your original idea of getting it into 4.7-rc1 first is the best, I
> will not take this for 4.6-final right now, it's not a regression.

Ok, noted.

> 
> thanks,
> 
> greg k-h

Regards,
-Bin.

[toc] | [prev] | [next] | [standalone]

#1395116

FromSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date2016-05-05 15:30 +0200
Message-ID<rvrvR-MH-41@gated-at.bofh.it>
In reply to#1394648
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

[toc] | [prev] | [next] | [standalone]

#1395126

FromBin Liu <b-liu@ti.com>
Date2016-05-05 15:40 +0200
Message-ID<rvrFw-S0-15@gated-at.bofh.it>
In reply to#1395116
Hi,

On Thu, May 05, 2016 at 04:21:23PM +0300, Sergei Shtylyov wrote:
> 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

This is my understanding of the manual too.

> meant that the interrupt is generated only on transition from 0 to
> 1....

What transition? the RXCSR bit? 'set' means from 0 to 1, 'clear' means 1
-> 0, right? I don't see you have any misunderstanding.

> 
> >Regards,
> >-Bin.
> 
> MBR, Sergei
>

[toc] | [prev] | [next] | [standalone]

#1395128

FromSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date2016-05-05 15:40 +0200
Message-ID<rvrFw-S0-19@gated-at.bofh.it>
In reply to#1395126
On 5/5/2016 4:31 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
>
> This is my understanding of the manual too.
>
>> meant that the interrupt is generated only on transition from 0 to
>> 1....
>
> What transition? the RXCSR bit?

    Of course.

> 'set' means from 0 to 1, 'clear' means 1 -> 0, right?

    Well, in my understanding "set" means 1 and "clear" means 0.

> I don't see you have any misunderstanding.

>>> Regards,
>>> -Bin.

MBR, Sergei

[toc] | [prev] | [next] | [standalone]

#1395134

FromBin Liu <b-liu@ti.com>
Date2016-05-05 15:50 +0200
Message-ID<rvrPc-Wp-31@gated-at.bofh.it>
In reply to#1395128
On Thu, May 05, 2016 at 04:39:06PM +0300, Sergei Shtylyov wrote:
> On 5/5/2016 4:31 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
> >
> >This is my understanding of the manual too.
> >
> >>meant that the interrupt is generated only on transition from 0 to
> >>1....
> >
> >What transition? the RXCSR bit?
> 
>    Of course.
> 
> >'set' means from 0 to 1, 'clear' means 1 -> 0, right?
> 
>    Well, in my understanding "set" means 1 and "clear" means 0.

This is right. I didn't mean raising or falling edge when mentioning
0->1 or 1->0. We don't know when exactly the controller generates the
interrupt when CSR bit changes, and we/driver don't care.

> 
> >I don't see you have any misunderstanding.
> 
> >>>Regards,
> >>>-Bin.
> 
> MBR, Sergei
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web