From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [PATCH] sata_nv.c, don't have libata perform phy reset Date: Sat, 06 Nov 2004 12:09:39 -0500 Message-ID: <418D0553.902@pobox.com> References: <418C3D3A.6010501@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:51879 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S261424AbUKFRJw (ORCPT ); Sat, 6 Nov 2004 12:09:52 -0500 In-Reply-To: <418C3D3A.6010501@nvidia.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: achew Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org achew wrote: > This patch works around the issue reported in bug 3352 on the bugzilla > bug database. > > Link to the bug report: http://bugme.osdl.org/show_bug_cgi?id=3352 > > In particular, we keep libata from performing the phy reset. Doing the > phy reset sometimes results in the busy bit failing to deassert. > > Signed-off-by: Andrew Chew > > > --- linux-2.6.10-rc1-bk15/drivers/scsi/sata_nv.c 2004-11-05 > 17:49:37.000000000 -0800 > +++ linux/drivers/scsi/sata_nv.c 2004-11-05 17:55:48.000000000 -0800 > @@ -20,6 +20,9 @@ > * If you do not delete the provisions above, a recipient may use your > * version of this file under either the OSL or the GPL. > * > + * 0.04 > + * - Disabled SATA phy reset to work around a problem where busy > bit never > + * deasserts after a phy reset. > * 0.03 > * - Fixed a bug where the hotplug handlers for non-CK804/MCP04 were > using > * mmio_base, which is only set for the CK804/MCP04 case. > @@ -44,7 +47,7 @@ > #include > > #define DRV_NAME "sata_nv" > -#define DRV_VERSION "0.03" > +#define DRV_VERSION "0.04" > > #define NV_PORTS 2 > #define NV_PIO_MASK 0x1f > @@ -221,7 +224,6 @@ > static struct ata_port_info nv_port_info = { > .sht = &nv_sht, > .host_flags = ATA_FLAG_SATA | > - ATA_FLAG_SATA_RESET | > ATA_FLAG_SRST | I'm not quite ready to apply this just yet. Reasons: 1) The code has two resets! I think it would be best to remove ATA_FLAG_SRST, since SATA reset should cover that. 2) Once ATA_FLAG_SRST is removed, if the problem still appears, I would prefer that you root-caused this problem. If it's a problem with the generic libata SATA reset code, I would prefer to fix that, rather than keep working around a bug that should be fixed. Jeff