On Thu, 2011-12-29 at 14:18 +0800, Jack Wang wrote:
> > @@ -267,39 +267,84 @@ static bool sas_ata_qc_fill_rtf(struct
> ata_queued_cmd
> > *qc)
> > return true;
> > }
> >
> > -static int sas_ata_hard_reset(struct ata_link *link, unsigned int *class,
> > - unsigned long deadline)
> > +static struct sas_internal *dev_to_sas_internal(struct domain_device
> *dev)
> > +{
> > + return to_sas_internal(dev->port->ha->core.shost->transportt);
> > +}
> > +
> > +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 sas_internal *i
> > - to_sas_internal(dev->port->ha->core.shost->transportt);
> > - int res = TMF_RESP_FUNC_FAILED;
> > - int ret = 0;
> > + struct domain_device *ex_dev = dev->parent;
> > + struct sas_phy *phy = sas_find_local_phy(dev);
> >
> > - if (i->dft->lldd_I_T_nexus_reset)
> > - res = i->dft->lldd_I_T_nexus_reset(dev);
> > + res = sas_get_phy_attached_sas_addr(ex_dev, phy->number, addr);
> > + /* 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)
> [Jack Wang]
> This check may not guarantee the FIS have received by the expander, should
> we
> Use sas_ex_phy_discover instead, we still need to teach
> sas_ex_phy_discover_helper to return right code.
So the concern seems valid, do we have a fix yet?
James
--
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
