[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d938ff8d-caaf-9221-e598-62e7e04aa907@opensource.wdc.com>
Date: Thu, 29 Sep 2022 16:56:28 +0900
From: Damien Le Moal <damien.lemoal@...nsource.wdc.com>
To: John Garry <john.garry@...wei.com>, jejb@...ux.ibm.com,
martin.petersen@...cle.com, jinpu.wang@...ud.ionos.com,
damien.lemoal@....com
Cc: hare@...e.de, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, linuxarm@...wei.com,
ipylypiv@...gle.com, changyuanl@...gle.com, hch@....de
Subject: Re: [PATCH 1/6] scsi: libsas: Add sas_task_find_rq()
On 9/29/22 16:33, John Garry wrote:
> On 29/09/2022 03:09, Damien Le Moal wrote:
>> On 9/28/22 21:27, John Garry wrote:
>>> blk-mq already provides a unique tag per request. Some libsas LLDDs - like
>>> hisi_sas - already use this tag as the unique per-IO HW tag.
>>>
>>> Add a common function to provide the request associated with a sas_task
>>> for all libsas LLDDs.
>>>
>>> Signed-off-by: John Garry <john.garry@...wei.com>
>>> ---
>>> include/scsi/libsas.h | 22 ++++++++++++++++++++++
>>> 1 file changed, 22 insertions(+)
>>>
>>> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
>>> index f86b56bf7833..bc51756a3317 100644
>>> --- a/include/scsi/libsas.h
>>> +++ b/include/scsi/libsas.h
>>> @@ -644,6 +644,28 @@ static inline bool sas_is_internal_abort(struct sas_task *task)
>>> return task->task_proto == SAS_PROTOCOL_INTERNAL_ABORT;
>>> }
>>>
>>> +static inline struct request *sas_task_find_rq(struct sas_task *task)
>>> +{
>>> + struct scsi_cmnd *scmd;
>>> +
>>> + if (!task || !task->uldd_task)
>>> + return NULL;
>>> +
>>> + if (task->task_proto & SAS_PROTOCOL_STP_ALL) {
>>> + struct ata_queued_cmd *qc;
>>> +
>>> + qc = task->uldd_task;
>>
>> I would change these 2 lines into a single line:
>>
>> struct ata_queued_cmd *qc = task->uldd_task;
>>
>> And no cast as suggested.
>>
>>> + scmd = qc->scsicmd;
>
> So do you prefer:
>
> scmd = ((struct ata_queued_cmd *)task->uldd_task)->scsicmd
Not a fan of the cast approach suggested by Jason. I prefer my above
suggestion, but no strong feeling about it. Either way will be OK.
>
> As Jason suggested?
>
> Thanks,
> John
--
Damien Le Moal
Western Digital Research
Powered by blists - more mailing lists