Re: [PATCH] sata_nv.c, don't have libata perform phy reset

[Jeff Garzik]

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@xxxxxxxxxx>
>
>
> --- 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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/