On 02/16/2016 01:22 PM, John Garry wrote: > When TRANS_TX_CREDIT_TIMEOUT_ERR or > TRANS_TX_CLOSE_NORMAL_ERR errors occur for a > command, the command should be re-attempted. > > Signed-off-by: John Garry <john.garry@xxxxxxxxxx> > --- > drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 22 ++++++++++++++++++---- > 1 file changed, 18 insertions(+), 4 deletions(-) > > diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c > index ce5f65d..34f71a1c 100644 > --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c > +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c > @@ -1118,9 +1118,8 @@ static int prep_ssp_v1_hw(struct hisi_hba *hisi_hba, > } > > /* by default, task resp is complete */ > -static void slot_err_v1_hw(struct hisi_hba *hisi_hba, > - struct sas_task *task, > - struct hisi_sas_slot *slot) > +static void slot_err_v1_hw(struct hisi_hba *hisi_hba, struct sas_task *task, > + struct hisi_sas_slot *slot, int *abort_slot) > { > struct task_status_struct *ts = &task->task_status; > struct hisi_sas_err_record_v1 *err_record = slot->status_buffer; > @@ -1212,6 +1211,14 @@ static void slot_err_v1_hw(struct hisi_hba *hisi_hba, > ts->stat = SAS_NAK_R_ERR; > break; > } > + case TRANS_TX_CREDIT_TIMEOUT_ERR: > + case TRANS_TX_CLOSE_NORMAL_ERR: > + { > + /* This will request a retry */ > + ts->stat = SAS_QUEUE_FULL; > + ++(*abort_slot); > + break; > + } > default: > { > ts->stat = SAM_STAT_CHECK_CONDITION; > @@ -1317,8 +1324,14 @@ static int slot_complete_v1_hw(struct hisi_hba *hisi_hba, > > if (cmplt_hdr_data & CMPLT_HDR_ERR_RCRD_XFRD_MSK && > !(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK)) { > + int abort_slot = 0; > > - slot_err_v1_hw(hisi_hba, task, slot); > + slot_err_v1_hw(hisi_hba, task, slot, &abort_slot); > + if (unlikely(abort_slot)) { > + queue_work(hisi_hba->wq, &slot->abort_slot); > + sts = ts->stat; > + goto out_1; > + } > goto out; > } > What is the 'abort_slot' variable for? Currently it's just a counter, no? So why the weird pointer passing? And it does feel weird. Apparently the driver does get a message, but still has to abort the command. Why? Isn't the message an indicator that the command has been aborted? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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