From: Hannes Reinecke <hare@suse.de>
To: John Garry <john.garry@huawei.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com,
jinpu.wang@cloud.ionos.com, damien.lemoal@opensource.wdc.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ajish.Koshy@microchip.com, linuxarm@huawei.com,
Viswas.G@microchip.com, hch@lst.de, liuqi115@huawei.com,
chenxiang66@hisilicon.com
Subject: Re: [PATCH 1/4] scsi: libsas: Add sas_execute_internal_abort_single()
Date: Wed, 20 Apr 2022 14:21:39 +0200 [thread overview]
Message-ID: <929aede0-9e58-9c3d-5951-6151a3281edd@suse.de> (raw)
In-Reply-To: <1646309930-138960-2-git-send-email-john.garry@huawei.com>
On 3/3/22 13:18, John Garry wrote:
> The internal abort feature is common to hisi_sas and pm8001 HBAs, and the
> driver support is similar also, so add a common handler.
>
> Two modes of operation will be supported:
> - single: Abort a single tagged command
> - device: Abort all commands associated with a specific domain device
>
> A new protocol is added, SAS_PROTOCOL_INTERNAL_ABORT, so the common queue
> command API may be re-used.
>
> Only add "single" support as a first step.
>
> Signed-off-by: John Garry <john.garry@huawei.com>
> ---
> drivers/scsi/libsas/sas_scsi_host.c | 75 +++++++++++++++++++++++++++++
> include/scsi/libsas.h | 14 ++++++
> include/scsi/sas.h | 2 +
> 3 files changed, 91 insertions(+)
>
> diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c
> index 5b5747e33dbd..0d05826e6e8c 100644
> --- a/drivers/scsi/libsas/sas_scsi_host.c
> +++ b/drivers/scsi/libsas/sas_scsi_host.c
> @@ -920,6 +920,81 @@ void sas_task_internal_timedout(struct timer_list *t)
> #define TASK_TIMEOUT (20 * HZ)
> #define TASK_RETRY 3
>
> +static int sas_execute_internal_abort(struct domain_device *device,
> + enum sas_internal_abort type, u16 tag,
> + unsigned int qid, void *data)
> +{
> + struct sas_ha_struct *ha = device->port->ha;
> + struct sas_internal *i = to_sas_internal(ha->core.shost->transportt);
> + struct sas_task *task = NULL;
> + int res, retry;
> +
> + for (retry = 0; retry < TASK_RETRY; retry++) {
> + task = sas_alloc_slow_task(GFP_KERNEL);
> + if (!task)
> + return -ENOMEM;
> +
> + task->dev = device;
> + task->task_proto = SAS_PROTOCOL_INTERNAL_ABORT;
> + task->task_done = sas_task_internal_done;
> + task->slow_task->timer.function = sas_task_internal_timedout;
> + task->slow_task->timer.expires = jiffies + TASK_TIMEOUT;
> + add_timer(&task->slow_task->timer);
> +
> + task->abort_task.tag = tag;
> + task->abort_task.type = type;
> +
> + res = i->dft->lldd_execute_task(task, GFP_KERNEL);
> + if (res) {
> + del_timer_sync(&task->slow_task->timer);
> + pr_err("Executing internal abort failed %016llx (%d)\n",
> + SAS_ADDR(device->sas_addr), res);
> + break;
> + }
> +
> + wait_for_completion(&task->slow_task->completion);
> + res = TMF_RESP_FUNC_FAILED;
> +
> + /* Even if the internal abort timed out, return direct. */
> + if (task->task_state_flags & SAS_TASK_STATE_ABORTED) {
> + pr_err("Internal abort: timeout %016llx\n",
> + SAS_ADDR(device->sas_addr));
> +
> + res = -EIO;
> + break;
> + }
> +
> + if (task->task_status.resp == SAS_TASK_COMPLETE &&
> + task->task_status.stat == SAS_SAM_STAT_GOOD) {
> + res = TMF_RESP_FUNC_COMPLETE;
> + break;
> + }
> +
> + if (task->task_status.resp == SAS_TASK_COMPLETE &&
> + task->task_status.stat == TMF_RESP_FUNC_SUCC) {
> + res = TMF_RESP_FUNC_SUCC;
> + break;
> + }
> +
> + pr_err("Internal abort: task to dev %016llx response: 0x%x status 0x%x\n",
> + SAS_ADDR(device->sas_addr), task->task_status.resp,
> + task->task_status.stat);
> + sas_free_task(task);
> + task = NULL;
> + }
> + BUG_ON(retry == TASK_RETRY && task != NULL);
> + sas_free_task(task);
> + return res;
> +}
> +
> +int sas_execute_internal_abort_single(struct domain_device *device, u16 tag,
> + unsigned int qid, void *data)
> +{
> + return sas_execute_internal_abort(device, SAS_INTERNAL_ABORT_SINGLE,
> + tag, qid, data);
> +}
> +EXPORT_SYMBOL_GPL(sas_execute_internal_abort_single);
> +
> int sas_execute_tmf(struct domain_device *device, void *parameter,
> int para_len, int force_phy_id,
> struct sas_tmf_task *tmf)
> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
> index df2c8fc43429..2d30d57916e5 100644
> --- a/include/scsi/libsas.h
> +++ b/include/scsi/libsas.h
> @@ -557,6 +557,16 @@ struct sas_ata_task {
> int force_phy_id;
> };
>
> +/* LLDDs rely on these values */
> +enum sas_internal_abort {
> + SAS_INTERNAL_ABORT_SINGLE = 0,
> +};
> +
Why don't you use the existing TMF_XXX values here?
Your 'single' method pretty much _is_ a TMF_ABORT_TASK, and the 'device'
method _is_ a TMF_ABORT_TASK_SET, no?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
next prev parent reply other threads:[~2022-04-20 12:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 12:18 [PATCH 0/4] scsi: libsas and users: Factor out internal abort code John Garry
2022-03-03 12:18 ` [PATCH 1/4] scsi: libsas: Add sas_execute_internal_abort_single() John Garry
2022-03-03 16:31 ` Damien Le Moal
2022-03-04 9:33 ` John Garry
2022-04-20 12:21 ` Hannes Reinecke [this message]
2022-04-25 8:27 ` John Garry
2022-04-25 8:34 ` Hannes Reinecke
2022-04-25 8:51 ` John Garry
2022-03-03 12:18 ` [PATCH 2/4] scsi: libsas: Add sas_execute_internal_abort_dev() John Garry
2022-04-20 12:22 ` Hannes Reinecke
2022-03-03 12:18 ` [PATCH 3/4] scsi: pm8001: Use libsas internal abort support John Garry
2022-03-03 16:36 ` Damien Le Moal
2022-03-04 9:41 ` John Garry
2022-03-07 2:47 ` Damien Le Moal
2022-04-20 12:24 ` Hannes Reinecke
2022-03-03 12:18 ` [PATCH 4/4] scsi: hisi_sas: " John Garry
2022-03-03 16:42 ` Damien Le Moal
2022-03-04 9:47 ` John Garry
2022-04-20 12:29 ` Hannes Reinecke
2022-04-25 8:43 ` John Garry
2022-03-03 16:29 ` [PATCH 0/4] scsi: libsas and users: Factor out internal abort code Damien Le Moal
2022-03-03 17:05 ` John Garry
2022-03-07 0:55 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=929aede0-9e58-9c3d-5951-6151a3281edd@suse.de \
--to=hare@suse.de \
--cc=Ajish.Koshy@microchip.com \
--cc=Viswas.G@microchip.com \
--cc=chenxiang66@hisilicon.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=hch@lst.de \
--cc=jejb@linux.ibm.com \
--cc=jinpu.wang@cloud.ionos.com \
--cc=john.garry@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liuqi115@huawei.com \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox