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.ga...@huawei.com>
> ---
> 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
h...@suse.de +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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
