All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Milburn <dmilburn@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: james.bottomley@suse.de, dave.jiang@intel.com,
	linux-scsi@vger.kernel.org, jacek.danecki@intel.com,
	ed.ciechanowski@intel.com, jeffrey.d.skirvin@intel.com,
	edmund.nadolski@intel.com
Subject: Re: [RFC PATCH 2/6] isci: task (libsas interface support)
Date: Wed, 16 Feb 2011 12:48:20 -0600	[thread overview]
Message-ID: <4D5C1BF4.2050100@redhat.com> (raw)
In-Reply-To: <AANLkTinfhEO2uXW94S9q++D8dNjBpOy1_3s64X=ScbLY@mail.gmail.com>

Dan Williams wrote:
> Thanks David, comments below.
> 
>>> +       if (task->task_state_flags & SAS_TASK_STATE_ABORTED) {
>>> +
>>> +               isci_task_complete_for_upper_layer(
>>> +                       task,
>>> +                       SAS_TASK_UNDELIVERED,
>>> +                       SAM_STAT_TASK_ABORTED,
>>> +                       isci_perform_normal_io_completion
>>> +                       );
>>> +
>>> +               return 0;  /* The I/O was accepted (and failed). */
>> Dan, is this the right status to return to libsas?
>>
>> Looks like it checks (->lldd_execute_task) for non-zero result.
> 
> I think this is self defense that can be deleted, how can a task be
> aborted before it has even returned from the submission routine.
> 
>>> +       }
>>> +       if ((task->dev == NULL) || (task->dev->port == NULL)) {
>>> +
>>> +               /* Indicate SAS_TASK_UNDELIVERED, so that the scsi
>>> midlayer
>>> +                * removes the target.
>>> +                */
>>> +               isci_task_complete_for_upper_layer(
>>> +                       task,
>>> +                       SAS_TASK_UNDELIVERED,
>>> +                       SAS_DEVICE_UNKNOWN,
>>> +                       isci_perform_normal_io_completion
>>> +                       );
>>> +               return 0;  /* The I/O was accepted (and failed). */
>> Same here?
> 
> Yeah, we should always be able to dereference task->dev because ->dev
> is referenced counted against outstanding commands.  If we have a task
> by definition we have a dev.
> 
> [..]
>>> +        */
>>> +       isci_task_build_tmf(&tmf, isci_device, isci_tmf_ssp_lun_reset,
>>> NULL,
>>> +                           NULL);
>>> +
>>> +       #define ISCI_LU_RESET_TIMEOUT_MS 2000 /* 2 second timeout. */
>> Maybe move #define to isci_task.h?
> 
> Ok.
> 
>>> +       ret = isci_task_execute_tmf(isci_host, &tmf,
>>> ISCI_LU_RESET_TIMEOUT_MS);
>>> +
>>> +       if (ret == TMF_RESP_FUNC_COMPLETE)
>>> +               dev_dbg(&isci_host->pdev->dev,
>>> +                       "%s: %p: TMF_LU_RESET passed\n",
>>> +                       __func__, isci_device);
>>> +       else
>>> +               dev_dbg(&isci_host->pdev->dev,
>>> +                       "%s: %p: TMF_LU_RESET failed (%x)\n",
>>> +                       __func__, isci_device, ret);
>>> +
>>> +       return ret;
>>> +}
>>> +
>>> +/**
>>> +
>>> +/*      int (*lldd_clear_nexus_port)(struct asd_sas_port *); */
>>> +int isci_task_clear_nexus_port(struct asd_sas_port *port)
>>> +{
>>> +       return TMF_RESP_FUNC_FAILED;
>>> +}
>>> +
>>> +
>>> +
>>> +int isci_task_clear_nexus_ha(struct sas_ha_struct *ha)
>>> +{
>>> +       return TMF_RESP_FUNC_FAILED;
>>> +}
>>> +
>>> +int isci_task_I_T_nexus_reset(struct domain_device *dev)
>>> +{
>>> +       return TMF_RESP_FUNC_FAILED;
>>> +}
>>> +
>> These will be used during libsas error handling.
> 
> The driver implements abort_task, and promotes the rest to lu_reset.
> Assuming the documentation is not out of date:
> 
>      A SAS LLDD should also implement at least one of the Task
>      Management Functions (TMFs) described in SAM:
> 
> ...how urgent is the need for these other task management routines?

Dan,

Looks like some of these will be used down the scsi error handling
path

scsi_error_handler
  eh_strategy_handler (sas_scsi_recover_host)
   sas_eh_handle_sas_errors

For some of these you may be able to build and execute, something
like

isci_task_abort_task()
{
	isci_task_build_tmf(TMF_ABORT_TASK)
	isci_task_execute_tmf()
}


Also, looks like other libsas drivers do a phy reset from 
lldd_I_T_nexus_reset,
probably ok to eliminate lldd_clear_aca for now.

> 
> Speaking of mandatory libsas methods all other libsas drivers outside
> of aic94xx forgo implementing
> 
>              /* Port and Adapter management */
>              int (*lldd_clear_nexus_port)(struct sas_port *);
>              int (*lldd_clear_nexus_ha)(struct sas_ha_struct *);
> 
>      A SAS LLDD should implement at least one of those.
> 
> ...not clear that at least one of those is mandatory.
> 

Yes, good point, probably ok to initially eliminate these.

Thanks,
David


>>
>>> +/**
>>> + * isci_task_abort_task() - This function is one of the SAS Domain
>>> Template
>>> + *    functions. This function is called by libsas to abort a specified
>>> task.
>>> + * @task: This parameter specifies the SAS task to abort.
>>> + *
>>> + * status, zero indicates success.
>>> + */
>>> +int isci_task_abort_task(struct sas_task *task)
>>> +{
>> scic_lock, flags);
>>
>>
>>> +
>>> +               #define ISCI_ABORT_TASK_TIMEOUT_MS 500 /* half second
>>> timeout. */
>> Maybe move this #define to isci_task.h?
> 
> Ok.
> 
> [..]
>>> + * isci_task_abort_task_set() - This function is one of the SAS Domain
>>> Template
>>> + *    functions. This is one of the Task Management functoins called by
>>> libsas,
>>> + *    to abort all task for the given lun.
>>> + * @d_device: This parameter specifies the domain device associated with
>>> this
>>> + *    request.
>>> + * @lun: This parameter specifies the lun associated with this request.
>>> + *
>>> + * status, zero indicates success.
>>> + */
>>> +int isci_task_abort_task_set(
>>> +       struct domain_device *d_device,
>>> +       u8 *lun)
>>> +{
>>> +       return TMF_RESP_FUNC_FAILED;
>>> +}
>>> +
>>> +
>>> +/**
>>> + * isci_task_clear_aca() - This function is one of the SAS Domain
>>> Template
>>> + *    functions. This is one of the Task Management functoins called by
>>> libsas.
>>> + * @d_device: This parameter specifies the domain device associated with
>>> this
>>> + *    request.
>>> + * @lun: This parameter specifies the lun       associated with this
>>> request.
>>> + *
>>> + * status, zero indicates success.
>>> + */
>>> +int isci_task_clear_aca(
>>> +       struct domain_device *d_device,
>>> +       u8 *lun)
>>> +{
>>> +       return TMF_RESP_FUNC_FAILED;
>>> +}
>>> +
>>> +
>>> +
>>> +/**
>>> + * isci_task_clear_task_set() - This function is one of the SAS Domain
>>> Template
>>> + *    functions. This is one of the Task Management functoins called by
>>> libsas.
>>> + * @d_device: This parameter specifies the domain device associated with
>>> this
>>> + *    request.
>>> + * @lun: This parameter specifies the lun       associated with this
>>> request.
>>> + *
>>> + * status, zero indicates success.
>>> + */
>>> +int isci_task_clear_task_set(
>>> +       struct domain_device *d_device,
>>> +       u8 *lun)
>>> +{
>>> +       return TMF_RESP_FUNC_FAILED;
>>> +}
>> More libsas error recovery functions.
> 
> Same comment as above the driver has the little and the big recovery
> hammers, the medium hammers can be prioritized behind other fixes I
> think.
> 
> --
> Dan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2011-02-16 18:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07  0:34 [RFC PATCH 0/6] isci: initial driver release (part1: intro and lldd) Dan Williams
2011-02-07  0:34 ` [RFC PATCH 1/6] isci: initialization Dan Williams
2011-02-17  8:22   ` Jeff Garzik
2011-02-19  0:12     ` Dan Williams
2011-02-17  8:25   ` Christoph Hellwig
2011-02-19  0:23     ` Dan Williams
2011-03-04 23:35   ` James Bottomley
2011-03-08  1:51     ` Dan Williams
2011-03-18 16:51   ` Christoph Hellwig
2011-02-07  0:34 ` [RFC PATCH 2/6] isci: task (libsas interface support) Dan Williams
2011-02-09 15:01   ` David Milburn
2011-02-14  7:14     ` Dan Williams
2011-02-16 18:48       ` David Milburn [this message]
2011-02-16 19:35         ` David Milburn
2011-02-07  0:34 ` [RFC PATCH 3/6] isci: request (core request infrastructure) Dan Williams
2011-03-18 16:41   ` Christoph Hellwig
2011-02-07  0:34 ` [RFC PATCH 4/6] isci: hardware / topology event handling Dan Williams
2011-03-18 16:18   ` Christoph Hellwig
2011-03-23  8:15     ` Dan Williams
2011-03-23  8:40       ` Christoph Hellwig
2011-03-23  9:04         ` Dan Williams
2011-03-23  9:08           ` Christoph Hellwig
2011-03-24  0:07             ` Dan Williams
2011-03-24  6:26               ` Christoph Hellwig
2011-03-25  0:57                 ` Dan Williams
2011-03-25 19:45                   ` Christoph Hellwig
2011-03-25 21:39                     ` Dan Williams
2011-03-25 22:07                       ` Christoph Hellwig
2011-03-25 22:34                         ` Dan Williams
2011-03-27 22:28                           ` Christoph Hellwig
2011-03-29  1:11                             ` Dan Williams
2011-03-30  0:37                               ` Dan Williams
2011-02-07  0:35 ` [RFC PATCH 5/6] isci: phy, port, and remote device Dan Williams
2011-02-07  0:35 ` [RFC PATCH 6/6] isci: sata support and phy settings via request_firmware() Dan Williams
2011-02-07  7:58 ` [RFC PATCH 1/6] isci: initialization jack_wang
2011-02-14  7:49   ` Dan Williams

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=4D5C1BF4.2050100@redhat.com \
    --to=dmilburn@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ed.ciechanowski@intel.com \
    --cc=edmund.nadolski@intel.com \
    --cc=jacek.danecki@intel.com \
    --cc=james.bottomley@suse.de \
    --cc=jeffrey.d.skirvin@intel.com \
    --cc=linux-scsi@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.