From patchwork Wed Dec 9 02:48:10 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robert Hancock X-Patchwork-Id: 40700 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 49C3EB6F0C for ; Wed, 9 Dec 2009 13:48:19 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755086AbZLICsK (ORCPT ); Tue, 8 Dec 2009 21:48:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756471AbZLICsJ (ORCPT ); Tue, 8 Dec 2009 21:48:09 -0500 Received: from mail-gx0-f226.google.com ([209.85.217.226]:57239 "EHLO mail-gx0-f226.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755086AbZLICsI (ORCPT ); Tue, 8 Dec 2009 21:48:08 -0500 Received: by gxk26 with SMTP id 26so5739709gxk.1 for ; Tue, 08 Dec 2009 18:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=xhgsne8Ndkx3YyOXdk9mBQDbpYK9jxI5vSO8NQgGY8o=; b=qhTI+jmb28VoRTOElzEjwa2rsdn5XB3in9jbV0AiboD+0pC0fbq4I4lIJGugaJNLH9 32YlV8qEbl5PhhaT3di49fjlXx8CykwqezGyB5FqPMGYXNh2ruklfZiJzQuYB1X5T4Vd a+qb8udB/fqOptfZMZ1lcwE83xkFaGAAXqe9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=CUoMWo7TsBwt1FvJINmSjax/3SAgv9EzQ3z3iWlYG2qgqFNbRz7TthUa03e0BQJPn1 BZFsZGhPfIpe0Ed7iO9LwVSHEIF1+FTt+Nt6c6IjPGjGnfwavIVsRA47xkTdjGXSyarl qitdAxRwYDtb7l/5ho9TcCUEUOa0jdbblhv8E= Received: by 10.91.147.14 with SMTP id z14mr850947agn.105.1260326892857; Tue, 08 Dec 2009 18:48:12 -0800 (PST) Received: from ?192.168.1.148? (S0106000c41bb86e1.ss.shawcable.net [70.76.47.20]) by mx.google.com with ESMTPS id 23sm4497449iwn.15.2009.12.08.18.48.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Dec 2009 18:48:12 -0800 (PST) Message-ID: <4B1F0FEA.7070403@gmail.com> Date: Tue, 08 Dec 2009 20:48:10 -0600 From: Robert Hancock User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091203 Fedora/3.0-3.13.rc2.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: ide , Jeff Garzik Subject: [PATCH] libata: fix reporting of drained bytes when clearing DRQ Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org When we drain data from a device to clear DRQ during error recovery, the number of bytes reported as drained is too low by a factor of 2 because the count is actually reporting the number of words drained, not bytes. Fix this. Signed-off-by: Robert Hancock --- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c index 51eb1e2..3afa21b 100644 --- a/drivers/ata/libata-sff.c +++ b/drivers/ata/libata-sff.c @@ -2275,7 +2275,7 @@ void ata_sff_drain_fifo(struct ata_queued_cmd *qc) ap = qc->ap; /* Drain up to 64K of data before we give up this recovery method */ for (count = 0; (ap->ops->sff_check_status(ap) & ATA_DRQ) - && count < 32768; count++) + && count < 65536; count += 2) ioread16(ap->ioaddr.data_addr); /* Can become DEBUG later */