* [PATCH] sata_nv.c, don't have libata perform phy reset
@ 2004-11-06 2:55 achew
2004-11-06 17:09 ` Jeff Garzik
0 siblings, 1 reply; 2+ messages in thread
From: achew @ 2004-11-06 2:55 UTC (permalink / raw)
To: Jeff Garzik, linux-kernel, linux-ide
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 <achew@nvidia.com>
--- 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 <linux/libata.h>
#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 |
ATA_FLAG_NO_LEGACY,
.pio_mask = NV_PIO_MASK,
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [PATCH] sata_nv.c, don't have libata perform phy reset
2004-11-06 2:55 [PATCH] sata_nv.c, don't have libata perform phy reset achew
@ 2004-11-06 17:09 ` Jeff Garzik
0 siblings, 0 replies; 2+ messages in thread
From: Jeff Garzik @ 2004-11-06 17:09 UTC (permalink / raw)
To: achew; +Cc: linux-kernel, linux-ide
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 <achew@nvidia.com>
>
>
> --- 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 <linux/libata.h>
>
> #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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-11-06 17:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-06 2:55 [PATCH] sata_nv.c, don't have libata perform phy reset achew
2004-11-06 17:09 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).