On 11/13/2014 06:59 PM, Christoph Hellwig wrote:
> James Smart said the userspace to consume these events never emerged.  Given
> that these get in the way of the following patches remove support for them.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> ---
>  drivers/scsi/lpfc/lpfc_scsi.c | 66 
> -------------------------------------------
>  1 file changed, 66 deletions(-)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
> index 8533ee9..80351ff 100644
> --- a/drivers/scsi/lpfc/lpfc_scsi.c
> +++ b/drivers/scsi/lpfc/lpfc_scsi.c
> @@ -243,60 +243,6 @@ lpfc_update_stats(struct lpfc_hba *phba, struct  
> lpfc_scsi_buf *lpfc_cmd)
>  }
>  
>  /**
> - * lpfc_send_sdev_queuedepth_change_event - Posts a queuedepth change event
> - * @phba: Pointer to HBA context object.
> - * @vport: Pointer to vport object.
> - * @ndlp: Pointer to FC node associated with the target.
> - * @lun: Lun number of the scsi device.
> - * @old_val: Old value of the queue depth.
> - * @new_val: New value of the queue depth.
> - *
> - * This function sends an event to the mgmt application indicating
> - * there is a change in the scsi device queue depth.
> - **/
> -static void
> -lpfc_send_sdev_queuedepth_change_event(struct lpfc_hba *phba,
> -             struct lpfc_vport  *vport,
> -             struct lpfc_nodelist *ndlp,
> -             uint64_t lun,
> -             uint32_t old_val,
> -             uint32_t new_val)
> -{
> -     struct lpfc_fast_path_event *fast_path_evt;
> -     unsigned long flags;
> -
> -     fast_path_evt = lpfc_alloc_fast_evt(phba);
> -     if (!fast_path_evt)
> -             return;
> -
> -     fast_path_evt->un.queue_depth_evt.scsi_event.event_type =
> -             FC_REG_SCSI_EVENT;
> -     fast_path_evt->un.queue_depth_evt.scsi_event.subcategory =
> -             LPFC_EVENT_VARQUEDEPTH;
> -
> -     /* Report all luns with change in queue depth */
> -     fast_path_evt->un.queue_depth_evt.scsi_event.lun = lun;
> -     if (ndlp && NLP_CHK_NODE_ACT(ndlp)) {
> -             memcpy(&fast_path_evt->un.queue_depth_evt.scsi_event.wwpn,
> -                     &ndlp->nlp_portname, sizeof(struct lpfc_name));
> -             memcpy(&fast_path_evt->un.queue_depth_evt.scsi_event.wwnn,
> -                     &ndlp->nlp_nodename, sizeof(struct lpfc_name));
> -     }
> -
> -     fast_path_evt->un.queue_depth_evt.oldval = old_val;
> -     fast_path_evt->un.queue_depth_evt.newval = new_val;
> -     fast_path_evt->vport = vport;
> -
> -     fast_path_evt->work_evt.evt = LPFC_EVT_FASTPATH_MGMT_EVT;
> -     spin_lock_irqsave(&phba->hbalock, flags);
> -     list_add_tail(&fast_path_evt->work_evt.evt_listp, &phba->work_list);
> -     spin_unlock_irqrestore(&phba->hbalock, flags);
> -     lpfc_worker_wake_up(phba);
> -
> -     return;
> -}
> -
> -/**
>   * lpfc_change_queue_depth - Alter scsi device queue depth
>   * @sdev: Pointer the scsi device on which to change the queue depth.
>   * @qdepth: New queue depth to set the sdev to.
> @@ -310,11 +256,6 @@ static int
>  lpfc_change_queue_depth(struct scsi_device *sdev, int qdepth, int reason)
>  {
>       struct lpfc_vport *vport = (struct lpfc_vport *) sdev->host->hostdata;
> -     struct lpfc_hba   *phba = vport->phba;
> -     struct lpfc_rport_data *rdata;
> -     unsigned long new_queue_depth, old_queue_depth;
> -
> -     old_queue_depth = sdev->queue_depth;
>  
>       switch (reason) {
>       case SCSI_QDEPTH_DEFAULT:
> @@ -334,13 +275,6 @@ lpfc_change_queue_depth(struct scsi_device *sdev, int 
> qdepth, int reason)
>               return -EOPNOTSUPP;
>       }
>  
> -     new_queue_depth = sdev->queue_depth;
> -     rdata = lpfc_rport_data_from_scsi_device(sdev);
> -     if (rdata)
> -             lpfc_send_sdev_queuedepth_change_event(phba, vport,
> -                                                    rdata->pnode, sdev->lun,
> -                                                    old_queue_depth,
> -                                                    new_queue_depth);
>       return sdev->queue_depth;
>  }
>  
> 
You definitely need to get an ACK from James Smart for this.
There's a good possibility that there are some Emulex management
software which makes use of this event...

Otherwise:

Reviewed-by: Hannes Reinecke <h...@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                   zSeries & Storage
h...@suse.de                          +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, 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

Reply via email to