From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Julius Werner <jwerner@chromium.org>,
Mathias Nyman <mathias.nyman@intel.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, 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: Fri, 28 Mar 2014 18:49:40 +0200 [thread overview]
Message-ID: <5335A824.2060204@linux.intel.com> (raw)
In-Reply-To: <1395772963-14127-1-git-send-email-jwerner@chromium.org>
On 03/25/2014 08:42 PM, Julius Werner wrote:
> The current XHCI driver recalculates the Context Entries field in the
> Slot Context on every add_endpoint() and drop_endpoint() call. In the
> case of drop_endpoint(), it seems to assume that the add_flags will
> always contain every endpoint for the new configuration, which is not
> necessarily correct if you don't make assumptions about how the USB core
> uses the add_endpoint/drop_endpoint interface (add_flags only contains
> endpoints that are new additions in the new configuration).
>
> Furthermore, EP0_FLAG is not consistently set in add_flags throughout
> the lifetime of a device. This means that when all endpoints are
> dropped, the Context Entries field can be set to 0 (which is invalid and
> may cause a Parameter Error) or -1 (which is interpreted as 31 and
> causes the driver to keep using the old, incorrect value).
>
> The only surefire way to set this field right is to also take all
> existing endpoints into account, and to force the value to 1 (meaning
> only EP0 is active) if no other endpoint is found. This patch implements
> that as a single step in the final check_bandwidth() call and removes
> the intermediary calculations from add_endpoint() and drop_endpoint().
>
Hi
I think this looks good in general, but before I really dig into it I'd
like to know if this has triggered any problems so far? (e.g. slot
context's context entries getting zeroed, or set to a smaller value than
the last active endpoint context, causing trouble)
-Mathias
next prev parent reply other threads:[~2014-03-28 16:39 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 [this message]
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
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=5335A824.2060204@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=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 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.