From patchwork Mon Dec 3 01:35:49 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aaron Lu X-Patchwork-Id: 203258 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.180.67]) by ozlabs.org (Postfix) with ESMTP id 52DE92C00A7 for ; Mon, 3 Dec 2012 12:35:54 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754373Ab2LCBfx (ORCPT ); Sun, 2 Dec 2012 20:35:53 -0500 Received: from mga01.intel.com ([192.55.52.88]:30847 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754218Ab2LCBfw (ORCPT ); Sun, 2 Dec 2012 20:35:52 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2012 17:35:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,202,1355126400"; d="scan'208";a="258009215" Received: from mint-spring.sh.intel.com ([10.239.36.140]) by fmsmga002.fm.intel.com with ESMTP; 02 Dec 2012 17:35:49 -0800 Date: Mon, 3 Dec 2012 09:35:49 +0800 From: Aaron Lu To: Alan Cox Cc: Jeff Garzik , Borislav Petkov , Dutra Julio , Phillip Wood , Tejun Heo , Szymon Janc , Bernd Buschinski , linux-ide@vger.kernel.org Subject: Re: [PATCH] libata: fix ata_dma_enabled Message-ID: <20121203013548.GA1396@mint-spring.sh.intel.com> References: <50BBFA94.2070105@intel.com> <20121203012225.00e0c121@pyramind.ukuu.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20121203012225.00e0c121@pyramind.ukuu.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Mon, Dec 03, 2012 at 01:22:25AM +0000, Alan Cox wrote: > On Mon, 03 Dec 2012 09:04:20 +0800 > Aaron Lu wrote: > > > > > ata_dma_enabled should check if device is either using multi word DMA > > or ultra DMA instead of checking 0xff, as dma_mode 0 is not a valid dma > > mode either. > > > > This patch fixes the following bug: > > https://bugzilla.kernel.org/show_bug.cgi?id=49151 > > NAK > > dma_mode should *NEVER* be zero. If it's getting set to zero you have > another bug and that needs fixing instead The ata_dev->dma_mode is initialized as zero after we allocate the ata_device structure, and we did not set this field until the set mode function. If you think it should _never_ be zero, probably my previous patch did the job: it sets ata_dev->dma_mode to 0xff in the reset operation: So do you prefer this? Thanks, Aaron > > Alan --- 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-eh.c b/drivers/ata/libata-eh.c index 9426423..d772d66 100644 --- a/drivers/ata/libata-eh.c +++ b/drivers/ata/libata-eh.c @@ -2657,6 +2657,7 @@ int ata_eh_reset(struct ata_link *link, int classify, * bus as we may be talking too fast. */ dev->pio_mode = XFER_PIO_0; + dev->dma_mode = 0xff; /* If the controller has a pio mode setup function * then use it to set the chipset to rights. Don't