public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Seokmann Ju <seokmann.ju@qlogic.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	James.Smart@Emulex.Com, James.Bottomley@HansenPartnership.com,
	linux-scsi@vger.kernel.org, andrew.vasquez@qlogic.com,
	michaelc@cs.wisc.edu, robert.w.love@intel.com
Subject: Re: [PATCH 1/2] scsi_transport_fc: FC pass through support - revised II
Date: Thu, 30 Oct 2008 16:12:42 +0200	[thread overview]
Message-ID: <4909C0DA.305@panasas.com> (raw)
In-Reply-To: <BDE35A87-59AD-4116-9DB8-F1DFAD40177A@qlogic.com>

Seokmann Ju wrote:
> On Oct 29, 2008, at 9:18 PM, FUJITA Tomonori wrote:
> 
>> On Wed, 29 Oct 2008 05:48:03 -0700
>> Seokmann Ju <seokmann.ju@qlogic.com> wrote:
>>
>>> From f32b386a61a23f408974f2289cd34200f59401e1 Mon Sep 17 00:00:00  
>>> 2001
>>> From: root <root@linux-atl-00.qlogic.com>
>>> Date: Tue, 28 Oct 2008 19:27:15 -0700
>>> Subject: [PATCH] scsi_transport_fc: FC pass through support
>>>
>>> This patch will add FC pass through support.
>>> The FC pass through support is service request handling mechanism
>>> for FC specification defined services including,
>>> - Link Services (Basic LS, Extended LS)
>>> - Generic Services (FC-CT - Common Transport)
>>> The support utilize BSG (Block layer SCSI Generic) interface with
>>> bidi (bi-directional) nature in handling the service requests.
>>>
>>> This patch added following featues in the support
>>> - FC service structure has defined to transport service requests
>>> - Handles the service request in asynchronous manner - LLD
>>> - Timeout capability
>>> - Abort capability
>>>
>>> Signed-off-by: Seokmann Ju <seokmann.ju@qlogic.com>
>>> ---
>>>  drivers/scsi/scsi_transport_fc.c |  216 +++++++++++++++++++++++++++ 
>>> ++
>>> ++++++++-
>>>  include/scsi/scsi_transport_fc.h |   81 ++++++++++++++-
>>>  2 files changed, 294 insertions(+), 3 deletions(-)
>> First, the patch looks corrupt (I can't apply this). I guess that tabs
>> are converted to spaces.
> Sorry, whenever I send patches, it makes me to worry about it... but,
> I'm still struggling to find what causes the problem.
> Sometimes it worked (guessing for shorter ones).
> I will submit the patch along with attachment next time.
> BTW: I use the Mail on my Mac... any comments on this problem would be
> greatly appreciated...
> 
>>> diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/
>>> scsi_transport_fc.c
>>> index 1e71abf..e26e8e0 100644
>>> --- a/drivers/scsi/scsi_transport_fc.c
>>> +++ b/drivers/scsi/scsi_transport_fc.c
<snip>
>>> +
>>> +static void fc_service_done(struct fc_service *service)
>>> +{
>>> +
>>> +	if (service->service_state_flag != FC_SERVICE_STATE_DONE) {
>>> +		if (service->service_state_flag == FC_SERVICE_STATE_TIMEOUT)
>>> +			printk(KERN_ERR "ERROR: FC service timed out\n");
>>> +		else if (service->service_state_flag ==
>>> +		    FC_SERVICE_STATE_ABORTED)
>>> +			printk(KERN_ERR "ERROR: FC service aborted\n");
>>> +		else
>>> +			printk(KERN_ERR "ERROR: FC service not finished\n");
>>> +	}
>>> +
>>> +	if (service->srv_reply.status != FC_SERVICE_COMPLETE) {
>>> +		printk(KERN_ERR "ERROR: FC service to rport %p failed with"
>>> +		    " status 0x%x\n", service->rport,
>>> +		    service->srv_reply.status);
>>> +	}
>>> +
>>> +	service->req->errors = service->srv_reply.status;
>>> +	service->req->next_rq->errors = service->srv_reply.status;
>> We don't need to save service->srv_reply.status at two places
>> service->req is appropriate.
> OK. It is removed.
> 
>>> +	blk_end_bidi_request(service->req, service->srv_reply.status,
>>> +	    blk_rq_bytes(service->req),
>>> +	    service->req->next_rq ? blk_rq_bytes(service->req->next_rq) :  
>>> 0);

>From what James said I understand that you should do:
+	blk_end_bidi_request(service->req, service->req->errors ? -EIO : 0,
+		blk_rq_bytes(service->req),
+		service->req->next_rq ? blk_rq_bytes(service->req->next_rq) : 0);

>>> +
>>> +	kfree(service->payload_dma);
>>> +	kfree(service->response_dma);
>>> +	kfree(service);
>>> +}
>>> +
<snip>

Boaz

  reply	other threads:[~2008-10-30 14:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-29 12:48 [PATCH 1/2] scsi_transport_fc: FC pass through support - revised II Seokmann Ju
2008-10-29 13:12 ` Boaz Harrosh
2008-10-30  4:18 ` FUJITA Tomonori
2008-10-30  7:51   ` Boaz Harrosh
2008-10-30  8:29     ` FUJITA Tomonori
2008-10-30 13:39       ` James Bottomley
2008-10-30 13:37   ` Seokmann Ju
2008-10-30 14:12     ` Boaz Harrosh [this message]
2008-10-30 14:47       ` Seokmann Ju
2008-10-30 23:12     ` FUJITA Tomonori
2008-10-31  1:38     ` Seokmann Ju
2008-10-31  1:57       ` FUJITA Tomonori
2008-10-31  2:57         ` Seokmann Ju

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=4909C0DA.305@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=James.Smart@Emulex.Com \
    --cc=andrew.vasquez@qlogic.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=robert.w.love@intel.com \
    --cc=seokmann.ju@qlogic.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