All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Erkka Talvitie" <erkka.talvitie@vincit.fi>
To: "'Alan Stern'" <stern@rowland.harvard.edu>
Cc: <gregkh@linuxfoundation.org>, <linux-usb@vger.kernel.org>,
	<claus.baumgartner@med.ge.com>
Subject: RE: [RFCv1 1/1] USB: EHCI: Do not return -EPIPE when hub is disconnected
Date: Thu, 5 Dec 2019 17:00:11 +0200	[thread overview]
Message-ID: <022001d5ab7c$b1e27380$15a75a80$@vincit.fi> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1912050929350.14919-100000@netrider.rowland.org>



> -----Original Message-----
> From: Alan Stern <stern@rowland.harvard.edu>
> Sent: torstai 5. joulukuuta 2019 16.38
> To: Erkka Talvitie <erkka.talvitie@vincit.fi>
> Cc: gregkh@linuxfoundation.org; linux-usb@vger.kernel.org;
> claus.baumgartner@med.ge.com
> Subject: RE: [RFCv1 1/1] USB: EHCI: Do not return -EPIPE when hub is
> disconnected
> 
> On Thu, 5 Dec 2019, Erkka Talvitie wrote:
> 
> > I tested this change and the issue did not reproduce.
> >
> > However when I was writing the comments for the patch I started to
> > think what happens in this following scenario:
> >
> > The PID Code is IN.
> >
> > 1. First there will be XACT, the CERR is decremented, let's say from 3
> > to 2 and the host controller executes a retry.
> > 2. On this next try there will happen the condition mentioned in the
> > Table
> > 4-13 of the EHCI specification so that the MMF is set and the queue is
> > halted (because it is IN).
> > 3. To my understanding now the execution enters to this first stall
> > check if, as CERR is > 0 and CERR < EHCI_TUNE_CERR.
> > 4. The -EPIPE (stall) is returned when actually the queue was halted
> > due to MMF - not stall - and the -EPROTO should be returned.
> >
> > Is my logic correct or am I missing something?
> 
> The same thought had occurred to me.
> 
> > If you agree with me then I would like to present you a bit more bold
> > (in a sense of amount of refactoring) RFC. In high level this another
> > RFC separates 1. error check and 2. stall check. For me this approach
> > is a bit easier to understand from the code. Or then please  propose
> > another solution.
> 
> I was going to suggest: Just check for MMF and PID == IN before checking
for
> STALL.  Everything else can remain the way it is.

Ok, just to double check:

I take the existing driver code (I will not apply the earlier RFC on top of
that) and apply one more check before the original stall check (that is):
} else if (QTD_CERR(token)) {

The check that I will add is checking MMF bit && PID == IN, and this check
comes right after the babble check, right?

Good, seems like a simple change. Yet I still prefer to test the change.
Unfortunately that goes to the next week as we have a national holiday
tomorrow. 
I will get back to you most likely on Monday.

> 
> Alan Stern
> 
Erkka Talvitie


  reply	other threads:[~2019-12-05 15:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 14:08 [RFCv1 1/1] USB: EHCI: Do not return -EPIPE when hub is disconnected Erkka Talvitie
2019-12-02 19:43 ` Alan Stern
2019-12-03  9:38   ` Erkka Talvitie
2019-12-03 10:54     ` Erkka Talvitie
2019-12-03 13:35       ` Erkka Talvitie
2019-12-03 19:01     ` Alan Stern
2019-12-04  8:55       ` Erkka Talvitie
2019-12-04 13:18         ` Erkka Talvitie
2019-12-04 14:24           ` Alan Stern
2019-12-04 14:37             ` Erkka Talvitie
2019-12-05 10:35               ` Erkka Talvitie
2019-12-05 14:37                 ` Alan Stern
2019-12-05 15:00                   ` Erkka Talvitie [this message]
2019-12-09  9:57                     ` Erkka Talvitie
2019-12-09 15:24                       ` Alan Stern
2019-12-10  6:31                         ` Erkka Talvitie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='022001d5ab7c$b1e27380$15a75a80$@vincit.fi' \
    --to=erkka.talvitie@vincit.fi \
    --cc=claus.baumgartner@med.ge.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.