public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Julius Werner <jwerner@chromium.org>,
	Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Vincent Palatin <vpalatin@chromium.org>,
	Andrew Bresticker <abrestic@chromium.org>,
	Jim Lin <jilin@nvidia.com>
Subject: Re: [PATCH] usb: xhci: Correct last context entry calculation for Configure Endpoint
Date: Tue, 29 Apr 2014 20:16:33 +0300	[thread overview]
Message-ID: <535FDE71.7000601@linux.intel.com> (raw)
In-Reply-To: <CAODwPW_N9sNKCcfD9ebGgCW71+zN_Ge9OM9uq7eRwyxgfyu4Uw@mail.gmail.com>

On 04/29/2014 06:11 AM, Julius Werner wrote:
> *bump*
>
> Sarah, Mathias, can we decide how to proceed with this? I think the
> section Alan quoted is a pretty good argument in favor of my
> interpretation (although of course this would not be the first time
> that two sections of a spec contradict each other). But more
> importantly, we have a case that just generates a clearly wrong Slot
> Context right now (the one that only drops endpoints), and I see no
> way how you could construct a correct Slot Context for that case with
> Sarah's interpretation. We need to resolve that somehow.

We discussed with Sarah that we should try this out and queue it for 
usb-linus. This clearly fixes the generation of a invalid slot context 
if all endpoints are dropped.

But because there hasn't been any reported issue about the other case 
this changes (always setting context entries to last valid ep in target 
configuration), and spec still has this tiny contradiction in this case, 
we should keep this out of stable. At least for now, until it gets some 
real world testing coverage.

-Mathias



  reply	other threads:[~2014-04-29 17:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-25 18:42 [PATCH] usb: xhci: Correct last context entry calculation for Configure Endpoint Julius Werner
2014-03-28 16:42 ` Felipe Balbi
2014-03-28 16:49 ` Mathias Nyman
2014-03-31 21:25 ` Sarah Sharp
2014-04-01 21:29   ` Julius Werner
2014-04-01 22:01     ` Alan Stern
2014-04-29  3:11       ` Julius Werner
2014-04-29 17:16         ` Mathias Nyman [this message]
2014-04-29 17:17           ` Julius Werner
2014-04-29 17:38             ` [PATCH v2] " Julius Werner
2014-04-30 23:04               ` Sarah Sharp
2014-04-30 23:28                 ` Felipe Balbi
2014-04-30 23:31                 ` Sarah Sharp

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=535FDE71.7000601@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=abrestic@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jilin@nvidia.com \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    --cc=vpalatin@chromium.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox