Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Gabor Juhos <juhosg@openwrt.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, Imre Kaloz <kaloz@openwrt.org>,
	"Luis R. Rodriguez" <lrodriguez@atheros.com>,
	Cliff Holden <Cliff.Holden@Atheros.com>,
	Kathy Giori <Kathy.Giori@Atheros.com>,
	David Brownell <dbrownell@users.sourceforge.net>,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 11/16] USB: ehci: add workaround for Synopsys HC bug
Date: Wed, 22 Dec 2010 16:30:48 -0800	[thread overview]
Message-ID: <20101223003048.GB9811@suse.de> (raw)
In-Reply-To: <1293049861-28913-12-git-send-email-juhosg@openwrt.org>

On Wed, Dec 22, 2010 at 09:30:56PM +0100, Gabor Juhos wrote:
> A Synopsys USB core used in various SoCs has a bug which might cause
> that the host controller not issuing ping.
> 
> When software uses the Doorbell mechanism to remove queue heads, the
> host controller still has references to the removed queue head even
> after indicating an Interrupt on Async Advance. This happens if the last
> executed queue head's Next Link queue head is removed.
> 
> Consequences of the defect:
> The Host controller fetches the removed queue head, using memory that
> would otherwise be deallocated.This results in incorrect transactions on
> both the USB and system memory. This may result in undefined behavior.
> 
> Workarounds:
> 
> 1) If no queue head is active (no Status field's Active bit is set)
> after removing the queue heads, the software can write one of the valid
> queue head addresses to the ASYNCLISTADDR register and deallocate the
> removed queue head's memory after 2 microframes.
> 
> If one or more of the queue heads is active (the Active bit is set in
> the Status field) after removing the queue heads, the software can delay
> memory deallocation after time X, where X is the time required for the
> Host Controller to go through all the queue heads once. X varies with
> the number of queue heads and the time required to process periodic
> transactions: if more periodic transactions must be performed, the Host
> Controller has less time to process asynchronous transaction processing.
> 
> 2) Do not use the Doorbell mechanism to remove the queue heads. Disable
> the Asynchronous Schedule Enable bit instead.
> 
> The bug has been discussed on the linux-usb-devel mailing-list
> four years ago, the original thread can be found here:
> http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg45345.html
> 
> This patch implements the first workaround as suggested by David Brownell.
> The built-in USB host controller of the Atheros AR7130/AR7141/AR7161 SoCs
> requires this to work properly.
> 
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Cc: David Brownell <dbrownell@users.sourceforge.net>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: linux-usb@vger.kernel.org
> ---
> 
> Changes since RFC: ---
> 
> Changes since v1:
>     - rebased against 2.6.37-rc7
> 
>  drivers/usb/host/ehci-q.c |    3 +++
>  drivers/usb/host/ehci.h   |    1 +
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> index 233c288..343b8de 100644
> --- a/drivers/usb/host/ehci-q.c
> +++ b/drivers/usb/host/ehci-q.c
> @@ -1193,6 +1193,9 @@ static void end_unlink_async (struct ehci_hcd *ehci)
>  		ehci->reclaim = NULL;
>  		start_unlink_async (ehci, next);
>  	}
> +
> +	if (ehci->has_synopsys_hc_bug)
> +		writel((u32)ehci->async->qh_dma, &ehci->regs->async_next);
>  }
>  
>  /* makes sure the async qh will become idle */
> diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> index ba8eab3..6da85b2 100644
> --- a/drivers/usb/host/ehci.h
> +++ b/drivers/usb/host/ehci.h
> @@ -133,6 +133,7 @@ struct ehci_hcd {			/* one per controller */
>  	unsigned		broken_periodic:1;
>  	unsigned		fs_i_thresh:1;	/* Intel iso scheduling */
>  	unsigned		use_dummy_qh:1;	/* AMD Frame List table quirk*/
> +	unsigned		has_synopsys_hc_bug:1; /* Synopsys HC */

That's fine, but who sets this value to 1?  I don't see any code that
does that, so why add this at all?  :)

thanks,

greg k-h

  reply	other threads:[~2010-12-23  0:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-22 20:30 [PATCH v2 00/16] MIPS: initial support for the Atheros AR71XX/AR724X/AR913X SoCs Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 01/16] MIPS: add initial support for the Atheros AR71XX/AR724X/AR931X SoCs Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 02/16] MIPS: ath79: add GPIOLIB support Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 03/16] MIPS: ath79: utilize the MIPS multi-machine support Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 04/16] MIPS: ath79: add initial support for the Atheros PB44 reference board Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 05/16] MIPS: ath79: add common GPIO LEDs device Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 06/16] watchdog: add driver for the Atheros AR71XX/AR724X/AR913X SoCs Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 07/16] MIPS: ath79: add common watchdog device Gabor Juhos
2010-12-23 10:41   ` Sergei Shtylyov
2010-12-22 20:30 ` [PATCH v2 08/16] MIPS: ath79: add common GPIO buttons device Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 09/16] spi: add SPI controller driver for the Atheros AR71XX/AR724X/AR913X SoCs Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 10/16] MIPS: ath79: add common SPI controller device Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 11/16] USB: ehci: add workaround for Synopsys HC bug Gabor Juhos
2010-12-23  0:30   ` Greg KH [this message]
2010-12-23  8:29     ` Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 12/16] USB: ehci: add bus glue for the Atheros AR71XX/AR724X/AR913X SoCs Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 13/16] USB: ohci: add bus glue for the Atheros AR71XX/AR7240 SoCs Gabor Juhos
2010-12-22 20:30 ` [PATCH v2 14/16] MIPS: ath79: add common USB Host Controller device Gabor Juhos
2010-12-22 20:31 ` [PATCH v2 15/16] MIPS: ath79: add initial support for the Atheros AP81 reference board Gabor Juhos
2010-12-22 20:31 ` [PATCH v2 16/16] MIPS: ath79: add common WMAC device for AR913X based boards Gabor Juhos

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=20101223003048.GB9811@suse.de \
    --to=gregkh@suse.de \
    --cc=Cliff.Holden@Atheros.com \
    --cc=Kathy.Giori@Atheros.com \
    --cc=dbrownell@users.sourceforge.net \
    --cc=juhosg@openwrt.org \
    --cc=kaloz@openwrt.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lrodriguez@atheros.com \
    --cc=ralf@linux-mips.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