On Sat, Jan 14, 2012 at 10:10 AM, Dan Williams [off-list ref] wrote:

libsas fails to discover all sata devices in the domain.  If a device fails
negotiation and does not transmit a signature fis the link needs recovery.
libata already understands how to manage slow to come up links, so treat these
conditions as ata device attach events for the purposes of creating an
ata_port.  This allows libata to manage retrying link bring up.

Cc: Jack Wang <redacted>
Cc: Xiangliang Yu <redacted>
Cc: Luben Tuikov <redacted>
Signed-off-by: Dan Williams <redacted>
---

[..]

 static int smp_ata_check_ready(struct ata_link *link)
 {
       int res;
-       u8 addr[8];
       struct ata_port *ap = link->ap;
       struct domain_device *dev = ap->private_data;
       struct domain_device *ex_dev = dev->parent;
       struct sas_phy *phy = sas_get_local_phy(dev);
+       struct ex_phy *ex_phy = &ex_dev->ex_dev.ex_phy[phy->number];

-       res = sas_get_phy_attached_sas_addr(ex_dev, phy->number, addr);
+       res = sas_ex_phy_discover(ex_dev, phy->number);
       sas_put_local_phy(phy);
+
       /* break the wait early if the expander is unreachable,
        * otherwise keep polling
        */
       if (res == -ECOMM)
               return res;
-       if (res != SMP_RESP_FUNC_ACC || SAS_ADDR(addr) == 0)
+       if (res != SMP_RESP_FUNC_ACC)
               return 0;
-       else
-               return 1;
+
+       switch (ex_phy->attached_dev_type) {
+       case SATA_PENDING:
+               return 0;
+       case SAS_END_DEV:
+               if (ex_phy->attached_sata_dev)
+                       return sas_ata_clear_pending(dev, ex_phy);
+       default:
+               return -ENODEV;
+       }
 }

Side comment, it strikes me as deadlock prone that we need to do
GFP_KERNEL allocations to recover a domain_device.  Since we're now
enforcing one in-flight smp command per expander, we might as well
pre-allocate the request/response buffers for managing remote phys.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html