On Tue, Dec 27, 2011 at 4:49 PM, Jack Wang <jack_wang@xxxxxxxxx> wrote:
> Hi all,
>
> For detecting a failure to transmit initial dev to host FIS as described in
> section G.5 of sas-2 r 04b , In order to generate the dev to host FIS, we
> send a link reset to the expander port, but this may still fail for some
> device, when this happened , we should ignore this , do not set the phy, let
> libsas find the device later .
>
> From a315c8ee6f6b7ad000d6dc72d31dfb576ecbceb5 Mon Sep 17 00:00:00 2001
> From: Jack Wang <jack_wang@xxxxxxxxx>
> Date: Tue, 27 Dec 2011 02:25:19 -0500
> Subject: [PATCH] don't set the invalid phy
>
> Signed-off-by: Lindar Liu <Lindar_liu@xxxxxxxxx>
> Signed-off-by: Jack Wang <jack_wang@xxxxxxxxx>
> ---
> drivers/scsi/libsas/sas_expander.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/libsas/sas_expander.c
> b/drivers/scsi/libsas/sas_expander.c
> index e47599b..c7a27c7 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -304,6 +304,12 @@ static int sas_ex_phy_discover_helper(struct
> domain_device *dev, u8 *disc_req,
> /* Wait for the reset to trigger the negotiation */
> msleep(500);
> }
> + if ((dr->attached_dev_type == 0 &&
> + dr->attached_sata_dev)) {
> + sas_printk("Found sata attached_dev_type = 0, ignore it to
> let it found later!\n");
> + return 0;
> + }
> +
> sas_set_ex_phy(dev, single, disc_resp);
> return 0;
> }
I wonder if we should just simulate the discovery of a sata disk in
this scenario?? Because the first thing libata is going to do is reset
it and wait for that to settle...
However, for that to work we would need to allow sas_ata_hard_reset to
set the detected device class. The current scheme of returning
dev->sata_dev.command_set (from what libsas set) is awkward since we
may have legitimately switched device classes during the reset, and
certainly wrong if we were not able to make a proper classification
during initial discovery.
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
