All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org, sarah.a.sharp@linux.intel.com,
	linux-kernel@vger.kernel.org,
	Julius Werner <jwerner@chromium.org>
Subject: Re: [PATCH 1/5] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
Date: Thu, 24 Apr 2014 12:49:05 -0700	[thread overview]
Message-ID: <20140424194905.GA12809@kroah.com> (raw)
In-Reply-To: <1398169382-12097-2-git-send-email-mathias.nyman@linux.intel.com>

On Tue, Apr 22, 2014 at 03:22:58PM +0300, Mathias Nyman wrote:
> From: Julius Werner <jwerner@chromium.org>
> 
> We have observed a rare cycle state desync bug after Set TR Dequeue
> Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
> doesn't fetch new TRBs and thus an unresponsive USB device). It always
> triggers when a previous Set TR Dequeue Pointer command has set the
> pointer to the final Link TRB of a segment, and then another URB gets
> enqueued and cancelled again before it can be completed. Further
> investigation showed that the xHC had returned the Link TRB in the TRB
> Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
> but when xhci_find_new_dequeue_state() later accesses the Endpoint
> Context's TR Dequeue Pointer field it is set to the first TRB of the
> next segment.
> 
> The driver expects those two values to be the same in this situation,
> and uses the cycle state of the latter together with the address of the
> former. This should be fine according to the XHCI specification, since
> the endpoint ring should be stopped when returning the Transfer Event
> and thus should not advance over the Link TRB before it gets restarted.
> However, real-world XHCI implementations apparently don't really care
> that much about these details, so the driver should follow a more
> defensive approach to try to work around HC spec violations.
> 
> This patch removes the stopped_trb variable that had been used to store
> the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
> xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
> requiring a small amount of additional processing to find the virtual
> address corresponding to the TR Dequeue Pointer. Some other parts of the
> function were slightly rearranged to better fit into this model.
> 
> This patch should be backported to kernels as old as 2.6.31 that contain
> the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
> cancellation support."

Ok, but:

> 
> Signed-off-by: Julius Werner <jwerner@chromium.org>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

You don't actually add the stable@ tag here, why not?

You have read Documentation/stable_kernel_rules.txt for how stable
kernel trees work, so why not add the label here?

greg k-h

  reply	other threads:[~2014-04-24 19:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-22 12:22 [PATCH 0/5] xhci: fixes for 3.15-rc usb-linus Mathias Nyman
2014-04-22 12:22 ` [PATCH 1/5] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb Mathias Nyman
2014-04-24 19:49   ` Greg KH [this message]
2014-04-24 20:15     ` Julius Werner
2014-04-22 12:22 ` [PATCH 2/5] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix() Mathias Nyman
2014-04-24 19:49   ` Greg KH
2014-04-25 10:48     ` Mathias Nyman
2014-04-22 12:23 ` [PATCH 3/5] xhci: Switch Intel Lynx Point ports to EHCI on shutdown Mathias Nyman
2014-04-24 19:49   ` Greg KH
2014-04-22 12:23 ` [PATCH 4/5] xhci: extend quirk for Renesas cards Mathias Nyman
2014-04-24 19:50   ` Greg KH
2014-04-22 12:23 ` [PATCH 5/5] usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM Mathias Nyman
2014-04-24 19:50   ` Greg KH
2014-04-24 20:15     ` David Cohen
2014-04-24 19:50 ` [PATCH 0/5] xhci: fixes for 3.15-rc usb-linus Greg KH
2014-04-25  8:11   ` Mathias Nyman

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=20140424194905.GA12809@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=sarah.a.sharp@linux.intel.com \
    /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.