Re: [PATCH 13/28] megaraid_sas: switch to generic DMA API

2018-10-16 Thread Sumit Saxena
 instance->vf_affiliation_111 =
> -   pci_alloc_consistent(pdev, sizeof(struct 
> MR_LD_VF_AFFILIATION_111),
> -
> >vf_affiliation_111_h);
> +   dma_alloc_coherent(>dev,
> +   sizeof(struct 
> MR_LD_VF_AFFILIATION_111),
> +   >vf_affiliation_111_h,
> +   GFP_KERNEL);
> if (!instance->vf_affiliation_111)
> dev_warn(>dev, "Can't allocate "
>"memory for VF affiliation buffer\n");
> } else {
> instance->vf_affiliation =
> -   pci_alloc_consistent(pdev,
> -(MAX_LOGICAL_DRIVES + 1) 
> *
> -sizeof(struct 
> MR_LD_VF_AFFILIATION),
> -
> >vf_affiliation_h);
> +   dma_alloc_coherent(>dev,
> +   (MAX_LOGICAL_DRIVES + 1) *
> +   sizeof(struct MR_LD_VF_AFFILIATION),
> +   >vf_affiliation_h,
> +   GFP_KERNEL);
> if (!instance->vf_affiliation)
> dev_warn(>dev, "Can't allocate "
>"memory for VF affiliation buffer\n");
> @@ -6994,19 +6994,19 @@ static void megasas_detach_one(struct pci_dev *pdev)
> }
>
> if (instance->vf_affiliation)
> -   pci_free_consistent(pdev, (MAX_LOGICAL_DRIVES + 1) *
> +   dma_free_coherent(>dev, (MAX_LOGICAL_DRIVES + 1) *
> sizeof(struct MR_LD_VF_AFFILIATION),
> instance->vf_affiliation,
> instance->vf_affiliation_h);
>
> if (instance->vf_affiliation_111)
> -   pci_free_consistent(pdev,
> +   dma_free_coherent(>dev,
> sizeof(struct MR_LD_VF_AFFILIATION_111),
> instance->vf_affiliation_111,
> instance->vf_affiliation_111_h);
>
> if (instance->hb_host_mem)
> -   pci_free_consistent(pdev, sizeof(struct MR_CTRL_HB_HOST_MEM),
> +   dma_free_coherent(>dev, sizeof(struct 
> MR_CTRL_HB_HOST_MEM),
> instance->hb_host_mem,
> instance->hb_host_mem_h);
>
> @@ -7254,7 +7254,7 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
>
> /*
>  * We don't change the dma_coherent_mask, so
> -* pci_alloc_consistent only returns 32bit addresses
> +* dma_alloc_coherent only returns 32bit addresses
>  */
> if (instance->consistent_mask_64bit) {
> kern_sge64[i].phys_addr = cpu_to_le64(buf_handle);
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index c7f95bace353..f74b5ea24f0f 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -684,8 +684,8 @@ megasas_alloc_rdpq_fusion(struct megasas_instance 
> *instance)
> array_size = sizeof(struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY) *
>  MAX_MSIX_QUEUES_FUSION;
>
> -   fusion->rdpq_virt = pci_zalloc_consistent(instance->pdev, array_size,
> - >rdpq_phys);
> +   fusion->rdpq_virt = dma_zalloc_coherent(>pdev->dev,
> +   array_size, >rdpq_phys, GFP_KERNEL);
> if (!fusion->rdpq_virt) {
> dev_err(>pdev->dev,
> "Failed from %s %d\n",  __func__, __LINE__);
> @@ -813,7 +813,7 @@ megasas_free_rdpq_fusion(struct megasas_instance 
> *instance) {
> dma_pool_destroy(fusion->reply_frames_desc_pool_align);
>
> if (fusion->rdpq_virt)
> -   pci_free_consistent(instance->pdev,
> +   dma_free_coherent(>pdev->dev,
> sizeof(struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY) * 
> MAX_MSIX_QUEUES_FUSION,
> fusion->rdpq_virt, fusion->rdpq_phys);
>  }
> @@ -2209,7 +2209,7 @@ megasas_set_pd_lba(struct MPI2_RAID_SCSI_IO_REQUEST 
> *io_request, u8 cdb_len,
> cdb[0] =  MEGASAS_SCSI_VARIABLE_LENGTH_CMD;
> cdb[7] =  MEGASAS_SCSI_ADDL_CDB_LEN;
>
> -   if (scp->sc_data_direction == PCI_DMA_FROMDEVICE)
> +   if (scp->sc_data_direction == DMA_FROM_DEVICE)
> cdb[9] = MEGASAS_SCSI_SERVICE_ACTION_READ32;
> else
> cdb[9] = MEGASAS_SCSI_SERVICE_ACTION_WRITE32;
> @@ -2238,7 +2238,7 @@ megasas_set_pd_lba(struct MPI2_RAID_SCSI_IO_REQUEST 
> *io_request, u8 cdb_len,
> cdb[31] = (u8)(num_blocks & 0xff);
>
> /* set SCSI IO EEDPFlags */
> -   if (scp->sc_data_direction == PCI_DMA_FROMDEVICE) {
> +   if (scp->sc_data_direction == DMA_FROM_DEVICE) {
> io_request->EEDPFlags = cpu_to_le16(
> MPI2_SCSIIO_EEDPFLAGS_INC_PRI_REFTAG  |
> MPI2_SCSIIO_EEDPFLAGS_CHECK_REFTAG |
> @@ -2621,7 +2621,7 @@ megasas_build_ldio_fusion(struct megasas_instance 
> *instance,
> scsi_buff_len = scsi_bufflen(scp);
> io_request->DataLength = cpu_to_le32(scsi_buff_len);
>
> -   if (scp->sc_data_direction == PCI_DMA_FROMDEVICE)
> +   if (scp->sc_data_direction == DMA_FROM_DEVICE)
> io_info.isRead = 1;
>
> local_map_ptr = fusion->ld_drv_map[(instance->map_id & 1)];
> @@ -3088,9 +3088,9 @@ megasas_build_io_fusion(struct megasas_instance 
> *instance,
>
> io_request->SGLFlags = cpu_to_le16(MPI2_SGE_FLAGS_64_BIT_ADDRESSING);
>
> -   if (scp->sc_data_direction == PCI_DMA_TODEVICE)
> +   if (scp->sc_data_direction == DMA_TO_DEVICE)
> io_request->Control |= cpu_to_le32(MPI2_SCSIIO_CONTROL_WRITE);
> -   else if (scp->sc_data_direction == PCI_DMA_FROMDEVICE)
> +   else if (scp->sc_data_direction == DMA_FROM_DEVICE)
> io_request->Control |= cpu_to_le32(MPI2_SCSIIO_CONTROL_READ);
>
> io_request->SGLOffset0 =

Acked-by: Sumit Saxena 

> --
> 2.19.1
>


RE: [PATCH] scsi: megaraid: Use dma_pool_zalloc()

2018-03-06 Thread Sumit Saxena
-Original Message-
From: Souptick Joarder [mailto:jrdr.li...@gmail.com]
Sent: Thursday, February 15, 2018 9:55 PM
To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
shivasharan.srikanteshw...@broadcom.com
Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org
Subject: [PATCH] scsi: megaraid: Use dma_pool_zalloc()

Use dma_pool_zalloc() instead of dma_pool_alloc + memset

Signed-off-by: Souptick Joarder <jrdr.li...@gmail.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index a71ee67..905ea36 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4022,7 +4022,7 @@ static int megasas_create_frame_pool(struct
megasas_instance *instance)

cmd = instance->cmd_list[i];

-   cmd->frame = dma_pool_alloc(instance->frame_dma_pool,
+   cmd->frame = dma_pool_zalloc(instance->frame_dma_pool,
GFP_KERNEL,
>frame_phys_addr);

cmd->sense = dma_pool_alloc(instance->sense_dma_pool,
@@ -4038,7 +4038,6 @@ static int megasas_create_frame_pool(struct
megasas_instance *instance)
return -ENOMEM;
}

-   memset(cmd->frame, 0, instance->mfi_frame_size);
cmd->frame->io.context = cpu_to_le32(cmd->index);
cmd->frame->io.pad_0 = 0;
if ((instance->adapter_type == MFI_SERIES) &&
reset_devices)

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

--
1.9.1


RE: [PATCH] scsi: megaraid: Convert timers to use timer_setup()

2017-10-31 Thread Sumit Saxena
-Original Message-
From: Kees Cook [mailto:keesc...@chromium.org]
Sent: Wednesday, October 25, 2017 3:37 PM
To: Martin K. Petersen
Cc: Kashyap Desai; Sumit Saxena; Shivasharan S; James E.J. Bottomley;
megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org;
linux-ker...@vger.kernel.org
Subject: [PATCH] scsi: megaraid: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer
to all timer callbacks, switch to using the new timer_setup() and
from_timer() to pass the timer pointer explicitly. Also consolidates the
timer setup functions arguments, which are all identical, and corrects
on-stack timer usage.

Cc: Kashyap Desai <kashyap.de...@broadcom.com>
Cc: Sumit Saxena <sumit.sax...@broadcom.com>
Cc: Shivasharan S <shivasharan.srikanteshw...@broadcom.com>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: megaraidlinux@broadcom.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
 drivers/scsi/megaraid/megaraid_ioctl.h  |  6 +
 drivers/scsi/megaraid/megaraid_mbox.c   | 26 ++---
 drivers/scsi/megaraid/megaraid_mm.c | 27 +++---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 35
+++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 15 +++--
 5 files changed, 47 insertions(+), 62 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_ioctl.h
b/drivers/scsi/megaraid/megaraid_ioctl.h
index 05f6e4ec3453..eedcbde46459 100644
--- a/drivers/scsi/megaraid/megaraid_ioctl.h
+++ b/drivers/scsi/megaraid/megaraid_ioctl.h
@@ -19,6 +19,7 @@

 #include 
 #include 
+#include 

 #include "mbox_defs.h"

@@ -153,6 +154,11 @@ typedef struct uioc {

 } __attribute__ ((aligned(1024),packed)) uioc_t;

+/* For on-stack uioc timers. */
+struct uioc_timeout {
+   struct timer_list timer;
+   uioc_t*uioc;
+};

 /**
  * struct mraid_hba_info - information about the controller diff --git
a/drivers/scsi/megaraid/megaraid_mbox.c
b/drivers/scsi/megaraid/megaraid_mbox.c
index ec3c43854978..530358cdcb39 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -3904,19 +3904,19 @@ megaraid_sysfs_get_ldmap_done(uioc_t *uioc)
wake_up(_dev->sysfs_wait_q);
 }

-
 /**
  * megaraid_sysfs_get_ldmap_timeout - timeout handling for get ldmap
- * @data   : timed out packet
+ * @t  : timed out timer
  *
  * Timeout routine to recover and return to application, in case the
adapter
  * has stopped responding. A timeout of 60 seconds for this command seems
like
  * a good value.
  */
 static void
-megaraid_sysfs_get_ldmap_timeout(unsigned long data)
+megaraid_sysfs_get_ldmap_timeout(struct timer_list *t)
 {
-   uioc_t  *uioc = (uioc_t *)data;
+   struct uioc_timeout *timeout = from_timer(timeout, t, timer);
+   uioc_t  *uioc = timeout->uioc;
adapter_t   *adapter = (adapter_t *)uioc->buf_vaddr;
mraid_device_t  *raid_dev = ADAP2RAIDDEV(adapter);

@@ -3951,8 +3951,7 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter)
mbox64_t*mbox64;
mbox_t  *mbox;
char*raw_mbox;
-   struct timer_list   sysfs_timer;
-   struct timer_list   *timerp;
+   struct uioc_timeout timeout;
caddr_t ldmap;
int rval = 0;

@@ -3988,14 +3987,12 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter)
/*
 * Setup a timer to recover from a non-responding controller
 */
-   timerp  = _timer;
-   init_timer(timerp);
-
-   timerp->function= megaraid_sysfs_get_ldmap_timeout;
-   timerp->data= (unsigned long)uioc;
-   timerp->expires = jiffies + 60 * HZ;
+   timeout.uioc = uioc;
+   timer_setup_on_stack(,
+megaraid_sysfs_get_ldmap_timeout, 0);

Kees,
Does calling "timer_setup_on_stack" instead of "timer_setup" intentional ?
If yes, please help me understand the reason.
Otherwise changes look good to me.

-   add_timer(timerp);
+   timeout.timer.expires   = jiffies + 60 * HZ;
+   add_timer();

/*
 * Send the command to the firmware
@@ -4033,7 +4030,8 @@ megaraid_sysfs_get_ldmap(adapter_t *adapter)
}


-   del_timer_sync(timerp);
+   del_timer_sync();
+   destroy_timer_on_stack();

mutex_unlock(_dev->sysfs_mtx);

diff --git a/drivers/scsi/megaraid/megaraid_mm.c
b/drivers/scsi/megaraid/megaraid_mm.c
index 65b6f6ace3a5..bb802b0c12b8 100644
--- a/drivers/scsi/megaraid/megaraid_mm.c
+++ b/drivers/scsi/megaraid/megaraid_mm.c
@@ -35,7 +35,7 @@ static int kioc_to_mimd(uioc_t *, mimd_t __user *);
static int handle_drvrcmd(void __user *, ui

RE: [PATCH 1/2] scsi: megaraid: Remove redundant code in megasas_alloc_cmds

2017-10-31 Thread Sumit Saxena
-Original Message-
From: Yisheng Xie [mailto:xieyishe...@huawei.com]
Sent: Wednesday, October 25, 2017 3:27 PM
To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org;
linux-ker...@vger.kernel.org; Yisheng Xie
Subject: [PATCH 1/2] scsi: megaraid: Remove redundant code in
megasas_alloc_cmds

megasas_alloc_cmds is to alloc cmd_list of instance instead of fusion, and
fusion is useless in this function. Just remove it.

Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index e518dad..0640168 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4033,9 +4033,7 @@ int megasas_alloc_cmds(struct megasas_instance
*instance)
int j;
u16 max_cmd;
struct megasas_cmd *cmd;
-   struct fusion_context *fusion;

-   fusion = instance->ctrl_context;
max_cmd = instance->max_mfi_cmds;

/*
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

--
1.7.12.4


RE: [PATCH] megaraid: kmemleak: Track page allocation for fusion

2017-09-14 Thread Sumit Saxena
-Original Message-
From: shuw...@redhat.com [mailto:shuw...@redhat.com]
Sent: Thursday, September 14, 2017 11:47 AM
To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org;
linux-ker...@vger.kernel.org; catalin.mari...@arm.com; liw...@redhat.com;
ch...@redhat.com; Shu Wang
Subject: [PATCH] megaraid: kmemleak: Track page allocation for fusion

From: Shu Wang <shuw...@redhat.com>

Kmemleak reports about a thousand false positives for fusion-> cmd_list[].
Root casue is the cmd_list objects are allocated from slab allocator, and
stored its pointer in object allocated by page allocator. The fix will
tell kmemleak to track and scan fusion object.

Before patch:
kmemleak: 1004 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

unreferenced object 0x88042584e000 (size 8192):
  backtrace:
 kmemleak_alloc+0x4a/0xa0
 __kmalloc+0xec/0x220
 megasas_alloc_cmdlist_fusion+0x3e/0x140 [megaraid_sas]
 megasas_alloc_cmds_fusion+0x44/0x450 [megaraid_sas]
 megasas_init_adapter_fusion+0x21d/0x6e0 [megaraid_sas]
 megasas_init_fw+0x357/0xd30 [megaraid_sas]
 megasas_probe_one.part.34+0x5be/0x1040 [megaraid_sas]
 megasas_probe_one+0x46/0xc0 [megaraid_sas]
 local_pci_probe+0x45/0xa0
 work_for_cpu_fn+0x14/0x20
 process_one_work+0x149/0x360
 worker_thread+0x1d8/0x3c0
 kthread+0x109/0x140
 ret_from_fork+0x25/0x30

Signed-off-by: Shu Wang <shuw...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 11bd2e698b84..621299edd8de 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -4512,7 +4513,9 @@ megasas_alloc_fusion_context(struct megasas_instance
*instance)
dev_err(>pdev->dev, "Failed from %s
%d\n", __func__, __LINE__);
return -ENOMEM;
}
-   }
+   } else
+   kmemleak_alloc(instance->ctrl_context,
+   sizeof(struct fusion_context), 1, GFP_KERNEL);

fusion = instance->ctrl_context;

@@ -4548,9 +4551,11 @@ megasas_free_fusion_context(struct megasas_instance
*instance)

if (is_vmalloc_addr(fusion))
vfree(fusion);
-   else
+   else {
free_pages((ulong)fusion,
instance->ctrl_context_pages);
+   kmemleak_free(fusion);
+   }
}
 }
Looks good. Thanks for catching this.

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

--
2.13.5


RE: [PATCH] megaraid_sas: boot hangs while LD is offline

2017-08-16 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Tuesday, August 15, 2017 5:29 PM
>To: Martin K. Petersen
>Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; Kashyap Desai;
>megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; Hannes
>Reinecke; Hannes Reinecke
>Subject: [PATCH] megaraid_sas: boot hangs while LD is offline
>
>Offline Logical drives (LDs) should not allowed to be visible to the OS,
as the
>OS will hang trying to send commands to it.
>This patch skips offline LDs like it already does for non-system physical
drives
>(PDs).

Hi Hannes,

You have submitted this patch in past as it was part of SLES kernel but
missing in upstream and it was concluded to drop this patch then.
This issue was fixed in firmware 4 years back and many firmware versions
should be available with the fix so this fix is not required in
driver(upstream
as well SLES kernel). Do you see any functional issue without this patch ?
If not, I would request  to back out this patch from SLES kernel also.

Thanks,
Sumit

>
>Signed-off-by: Hannes Reinecke <h...@suse.com>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index 5202c2f..39b08fc 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -1897,14 +1897,19 @@ static void
>megasas_set_static_target_properties(struct scsi_device *sdev,
>
> static int megasas_slave_configure(struct scsi_device *sdev)  {
>-  u16 pd_index = 0;
>+  u16 pd_index = 0, ld_index;
>   struct megasas_instance *instance;
>   int ret_target_prop = DCMD_FAILED;
>   bool is_target_prop = false;
>
>   instance = megasas_lookup_instance(sdev->host->host_no);
>   if (instance->pd_list_not_supported) {
>-  if (!MEGASAS_IS_LOGICAL(sdev) && sdev->type ==
>TYPE_DISK) {
>+  if (MEGASAS_IS_LOGICAL(sdev)) {
>+  ld_index = ((sdev->channel -
>MEGASAS_MAX_PD_CHANNELS) *
>+  MEGASAS_MAX_DEV_PER_CHANNEL) +
>sdev->id;
>+  if (instance->ld_ids[ld_index] == 0xff)
>+  return -ENXIO;
>+  } else if (sdev->type == TYPE_DISK) {
>   pd_index = (sdev->channel *
>MEGASAS_MAX_DEV_PER_CHANNEL) +
>   sdev->id;
>   if (instance->pd_list[pd_index].driveState !=
>--
>1.8.5.6


RE: [PATCH] megaraid_sas: Fallback to older scanning if no disks are found

2017-08-16 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Tuesday, August 15, 2017 5:36 PM
>To: Martin K. Petersen
>Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; Kashyap Desai;
>megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; Hannes
>Reinecke
>Subject: [PATCH] megaraid_sas: Fallback to older scanning if no disks are
>found
>
>commit 21c9e160a51383d4cb0b882398534b0c95c0cc3b implemented a new
>driver lookup using the MR_DCMD_LD_LIST_QUERY firmware command.
>However, this command might not work properly on older firmware, causing
>the command to return no drives instead of an error.
>This causes a regression on older firmware as the driver will no longer
detect
>any drives.
>This patch checks if MR_DCMD_LD_LIST_QUERY return no drives, and falls
>back to the original method if so.
>
>Signed-off-by: Hannes Reinecke <h...@suse.de>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 29
>+++--
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index 39b08fc..a1cf2c3 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -4502,7 +4502,6 @@ int megasas_alloc_cmds(struct megasas_instance
>*instance)
>   dev_info(>pdev->dev,
>   "DCMD not supported by firmware - %s %d\n",
>   __func__, __LINE__);
>-  ret = megasas_get_ld_list(instance);
>   break;
>   case DCMD_TIMEOUT:
>   switch (dcmd_timeout_ocr_possible(instance)) { @@ -4530,6
>+4529,14 @@ int megasas_alloc_cmds(struct megasas_instance *instance)
>   break;
>   case DCMD_SUCCESS:
>   tgtid_count = le32_to_cpu(ci->count);
>+  /*
>+   * Some older firmware return '0' if the LD LIST QUERY
>+   * command is not supported.
>+   */
>+  if (tgtid_count == 0) {
>+  ret = DCMD_FAILED;
>+  break;
>+  }

If firmware does not support LD_LIST_QUERY,  "DCMD_FAILED" should be
returned by megasas_issue_blocked_cmd
(function which fires command to firmware) instead of DCMD_SCCESS.
Can you please help with older firmware version which returns
DCMD_SUCCESS(0) if LD_LIST_QUERY is not supported ?

"tgtid_count" may be zero(in case of no logical disks configured) even
when firmware supports LD LIST QUERY
and in that case also driver will fire old command by calling
megasas_get_ld_list() but that's not a problem.

Thanks,
Sumit

>
>   if ((tgtid_count > (instance->fw_supported_vd_count)))
>   break;
>@@ -5146,7 +5153,7 @@ static int megasas_init_fw(struct megasas_instance
>*instance)
>   struct megasas_register_set __iomem *reg_set;
>   struct megasas_ctrl_info *ctrl_info = NULL;
>   unsigned long bar_list;
>-  int i, j, loop, fw_msix_count = 0;
>+  int i, j, loop, fw_msix_count = 0, ret;
>   struct IOV_111 *iovPtr;
>   struct fusion_context *fusion;
>
>@@ -5384,8 +5391,11 @@ static int megasas_init_fw(struct megasas_instance
>*instance)
>   }
>   }
>
>-  if (megasas_ld_list_query(instance,
>-MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
>+  ret = megasas_ld_list_query(instance,
>+  MR_LD_QUERY_TYPE_EXPOSED_TO_HOST);
>+  if (ret == DCMD_FAILED)
>+  ret = megasas_get_ld_list(instance);
>+  if (ret)
>   goto fail_get_ld_pd_list;
>
>   /*
>@@ -7426,8 +7436,12 @@ static inline void
>megasas_remove_scsi_device(struct scsi_device *sdev)
>   case MR_EVT_LD_DELETED:
>   case MR_EVT_LD_CREATED:
>   if (!instance->requestorId ||
>-  (instance->requestorId &&
>megasas_get_ld_vf_affiliation(instance, 0)))
>+  (instance->requestorId &&
>+   megasas_get_ld_vf_affiliation(instance, 0)))
{
>   dcmd_ret = megasas_ld_list_query(instance,
>MR_LD_QUERY_TYPE_EXPOSED_TO_HOST);
>+  if (dcmd_ret == DCMD_FAILED)
>+  dcmd_ret =
>megasas_get_ld_list(instance);
>+  }
>
>   if (dcmd_ret == DCMD_SUCCESS)
>   doscan = SCAN_VD_CHANNEL;
>@@ -7443,8 +7457,11 @@ static inline void
>megasas_remove_scsi_device(struct scsi_device *sdev)
&g

RE: [PATCH v2] scsi: megaraid_sas: fix allocate instance->pd_info twice

2017-08-08 Thread Sumit Saxena
>-Original Message-
>From: weiping zhang [mailto:zhangweip...@didichuxing.com]
>Sent: Tuesday, August 08, 2017 10:46 AM
>To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
>shivasharan.srikanteshw...@broadcom.com
>Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org
>Subject: [PATCH v2] scsi: megaraid_sas: fix allocate instance->pd_info
twice
>
>fix allocate instance->pd_info twice which was introduced by
96188a89cc6d.
>
>Signed-off-by: weiping zhang <zhangweip...@didichuxing.com>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index 71c4746..a0f057c 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -6096,14 +6096,12 @@ static int megasas_probe_one(struct pci_dev
>*pdev,
>   instance->pd_info = pci_alloc_consistent(pdev,
>   sizeof(struct MR_PD_INFO), >pd_info_h);
>
>-  instance->pd_info = pci_alloc_consistent(pdev,
>-  sizeof(struct MR_PD_INFO), >pd_info_h);
>-  instance->tgt_prop = pci_alloc_consistent(pdev,
>-  sizeof(struct MR_TARGET_PROPERTIES), 
>>tgt_prop_h);
>-
>   if (!instance->pd_info)
>   dev_err(>pdev->dev, "Failed to alloc mem
>for pd_info\n");
>
>+  instance->tgt_prop = pci_alloc_consistent(pdev,
>+  sizeof(struct MR_TARGET_PROPERTIES), 
>>tgt_prop_h);
>+
>   if (!instance->tgt_prop)
>   dev_err(>pdev->dev, "Failed to alloc mem
>for tgt_prop\n");

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>
>--
>2.9.4


RE: [PATCH] megaraid_sas: move command counter to correct place

2017-08-08 Thread Sumit Saxena
>-Original Message-
>From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
>Sent: Monday, August 07, 2017 11:07 PM
>To: Tomas Henzl
>Cc: linux-scsi@vger.kernel.org; sumit.sax...@broadcom.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH] megaraid_sas: move command counter to correct place
>
>
>Tomas,
>
>> the eh reset function returns success when fw_outstanding equals zero,
>> that means that the counter shouldn't be decremented when the driver
>> still owns the command
>
>Applied to 4.13/scsi-fixes. Thank you!

Just realized that this patch may cause performance regression.
With this patch below scenario may occur-

-Consider outstanding IOs reaches to controller's Queue depth.
-Driver frees up command and complete it back to SML.
-Since host_busy is decremented, SML can issue one new  IO to driver.
-By the time, if "fw_outstanding" is not decremented by driver, then
driver will return newly submitted IO back to SML with return status
SCSI_MLQUEUE_HOST_BUSY because of below code
  in megaraid_sas driver's IO submission path-

if (atomic_inc_return(>fw_outstanding) >
instance->host->can_queue) {
atomic_dec(>fw_outstanding);
return SCSI_MLQUEUE_HOST_BUSY;
}

This situation will be more evident when RAID1 fastpath IOs are running as
in that case driver will be issuing two IOs to firmware for single IO
issued from SML.
Above situation can be avoided, if this patch is removed.

Regarding Tomas' concern, there should not be any problem as driver calls
"synchronize_irq" before checking "fw_outstanding". Once fw_outstanding is
decremented and
driver frees up command, then only driver will be checking
"fw_outstanding" equals to zero or not so all this will always fall in a
sequence and will not
cause the problem stated by Tomas.

I am sorry for confusion and would request to revert this patch.

Thanks,
Sumit

>
>--
>Martin K. Petersen Oracle Linux Engineering


RE: [PATCH] scsi: megaraid_sas: fix error handle in megasas_probe_one

2017-08-07 Thread Sumit Saxena
>-Original Message-
>From: weiping zhang [mailto:zhangweip...@didichuxing.com]
>Sent: Monday, August 07, 2017 10:57 PM
>To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
>shivasharan.srikanteshw...@broadcom.com
>Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org
>Subject: [PATCH] scsi: megaraid_sas: fix error handle in
megasas_probe_one
>
>megasas_mgmt_info.max_index has increased by 1 before
>megasas_io_attach, if megasas_io_attach return error, then goto
>fail_io_attach, megasas_mgmt_info.instance has a wrong index here. So
first
>reduce max_index and then set that instance to NULL.
>
>Signed-off-by: weiping zhang <zhangweip...@didichuxing.com>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index b5b9ba7..91eeec9 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -6226,8 +6226,8 @@ static int megasas_probe_one(struct pci_dev *pdev,
> fail_start_aen:
> fail_io_attach:
>   megasas_mgmt_info.count--;
>-  megasas_mgmt_info.instance[megasas_mgmt_info.max_index] =
>NULL;
>   megasas_mgmt_info.max_index--;
>+  megasas_mgmt_info.instance[megasas_mgmt_info.max_index] =
>NULL;
>
>   instance->instancet->disable_intr(instance);
>   megasas_destroy_irqs(instance);

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.9.4


RE: [PATCH] megaraid_sas: move command counter to correct place

2017-08-07 Thread Sumit Saxena
>-Original Message-
>From: Tomas Henzl [mailto:the...@redhat.com]
>Sent: Friday, July 28, 2017 7:34 PM
>To: linux-scsi@vger.kernel.org
>Cc: sumit.sax...@broadcom.com; kashyap.de...@broadcom.com
>Subject: [PATCH] megaraid_sas: move command counter to correct place
>
>the eh reset function returns success when fw_outstanding equals zero,
that
>means that the counter shouldn't be decremented when the driver still
owns
>the command
>
>
>Signed-off-by: Tomas Henzl <the...@redhat.com>
>---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index f990ab4d45..c615aadb2b 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -3046,7 +3046,6 @@ complete_cmd_fusion(struct megasas_instance
>*instance, u32 MSIxIndex)
>   }
>   //Fall thru and complete IO
>   case MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST: /* LD-IO
>Path */
>-  atomic_dec(>fw_outstanding);
>   if (cmd_fusion->r1_alt_dev_handle ==
>MR_DEVHANDLE_INVALID) {
>   map_cmd_status(fusion, scmd_local, status,
>  extStatus,
>le32_to_cpu(data_length), @@ -3060,6 +3059,7 @@
>complete_cmd_fusion(struct megasas_instance *instance, u32 MSIxIndex)
>   scmd_local->scsi_done(scmd_local);
>   } else  /* Optimal VD - R1 FP command completion.
>*/
>   megasas_complete_r1_command(instance,
>cmd_fusion);
>+  atomic_dec(>fw_outstanding);
>   break;
>   case MEGASAS_MPI2_FUNCTION_PASSTHRU_IO_REQUEST:
>/*MFI command */
>   cmd_mfi = instance->cmd_list[cmd_fusion-
>>sync_cmd_idx];

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.9.4


RE: [PATCH] scsi: megaraid_sas: fix memleak in megasas_alloc_cmdlist_fusion

2017-07-21 Thread Sumit Saxena
>-Original Message-
>From: shuw...@redhat.com [mailto:shuw...@redhat.com]
>Sent: Friday, July 21, 2017 4:24 PM
>To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
>shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org; ch...@redhat.com; liw...@redhat.com; Shu Wang
>Subject: [PATCH] scsi: megaraid_sas: fix memleak in
>megasas_alloc_cmdlist_fusion
>
>From: Shu Wang <shuw...@redhat.com>
>
>Found this issue by kmemleak, a few kb mem was leaked in
>megasas_alloc_cmdlist_fusion when kzalloc failed for one
>megasas_cmd_fusion allocation.
>
>unreferenced object 0x88045dbd2000 (size 8192):
>  comm "systemd-udevd", pid 323, jiffies 4294671759 (age 49.008s)
>  backtrace:
>[] kmemleak_alloc+0x4a/0xa0
>[] __kmalloc+0xe8/0x220
>[] megasas_alloc_cmdlist_fusion+0x34/0xe0
>[megaraid_sas]
>(gdb) list *megasas_alloc_cmdlist_fusion+0x34
>0xd5c4 is in megasas_alloc_cmdlist_fusion
>   (drivers/scsi/megaraid/megaraid_sas_fusion.c:443).
>[] megasas_alloc_cmds_fusion+0x25/0x410
>[megaraid_sas]
>[] megasas_init_adapter_fusion+0x21f/0x640
>[megaraid_sas]
>[] megasas_init_fw+0x357/0xd30 [megaraid_sas]
>[] megasas_probe_one.part.33+0x636/0x1100
>[megaraid_sas]
>[] megasas_probe_one+0x46/0xc0 [megaraid_sas]
>[] local_pci_probe+0x45/0xa0
>[] pci_device_probe+0x192/0x1b0
>[] driver_probe_device+0x2a8/0x460
>[] __driver_attach+0xdd/0xe0
>[] bus_for_each_dev+0x6c/0xc0
>[] driver_attach+0x1e/0x20
>[] bus_add_driver+0x45/0x270
>[] driver_register+0x60/0xe0 unreferenced object
>0x880454ce3600 (size 192):
>  backtrace:
>[] kmemleak_alloc+0x4a/0xa0
>[] kmem_cache_alloc_trace+0xca/0x1d0
>[] megasas_alloc_cmdlist_fusion+0x77/0xe0
>[megaraid_sas]
>(gdb) list *megasas_alloc_cmdlist_fusion+0x77
>0xd607 is in megasas_alloc_cmdlist_fusion
>(drivers/scsi/megaraid/megaraid_sas_fusion.c:450).
>[] megasas_alloc_cmds_fusion+0x25/0x410
>[megaraid_sas]
>[] megasas_init_adapter_fusion+0x21f/0x640
>[megaraid_sas]
>[] megasas_init_fw+0x357/0xd30 [megaraid_sas]
>[] megasas_probe_one.part.33+0x636/0x1100
>[megaraid_sas]
>[] megasas_probe_one+0x46/0xc0 [megaraid_sas]
>[] local_pci_probe+0x45/0xa0
>[] pci_device_probe+0x192/0x1b0
>[] driver_probe_device+0x2a8/0x460
>[] __driver_attach+0xdd/0xe0
>[] bus_for_each_dev+0x6c/0xc0
>[] driver_attach+0x1e/0x20
>[] bus_add_driver+0x45/0x270
>[] driver_register+0x60/0xe0
>
>Signed-off-by: Shu Wang <shuw...@redhat.com>
>---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index f990ab4d..9855106 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -425,7 +425,7 @@ static int megasas_create_sg_sense_fusion(struct
>megasas_instance *instance)  int  megasas_alloc_cmdlist_fusion(struct
>megasas_instance *instance)  {
>-  u32 max_mpt_cmd, i;
>+  u32 max_mpt_cmd, i, j;
>   struct fusion_context *fusion;
>
>   fusion = instance->ctrl_context;
>@@ -450,11 +450,15 @@ megasas_alloc_cmdlist_fusion(struct
>megasas_instance *instance)
>   fusion->cmd_list[i] = kzalloc(sizeof(struct
>megasas_cmd_fusion),
> GFP_KERNEL);
>   if (!fusion->cmd_list[i]) {
>+  for (j = 0; j < i; j++)
>+      kfree(fusion->cmd_list[j]);
>+  kfree(fusion->cmd_list);
>   dev_err(>pdev->dev,
>   "Failed from %s %d\n",  __func__,
__LINE__);
>   return -ENOMEM;
>   }
>   }
>+
>   return 0;
> }
> int
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.5.0


RE: [PATCH 1/2] Drop legacy megaraid controller

2017-07-03 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Friday, June 30, 2017 11:46 PM
>To: Christoph Hellwig
>Cc: Martin K. Petersen; James Bottomley; Kashyap Desai; Sumit Saxena;
>linux-
>s...@vger.kernel.org; Hannes Reinecke
>Subject: Re: [PATCH 1/2] Drop legacy megaraid controller
>
>On 06/30/2017 07:33 PM, Christoph Hellwig wrote:
>> On Fri, Jun 30, 2017 at 01:05:53PM +0200, Hannes Reinecke wrote:
>>> The hardware is ancient, and support for most cards has been moved to
>>> megaraid_mbox. So drop it.
>>
>>
>> This seems to drop support for the PCI_DEVICE_ID_AMI_MEGARAID and
>> PCI_DEVICE_ID_AMI_MEGARAID2 cards.  Do we have any suggestions this
>> code is so broken to not care anymore? Is there any reason why they
>> can't just work with the megaraid_mbox driver?
>>
>Hmm. Probably no good reason at all.
>I'll check which version I have here.

Hannes,
We are willing to keep only megaraid_sas driver and intent is rest of
megaraid* drivers
(it includes megaraid, megaraid_mm, megaraid_mbox) should be removed.
Broadcom(LSI) has stopped supporting hardware associated with these old
drivers.

Thanks,
Sumit
>
>Cheers,
>
>Hannes
>--
>Dr. Hannes Reinecke   Teamlead Storage & Networking
>h...@suse.de  +49 911 74053 688
>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
>GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284
>(AG Nürnberg)


RE: [PATCH 13/47] megaraid: pass in NULL scb for host reset

2017-06-29 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Thursday, June 29, 2017 11:23 AM
>To: Kashyap Desai; Sumit Saxena; Christoph Hellwig
>Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org; Hannes
>Reinecke
>Subject: Re: [PATCH 13/47] megaraid: pass in NULL scb for host reset
>
>On 06/28/2017 07:40 PM, Kashyap Desai wrote:
>>> -Original Message-
>>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>>> ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
>>> Sent: Wednesday, June 28, 2017 9:00 PM
>>> To: Sumit Saxena; Christoph Hellwig
>>> Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org;
>>> Hannes Reinecke
>>> Subject: Re: [PATCH 13/47] megaraid: pass in NULL scb for host reset
>>>
>>> On 06/28/2017 03:41 PM, Sumit Saxena wrote:
>>>>> -Original Message-
>>>>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>>>>> ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
>>>>> Sent: Wednesday, June 28, 2017 2:03 PM
>>>>> To: Christoph Hellwig
>>>>> Cc: Martin K. Petersen; James Bottomley;
>>>>> linux-scsi@vger.kernel.org;
>>>> Hannes
>>>>> Reinecke; Hannes Reinecke
>>>>> Subject: [PATCH 13/47] megaraid: pass in NULL scb for host reset
>>>>>
>>>>> When calling a host reset we shouldn't rely on the command
>>>>> triggering the reset, so allow megaraid_abort_and_reset() to be
>>>>> called with a NULL
>>> scb.
>>>>> And drop the pointless 'bus_reset' and 'target_reset' handlers,
>>>>> which
>>>> just call
>>>>> the same function as host_reset.
>>>>
>>>> If this patch address any functional issue, then we should consider
>>>> this.
>>>> If it's code optimization, can we ignore this as this is being very
>>>> old driver and no more maintained by Broadcom/LSI ?
>>>>
>>> Sadly, ignoring is not an option.
>>> I'm planning to update the calling convention for SCSI EH, to resolve
>>> the
>>> long-
>>> standing problem with sg_reset ioctls.
>>> sg_reset ioctl will allocate an out-of-band SCSI command, which does
>>> no longer work with the new command allocation scheme in multiqueue.
>>> So it's not possible to just 'ignore' it, as then SCSI EH will cease
>>> to function with that driver.
>>
>> Hannes - We are in process of sending megaraid and 3ware driver
>> removal as LSI/Broadcom  stopped supporting those products.
>> I agree we should review this closely, but lack of test coverage and
>> end of life cycle of product is requesting us to know the rational.
>> For now, let's consider NACK for this patch. We will be removing old
>> megaraid (mbox) driver and 3Ware drivers soon.
>>
>Hmm.
>Can't we do the removal now?
>There is not a lot of testing involved with _that_, surely?
>
>I'd be happy to do a patch if you like ...
We are fine with you submitting the patch to remove megaraid and megaraid_mm
drivers. 3ware drivers are maintained by Adam Radford so we can not remove
them.
>
>Cheers,
>
>Hannes
>--
>Dr. Hannes Reinecke   Teamlead Storage & Networking
>h...@suse.de  +49 911 74053 688
>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
>GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284
>(AG Nürnberg)


RE: [PATCH 13/47] megaraid: pass in NULL scb for host reset

2017-06-28 Thread Sumit Saxena
>-Original Message-
>From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
>Sent: Wednesday, June 28, 2017 2:03 PM
>To: Christoph Hellwig
>Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org;
Hannes
>Reinecke; Hannes Reinecke
>Subject: [PATCH 13/47] megaraid: pass in NULL scb for host reset
>
>When calling a host reset we shouldn't rely on the command triggering the
>reset, so allow megaraid_abort_and_reset() to be called with a NULL scb.
>And drop the pointless 'bus_reset' and 'target_reset' handlers, which
just call
>the same function as host_reset.

If this patch address any functional issue, then we should consider this.
If it's code optimization, can we ignore this as this is being very old
driver
and no more maintained by Broadcom/LSI ?

>
>Signed-off-by: Hannes Reinecke 
>---
> drivers/scsi/megaraid.c | 42 --
> 1 file changed, 16 insertions(+), 26 deletions(-)
>
>diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
>3c63c29..7e504d3 100644
>--- a/drivers/scsi/megaraid.c
>+++ b/drivers/scsi/megaraid.c
>@@ -1909,7 +1909,7 @@ static DEF_SCSI_QCMD(megaraid_queue)
>
>   spin_lock_irq(>lock);
>
>-  rval =  megaraid_abort_and_reset(adapter, cmd, SCB_RESET);
>+  rval =  megaraid_abort_and_reset(adapter, NULL, SCB_RESET);

If cmd=NULL is passed, it will crash inside function
megaraid_abort_and_reset() while dereferencing "cmd" pointer.
Below is the code of function  megaraid_abort_and_reset() where it will
crash-

static int
megaraid_abort_and_reset(adapter_t *adapter, Scsi_Cmnd *cmd, int aor)
{
struct list_head*pos, *next;
scb_t   *scb;

dev_warn(>dev->dev, "%s cmd=%x 

RE: Application stops due to ext4 filesytsem IO error

2017-06-13 Thread Sumit Saxena
Gentle ping.

I have opened kernel BZ for this. Here is the BZ link-
https://bugzilla.kernel.org/show_bug.cgi?id=196057

Thanks,
Sumit
>-Original Message-
>From: Sumit Saxena [mailto:sumit.sax...@broadcom.com]
>Sent: Tuesday, June 06, 2017 9:05 PM
>To: 'Jens Axboe'
>Cc: 'linux-bl...@vger.kernel.org'; 'linux-scsi@vger.kernel.org'
>Subject: RE: Application stops due to ext4 filesytsem IO error
>
>Gentle ping..
>
>>-----Original Message-
>>From: Sumit Saxena [mailto:sumit.sax...@broadcom.com]
>>Sent: Monday, June 05, 2017 12:59 PM
>>To: 'Jens Axboe'
>>Cc: 'linux-bl...@vger.kernel.org'; 'linux-scsi@vger.kernel.org'
>>Subject: Application stops due to ext4 filesytsem IO error
>>
>>Jens,
>>
>>We am observing  application stops while running ext4 filesystem IOs
>>along with target reset in parallel.
>>Our suspect is this behavior can be attributed to linux block layer.
>>See below for details-
>>
>>Problem statement - " Application stops due to IO error from file
>>system buffered IO. (Note - It is always a FS meta data read failure)"
>>Issue is reproducible - "Yes. It is consistently reproducible."
>>Brief about setup -
>>Latest 4.11 kernel. Issue hits irrespective of whether SCSI MQ is
>>enabled or disabled. use_blk_mq=Y and use_blk_mq=N has similar issue.
>>Direct attached 4 SAS/SATA drives connected to MegaRAID Invader
>>controller.
>>
>>Reproduction steps -
>>-Create ext4 FS on 4 JBODs(non RAID volumes) behind MegaRAID SAS
>>controller.
>>-Start Data integrity test on all four ext4 mounted partition. (Tool
>>should be configured to send Buffered FS IO).
>>-Send Target Reset  (have some delay between next reset to allow some
>>IO on device) on each JBOD to simulate error condition. (sg_reset -d
>/dev/sdX).
>>
>>End result -
>>Combination of target resets and FS IOs in parallel causes application
>>halt with ext4 Filesystem IO error.
>>We are able to restart  application without cleaning and unmounting
>>filesystem.
>>Below are the error logs at the time of application stop-
>>
>>--
>>sd 0:0:53:0: target reset called for
>>scmd(88003cf25148)
>>sd 0:0:53:0: attempting target reset!
>>scmd(88003cf25148) tm_dev_handle 0xb
>>sd 0:0:53:0: [sde] tag#519 BRCM Debug: request->cmd_flags: 0x80700
>bio-
>>>bi_flags: 0x2  bio->bi_opf: 0x3000 rq_flags 0x20e3
>>..
>>sd 0:0:53:0: [sde] tag#519 CDB: Read(10) 28 00 15 00 11 10 00 00 f8 00
>>EXT4-fs error (device sde): __ext4_get_inode_loc:4465: inode #11018287:
>>block 44040738: comm chaos: unable to read itable block
>>---
>>
>>We debug further to understand what is happening above LLD. See below-
>>
>>During target reset,  there may be IO coming from target with CHECK
>>CONDITION with below sense information-.
>>Sense Key : Aborted Command [current]
>>Add. Sense: No additional sense information
>>
>>Such Aborted command should be retried by SML/Block layer. This happens
>>from SML expect for FS Meta data read.
>>From driver level debug, we found IOs with REQ_FAILFAST_DEV bit set in
>>scmd->request->cmd_flags are not retried by SML and that is also as
>>expected.
>>
>>Below is the code in scsi_error.c(function- scsi_noretry_cmd) which
>>causes IOs with REQ_FAILFAST_DEV enabled not getting retried bit
>>completed back to upper layer-
>>
>>/*
>> * assume caller has checked sense and determined
>> * the check condition was retryable.
>> */
>>if (scmd->request->cmd_flags & REQ_FAILFAST_DEV ||
>>scmd->request->cmd_type == REQ_TYPE_BLOCK_PC)
>>return 1;
>>else
>>return 0;
>>
>>
>>IO which causes application to stop has REQ_FAILFAST_DEV enabled inside
>>"scmd->request->cmd_flags". We noticed that this bit will be set for
>>filesystem Read ahead meta data IOs. In order to confirm the same, we
>>mounted with option inode_readahead_blks=0 to disable ext4's inode
>>table readahead algorithm and did not observe the issue. Issue does not
>>hit with DIRECT IOs but only with cached/buffered IOs.
>>
>>2. From driver level debug prints, we also noticed - There are many IO
>>failures with REQ_FAILFAST_DEV handled gracefully by filesystem.
>>Application level failure happens only If IO has RQF_MIXED_MERGE set.
>>If IO merging is disabled through sysfs parameter for SCSI device in
>>question- nomerges set to 2, we are not seein

RE: Application stops due to ext4 filesytsem IO error

2017-06-06 Thread Sumit Saxena
Gentle ping..

>-Original Message-
>From: Sumit Saxena [mailto:sumit.sax...@broadcom.com]
>Sent: Monday, June 05, 2017 12:59 PM
>To: 'Jens Axboe'
>Cc: 'linux-bl...@vger.kernel.org'; 'linux-scsi@vger.kernel.org'
>Subject: Application stops due to ext4 filesytsem IO error
>
>Jens,
>
>We am observing  application stops while running ext4 filesystem IOs
along
>with target reset in parallel.
>Our suspect is this behavior can be attributed to linux block layer. See
below
>for details-
>
>Problem statement - " Application stops due to IO error from file system
>buffered IO. (Note - It is always a FS meta data read failure)"
>Issue is reproducible - "Yes. It is consistently reproducible."
>Brief about setup -
>Latest 4.11 kernel. Issue hits irrespective of whether SCSI MQ is enabled
or
>disabled. use_blk_mq=Y and use_blk_mq=N has similar issue.
>Direct attached 4 SAS/SATA drives connected to MegaRAID Invader
>controller.
>
>Reproduction steps -
>-Create ext4 FS on 4 JBODs(non RAID volumes) behind MegaRAID SAS
>controller.
>-Start Data integrity test on all four ext4 mounted partition. (Tool
should be
>configured to send Buffered FS IO).
>-Send Target Reset  (have some delay between next reset to allow some IO
>on device) on each JBOD to simulate error condition. (sg_reset -d
/dev/sdX).
>
>End result -
>Combination of target resets and FS IOs in parallel causes application
halt
>with ext4 Filesystem IO error.
>We are able to restart  application without cleaning and unmounting
>filesystem.
>Below are the error logs at the time of application stop-
>
>--
>sd 0:0:53:0: target reset called for
>scmd(88003cf25148)
>sd 0:0:53:0: attempting target reset!
>scmd(88003cf25148) tm_dev_handle 0xb
>sd 0:0:53:0: [sde] tag#519 BRCM Debug: request->cmd_flags: 0x80700   bio-
>>bi_flags: 0x2  bio->bi_opf: 0x3000 rq_flags 0x20e3
>..
>sd 0:0:53:0: [sde] tag#519 CDB: Read(10) 28 00 15 00 11 10 00 00 f8 00
>EXT4-fs error (device sde): __ext4_get_inode_loc:4465: inode #11018287:
>block 44040738: comm chaos: unable to read itable block
>---
>
>We debug further to understand what is happening above LLD. See below-
>
>During target reset,  there may be IO coming from target with CHECK
>CONDITION with below sense information-.
>Sense Key : Aborted Command [current]
>Add. Sense: No additional sense information
>
>Such Aborted command should be retried by SML/Block layer. This happens
>from SML expect for FS Meta data read.
>From driver level debug, we found IOs with REQ_FAILFAST_DEV bit set in
>scmd->request->cmd_flags are not retried by SML and that is also as
>expected.
>
>Below is the code in scsi_error.c(function- scsi_noretry_cmd) which
causes
>IOs with REQ_FAILFAST_DEV enabled not getting retried bit completed back
>to upper layer-
>
>/*
> * assume caller has checked sense and determined
> * the check condition was retryable.
> */
>if (scmd->request->cmd_flags & REQ_FAILFAST_DEV ||
>scmd->request->cmd_type == REQ_TYPE_BLOCK_PC)
>return 1;
>else
>return 0;
>
>
>IO which causes application to stop has REQ_FAILFAST_DEV enabled inside
>"scmd->request->cmd_flags". We noticed that this bit will be set for
>filesystem Read ahead meta data IOs. In order to confirm the same, we
>mounted with option inode_readahead_blks=0 to disable ext4's inode table
>readahead algorithm and did not observe the issue. Issue does not hit
with
>DIRECT IOs but only with cached/buffered IOs.
>
>2. From driver level debug prints, we also noticed - There are many IO
>failures with REQ_FAILFAST_DEV handled gracefully by filesystem.
>Application level failure happens only If IO has RQF_MIXED_MERGE set.
>If IO merging is disabled through sysfs parameter for SCSI device in
question-
>nomerges set to 2, we are not seeing the issue.
>
>3. We added few prints in driver to dump "scmd->request->cmd_flags" and
>"scmd->request->rq_flags" for IOs completed with CHECK CONDITION and
>culprit IOs has all these bits- REQ_FAILFAST_DEV and REQ_RAHEAD bit set
in
>"scmd->request->cmd_flags" and RQF_MIXED_MERGE bit set in "scmd-
>>request->rq_flags". Also it's not necessarily true that all IOs with
these
>three bits set will cause issue but whenever issue hits, these three bits
are
>set for IO causing failure.
>
>
>In summary,
>FS mechanism of using READ AHEAD for meta data works fine (in case of IO
>failure) if there is no mix/merge at block layer.
>FS mechanism of using READ AHEAD for meta data has some corner case
>which is not handled properly (in case of IO failure) if  there was
mix/merge
>at block layer.
>megaraid_sas driver's behavior seems correct here. Aborted IO goes to SML
>with CHECK CONDITION settings and SML decided to fail fast IO as it was
>requested.
>
>Query -  Is this block layer (page cache) issue?  What should be the
ideal fix ?
>
>Thanks,
>Sumit


Application stops due to ext4 filesytsem IO error

2017-06-05 Thread Sumit Saxena
Jens,

We am observing  application stops while running ext4 filesystem IOs along
with target reset in parallel.
Our suspect is this behavior can be attributed to linux block layer. See
below for details-

Problem statement - " Application stops due to IO error from file system
buffered IO. (Note - It is always a FS meta data read failure)"
Issue is reproducible - "Yes. It is consistently reproducible."
Brief about setup -
Latest 4.11 kernel. Issue hits irrespective of whether SCSI MQ is enabled
or disabled. use_blk_mq=Y and use_blk_mq=N has similar issue.
Direct attached 4 SAS/SATA drives connected to MegaRAID Invader
controller.

Reproduction steps -
-Create ext4 FS on 4 JBODs(non RAID volumes) behind MegaRAID SAS
controller.
-Start Data integrity test on all four ext4 mounted partition. (Tool
should be configured to send Buffered FS IO).
-Send Target Reset  (have some delay between next reset to allow some IO
on device) on each JBOD to simulate error condition. (sg_reset -d
/dev/sdX).

End result -
Combination of target resets and FS IOs in parallel causes application
halt with ext4 Filesystem IO error.
We are able to restart  application without cleaning and unmounting
filesystem.
Below are the error logs at the time of application stop-

--
sd 0:0:53:0: target reset called for
scmd(88003cf25148)
sd 0:0:53:0: attempting target reset!
scmd(88003cf25148) tm_dev_handle 0xb
sd 0:0:53:0: [sde] tag#519 BRCM Debug: request->cmd_flags: 0x80700
bio->bi_flags: 0x2  bio->bi_opf: 0x3000 rq_flags 0x20e3
..
sd 0:0:53:0: [sde] tag#519 CDB: Read(10) 28 00 15 00 11 10 00 00 f8 00
EXT4-fs error (device sde): __ext4_get_inode_loc:4465: inode #11018287:
block 44040738: comm chaos: unable to read itable block
---

We debug further to understand what is happening above LLD. See below-

During target reset,  there may be IO coming from target with CHECK
CONDITION with below sense information-.
Sense Key : Aborted Command [current]
Add. Sense: No additional sense information

Such Aborted command should be retried by SML/Block layer. This happens
from SML expect for FS Meta data read.
>From driver level debug, we found IOs with REQ_FAILFAST_DEV bit set in
scmd->request->cmd_flags are not retried by SML and that is also as
expected.

Below is the code in scsi_error.c(function- scsi_noretry_cmd) which causes
IOs with REQ_FAILFAST_DEV enabled not getting retried bit completed back
to upper layer-

/*
 * assume caller has checked sense and determined
 * the check condition was retryable.
 */
if (scmd->request->cmd_flags & REQ_FAILFAST_DEV ||
scmd->request->cmd_type == REQ_TYPE_BLOCK_PC)
return 1;
else
return 0;


IO which causes application to stop has REQ_FAILFAST_DEV enabled inside
"scmd->request->cmd_flags". We noticed that this bit will be set for
filesystem Read ahead meta data IOs. In order to confirm the same, we
mounted with option inode_readahead_blks=0 to disable ext4's inode table
readahead algorithm and did not observe the issue. Issue does not hit with
DIRECT IOs but only with cached/buffered IOs.

2. From driver level debug prints, we also noticed - There are many IO
failures with REQ_FAILFAST_DEV handled gracefully by filesystem.
Application level failure happens only If IO has RQF_MIXED_MERGE set.
If IO merging is disabled through sysfs parameter for SCSI device in
question- nomerges set to 2, we are not seeing the issue.

3. We added few prints in driver to dump "scmd->request->cmd_flags" and
"scmd->request->rq_flags" for IOs completed with CHECK CONDITION and
culprit IOs has all these bits- REQ_FAILFAST_DEV and REQ_RAHEAD bit set in
"scmd->request->cmd_flags" and RQF_MIXED_MERGE bit set in
"scmd->request->rq_flags". Also it's not necessarily true that all IOs
with these three bits set will cause issue but whenever issue hits, these
three bits are set for IO causing failure.


In summary,
FS mechanism of using READ AHEAD for meta data works fine (in case of IO
failure) if there is no mix/merge at block layer.
FS mechanism of using READ AHEAD for meta data has some corner case which
is not handled properly (in case of IO failure) if  there was  mix/merge
at block layer.
megaraid_sas driver's behavior seems correct here. Aborted IO goes to SML
with CHECK CONDITION settings and SML decided to fail fast IO as it was
requested.

Query -  Is this block layer (page cache) issue?  What should be the ideal
fix ?

Thanks,
Sumit


RE: [PATCH] megaraid: Fix a sleep-in-atomic bug

2017-05-31 Thread Sumit Saxena
>-Original Message-
>From: Jia-Ju Bai [mailto:baijiaju1...@163.com]
>Sent: Wednesday, May 31, 2017 8:27 AM
>To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
>shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org; Jia-Ju Bai
>Subject: [PATCH] megaraid: Fix a sleep-in-atomic bug
>
>The driver may sleep under a spin lock, and the function call path is:
>mraid_mm_attach_buf (acquire the lock by spin_lock_irqsave)
>  pci_pool_alloc(GFP_KERNEL) --> may sleep
>
>To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".
>
>Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com>
>---
> drivers/scsi/megaraid/megaraid_mm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_mm.c
>b/drivers/scsi/megaraid/megaraid_mm.c
>index 4cf9ed9..c43afb8 100644
>--- a/drivers/scsi/megaraid/megaraid_mm.c
>+++ b/drivers/scsi/megaraid/megaraid_mm.c
>@@ -574,7 +574,7 @@
>
>   kioc->pool_index= right_pool;
>   kioc->free_buf  = 1;
>-  kioc->buf_vaddr = pci_pool_alloc(pool->handle, GFP_KERNEL,
>+  kioc->buf_vaddr = pci_pool_alloc(pool->handle, GFP_ATOMIC,
>   >buf_paddr);
>   spin_unlock_irqrestore(>lock, flags);

This is very old driver and reached EOL. Did you face any issue because of
this bug or discover this through code review?
Anyways patch looks good to me.

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>
>--
>1.7.9.5
>


RE: [PATCH v4 11/19] scsi: megaraid: Replace PCI pool old API

2017-03-01 Thread Sumit Saxena
VME_PAGE_SIZE, 0);
>   /* SCSI_SENSE_BUFFERSIZE  = 96 bytes */
>   fusion->sense_dma_pool =
>-  pci_pool_create("mr_sense", instance->pdev,
>+  dma_pool_create("mr_sense", >pdev->dev,
>   SCSI_SENSE_BUFFERSIZE, 64, 0);
>
>   if (!fusion->sense_dma_pool || !fusion->sg_dma_pool) { @@ -395,10
>+389,10 @@ static int megasas_create_sg_sense_fusion(struct
>megasas_instance *instance)
>*/
>   for (i = 0; i < max_cmd; i++) {
>   cmd = fusion->cmd_list[i];
>-  cmd->sg_frame = pci_pool_alloc(fusion->sg_dma_pool,
>+  cmd->sg_frame = dma_pool_alloc(fusion->sg_dma_pool,
>   GFP_KERNEL, 
>>sg_frame_phys_addr);
>
>-  cmd->sense = pci_pool_alloc(fusion->sense_dma_pool,
>+  cmd->sense = dma_pool_alloc(fusion->sense_dma_pool,
>   GFP_KERNEL,
>sense_phys_addr);
>   if (!cmd->sg_frame || !cmd->sense) {
>   dev_err(>pdev->dev,
>@@ -410,7 +404,7 @@ static int megasas_create_sg_sense_fusion(struct
>megasas_instance *instance)
>   /* create sense buffer for the raid 1/10 fp */
>   for (i = max_cmd; i < instance->max_mpt_cmds; i++) {
>   cmd = fusion->cmd_list[i];
>-  cmd->sense = pci_pool_alloc(fusion->sense_dma_pool,
>+  cmd->sense = dma_pool_alloc(fusion->sense_dma_pool,
>   GFP_KERNEL, >sense_phys_addr);
>   if (!cmd->sense) {
>   dev_err(>pdev->dev,
>@@ -475,7 +469,7 @@ megasas_alloc_request_fusion(struct megasas_instance
>*instance)
>   }
>
>   fusion->io_request_frames_pool =
>-  pci_pool_create("mr_ioreq", instance->pdev,
>+  dma_pool_create("mr_ioreq", >pdev->dev,
>   fusion->io_frames_alloc_sz, 16, 0);
>
>   if (!fusion->io_request_frames_pool) { @@ -485,7 +479,7 @@
>megasas_alloc_request_fusion(struct megasas_instance *instance)
>   }
>
>   fusion->io_request_frames =
>-  pci_pool_alloc(fusion->io_request_frames_pool,
>+  dma_pool_alloc(fusion->io_request_frames_pool,
>   GFP_KERNEL, 
>>io_request_frames_phys);
>   if (!fusion->io_request_frames) {
>   dev_err(>pdev->dev,
>@@ -505,7 +499,7 @@ megasas_alloc_reply_fusion(struct megasas_instance
>*instance)
>
>   count = instance->msix_vectors > 0 ? instance->msix_vectors : 1;
>   fusion->reply_frames_desc_pool =
>-  pci_pool_create("mr_reply", instance->pdev,
>+  dma_pool_create("mr_reply", >pdev->dev,
>   fusion->reply_alloc_sz * count, 16, 0);
>
>   if (!fusion->reply_frames_desc_pool) { @@ -515,7 +509,7 @@
>megasas_alloc_reply_fusion(struct megasas_instance *instance)
>   }
>
>   fusion->reply_frames_desc[0] =
>-  pci_pool_alloc(fusion->reply_frames_desc_pool,
>+  dma_pool_alloc(fusion->reply_frames_desc_pool,
>   GFP_KERNEL, >reply_frames_desc_phys[0]);
>   if (!fusion->reply_frames_desc[0]) {
>   dev_err(>pdev->dev,
>@@ -558,8 +552,10 @@ megasas_alloc_rdpq_fusion(struct megasas_instance
>*instance)
>   memset(fusion->rdpq_virt, 0,
>   sizeof(struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY) *
>MAX_MSIX_QUEUES_FUSION);
>   count = instance->msix_vectors > 0 ? instance->msix_vectors : 1;
>-  fusion->reply_frames_desc_pool = pci_pool_create("mr_rdpq",
>-   instance->pdev,
fusion-
>>reply_alloc_sz, 16, 0);
>+  fusion->reply_frames_desc_pool = dma_pool_create("mr_rdpq",
>+
>pdev->dev,
>+
fusion->reply_alloc_sz,
>+   16, 0);
>
>   if (!fusion->reply_frames_desc_pool) {
>   dev_err(>pdev->dev,
>@@ -569,7 +565,7 @@ megasas_alloc_rdpq_fusion(struct megasas_instance
>*instance)
>
>   for (i = 0; i < count; i++) {
>   fusion->reply_frames_desc[i] =
>-  pci_pool_alloc(fusion-
>>reply_frames_desc_pool,
>+  dma_pool_alloc(fusion-
>>reply_frames_desc_pool,
>   GFP_KERNEL, 
>>reply_frames_desc_phys[i]);
>   if (!fusion->reply_frames_desc[i]) {
>   dev_err(>pdev->dev,
>@@ -597,13 +593,12 @@ megasas_free_rdpq_fusion(struct megasas_instance
>*instance) {
>
>   for (i = 0; i < MAX_MSIX_QUEUES_FUSION; i++) {
>   if (fusion->reply_frames_desc[i])
>-  pci_pool_free(fusion->reply_frames_desc_pool,
>+  dma_pool_free(fusion->reply_frames_desc_pool,
>   fusion->reply_frames_desc[i],
>   fusion->reply_frames_desc_phys[i]);
>   }
>
>-  if (fusion->reply_frames_desc_pool)
>-  pci_pool_destroy(fusion->reply_frames_desc_pool);
>+  dma_pool_destroy(fusion->reply_frames_desc_pool);
>
>   if (fusion->rdpq_virt)
>   pci_free_consistent(instance->pdev,
>@@ -619,12 +614,11 @@ megasas_free_reply_fusion(struct megasas_instance
>*instance) {
>   fusion = instance->ctrl_context;
>
>   if (fusion->reply_frames_desc[0])
>-  pci_pool_free(fusion->reply_frames_desc_pool,
>+  dma_pool_free(fusion->reply_frames_desc_pool,
>   fusion->reply_frames_desc[0],
>   fusion->reply_frames_desc_phys[0]);
>
>-  if (fusion->reply_frames_desc_pool)
>-  pci_pool_destroy(fusion->reply_frames_desc_pool);
>+  dma_pool_destroy(fusion->reply_frames_desc_pool);
>
> }

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>
>--
>2.9.3


RE: [patch] scsi: megaraid_sas: array overflow in megasas_dump_frame()

2017-02-15 Thread Sumit Saxena
>-Original Message-
>From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
>Sent: Tuesday, February 14, 2017 10:09 PM
>To: Kashyap Desai; Shivasharan S
>Cc: Sumit Saxena; James E.J. Bottomley; Martin K. Petersen;
>megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; kernel-
>janit...@vger.kernel.org
>Subject: [patch] scsi: megaraid_sas: array overflow in
megasas_dump_frame()
>
>The "sz" variable is in terms of bytes, but we're treating the buffer as
an array of
>__le32 so we have to divide by 4.
>
>Fixes: def0eab3af86 ("scsi: megaraid_sas: enhance debug logs in OCR
context")
>Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index dc9f42e135bb..7ac9a9ee9bd4 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -2754,7 +2754,7 @@ megasas_dump_frame(void *mpi_request, int sz)
>   __le32 *mfp = (__le32 *)mpi_request;
>
>   printk(KERN_INFO "IO request frame:\n\t");
>-  for (i = 0; i < sz; i++) {
>+  for (i = 0; i < sz / sizeof(__le32); i++) {
>   if (i && ((i % 8) == 0))
>   printk("\n\t");
>   printk("%08x ", le32_to_cpu(mfp[i]));

Patch looks good. In last reply, Acked-by tag was not in proper format.
Fixing it now. Sorry for inconvenience.
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>


RE: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit

2017-02-15 Thread Sumit Saxena
>-Original Message-
>From: Arnd Bergmann [mailto:a...@arndb.de]
>Sent: Wednesday, February 15, 2017 2:52 AM
>To: James E.J. Bottomley; Martin K. Petersen
>Cc: Arnd Bergmann; Kashyap Desai; Sumit Saxena; Shivasharan S; Tomas
Henzl;
>Hannes Reinecke; Sasikumar Chandrasekaran;
>megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org
>Subject: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit
>
>When building with a dma_addr_t that is different from pointer size, we
get this
>warning:
>
>drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
>'megasas_make_prp_nvme':
>drivers/scsi/megaraid/megaraid_sas_fusion.c:1654:17: error: cast to
pointer
>from integer of different size [-Werror=int-to-pointer-cast]
>
>It's better to not pretend that the dma address is a pointer and instead
use a
>dma_addr_t consistently.
>
>Fixes: 33203bc4d61b ("scsi: megaraid_sas: NVME fast path io support")
>Signed-off-by: Arnd Bergmann <a...@arndb.de>
>---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index 750090119f81..29650ba669da 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -1619,7 +1619,8 @@ megasas_make_prp_nvme(struct megasas_instance
>*instance, struct scsi_cmnd *scmd,  {
>   int sge_len, offset, num_prp_in_chain = 0;
>   struct MPI25_IEEE_SGE_CHAIN64 *main_chain_element, *ptr_first_sgl;
>-  u64 *ptr_sgl, *ptr_sgl_phys;
>+  u64 *ptr_sgl;
>+  dma_addr_t ptr_sgl_phys;
>   u64 sge_addr;
>   u32 page_mask, page_mask_result;
>   struct scatterlist *sg_scmd;
>@@ -1651,14 +1652,14 @@ megasas_make_prp_nvme(struct megasas_instance
>*instance, struct scsi_cmnd *scmd,
>*/
>   page_mask = mr_nvme_pg_size - 1;
>   ptr_sgl = (u64 *)cmd->sg_frame;
>-  ptr_sgl_phys = (u64 *)cmd->sg_frame_phys_addr;
>+  ptr_sgl_phys = cmd->sg_frame_phys_addr;
>   memset(ptr_sgl, 0, instance->max_chain_frame_sz);
>
>   /* Build chain frame element which holds all prps except first*/
>   main_chain_element = (struct MPI25_IEEE_SGE_CHAIN64 *)
>   ((u8 *)sgl_ptr + sizeof(struct MPI25_IEEE_SGE_CHAIN64));
>
>-  main_chain_element->Address =
cpu_to_le64((uintptr_t)ptr_sgl_phys);
>+  main_chain_element->Address = cpu_to_le64(ptr_sgl_phys);
>   main_chain_element->NextChainOffset = 0;
>   main_chain_element->Flags = IEEE_SGE_FLAGS_CHAIN_ELEMENT |
>   IEEE_SGE_FLAGS_SYSTEM_ADDR |
>@@ -1696,16 +1697,15 @@ megasas_make_prp_nvme(struct megasas_instance
>*instance, struct scsi_cmnd *scmd,
>   scmd_printk(KERN_NOTICE,
>   scmd, "page boundary ptr_sgl: 0x%p\n",
>   ptr_sgl);
>-  ptr_sgl_phys++;
>-  *ptr_sgl =
>-  cpu_to_le64((uintptr_t)ptr_sgl_phys);
>+  ptr_sgl_phys += 8;
>+  *ptr_sgl = cpu_to_le64(ptr_sgl_phys);
>   ptr_sgl++;
>   num_prp_in_chain++;
>   }
>
>   *ptr_sgl = cpu_to_le64(sge_addr);
>   ptr_sgl++;
>-  ptr_sgl_phys++;
>+  ptr_sgl_phys += 8;
>   num_prp_in_chain++;
>
>   sge_addr += mr_nvme_pg_size;

Patch looks good. In last reply, Acked-by tag was not in proper format.
Fixing it now. Sorry for inconvenience.
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.9.0


RE: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit

2017-02-14 Thread Sumit Saxena
>-Original Message-
>From: Arnd Bergmann [mailto:a...@arndb.de]
>Sent: Wednesday, February 15, 2017 2:52 AM
>To: James E.J. Bottomley; Martin K. Petersen
>Cc: Arnd Bergmann; Kashyap Desai; Sumit Saxena; Shivasharan S; Tomas
Henzl;
>Hannes Reinecke; Sasikumar Chandrasekaran;
>megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org
>Subject: [PATCH] scsi: megaraid_sas: handle dma_addr_t right on 32-bit
>
>When building with a dma_addr_t that is different from pointer size, we
get this
>warning:
>
>drivers/scsi/megaraid/megaraid_sas_fusion.c: In function
>'megasas_make_prp_nvme':
>drivers/scsi/megaraid/megaraid_sas_fusion.c:1654:17: error: cast to
pointer
>from integer of different size [-Werror=int-to-pointer-cast]
>
>It's better to not pretend that the dma address is a pointer and instead
use a
>dma_addr_t consistently.

Patch looks good from review but we need to have some test runs before
acking this.
I will get back after some test runs.

Thanks,
Sumit
>
>Fixes: 33203bc4d61b ("scsi: megaraid_sas: NVME fast path io support")
>Signed-off-by: Arnd Bergmann <a...@arndb.de>
>---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index 750090119f81..29650ba669da 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -1619,7 +1619,8 @@ megasas_make_prp_nvme(struct megasas_instance
>*instance, struct scsi_cmnd *scmd,  {
>   int sge_len, offset, num_prp_in_chain = 0;
>   struct MPI25_IEEE_SGE_CHAIN64 *main_chain_element, *ptr_first_sgl;
>-  u64 *ptr_sgl, *ptr_sgl_phys;
>+  u64 *ptr_sgl;
>+  dma_addr_t ptr_sgl_phys;
>   u64 sge_addr;
>   u32 page_mask, page_mask_result;
>   struct scatterlist *sg_scmd;
>@@ -1651,14 +1652,14 @@ megasas_make_prp_nvme(struct megasas_instance
>*instance, struct scsi_cmnd *scmd,
>*/
>   page_mask = mr_nvme_pg_size - 1;
>   ptr_sgl = (u64 *)cmd->sg_frame;
>-  ptr_sgl_phys = (u64 *)cmd->sg_frame_phys_addr;
>+  ptr_sgl_phys = cmd->sg_frame_phys_addr;
>   memset(ptr_sgl, 0, instance->max_chain_frame_sz);
>
>   /* Build chain frame element which holds all prps except first*/
>   main_chain_element = (struct MPI25_IEEE_SGE_CHAIN64 *)
>   ((u8 *)sgl_ptr + sizeof(struct MPI25_IEEE_SGE_CHAIN64));
>
>-  main_chain_element->Address =
cpu_to_le64((uintptr_t)ptr_sgl_phys);
>+  main_chain_element->Address = cpu_to_le64(ptr_sgl_phys);
>   main_chain_element->NextChainOffset = 0;
>   main_chain_element->Flags = IEEE_SGE_FLAGS_CHAIN_ELEMENT |
>   IEEE_SGE_FLAGS_SYSTEM_ADDR |
>@@ -1696,16 +1697,15 @@ megasas_make_prp_nvme(struct megasas_instance
>*instance, struct scsi_cmnd *scmd,
>   scmd_printk(KERN_NOTICE,
>   scmd, "page boundary ptr_sgl: 0x%p\n",
>   ptr_sgl);
>-  ptr_sgl_phys++;
>-  *ptr_sgl =
>-  cpu_to_le64((uintptr_t)ptr_sgl_phys);
>+  ptr_sgl_phys += 8;
>+  *ptr_sgl = cpu_to_le64(ptr_sgl_phys);
>   ptr_sgl++;
>   num_prp_in_chain++;
>   }
>
>   *ptr_sgl = cpu_to_le64(sge_addr);
>   ptr_sgl++;
>-  ptr_sgl_phys++;
>+  ptr_sgl_phys += 8;
>   num_prp_in_chain++;
>
>   sge_addr += mr_nvme_pg_size;
>--
>2.9.0


RE: [patch] scsi: megaraid_sas: array overflow in megasas_dump_frame()

2017-02-14 Thread Sumit Saxena
>-Original Message-
>From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
>Sent: Tuesday, February 14, 2017 10:09 PM
>To: Kashyap Desai; Shivasharan S
>Cc: Sumit Saxena; James E.J. Bottomley; Martin K. Petersen;
>megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org; kernel-
>janit...@vger.kernel.org
>Subject: [patch] scsi: megaraid_sas: array overflow in
megasas_dump_frame()
>
>The "sz" variable is in terms of bytes, but we're treating the buffer as
an array of
>__le32 so we have to divide by 4.
>
>Fixes: def0eab3af86 ("scsi: megaraid_sas: enhance debug logs in OCR
context")
>Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index dc9f42e135bb..7ac9a9ee9bd4 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -2754,7 +2754,7 @@ megasas_dump_frame(void *mpi_request, int sz)
>   __le32 *mfp = (__le32 *)mpi_request;
>
>   printk(KERN_INFO "IO request frame:\n\t");
>-  for (i = 0; i < sz; i++) {
>+  for (i = 0; i < sz / sizeof(__le32); i++) {
>   if (i && ((i % 8) == 0))
>   printk("\n\t");
>   printk("%08x ", le32_to_cpu(mfp[i]));

Thanks for fixing this.
Acked-by: Sumit Saxena<sumit.sax...@broadcom.com>


RE: [bug report] megaraid_sas: Make PI enabled VD 8 byte DMA aligned

2017-02-14 Thread Sumit Saxena
>-Original Message-
>From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
>Sent: Tuesday, February 14, 2017 9:54 PM
>To: sumit.sax...@avagotech.com
>Cc: megaraidlinux@broadcom.com; linux-scsi@vger.kernel.org
>Subject: [bug report] megaraid_sas: Make PI enabled VD 8 byte DMA aligned
>
>Hello sumit.sax...@avagotech.com,
>
>The patch 0b48d12d0365: "megaraid_sas: Make PI enabled VD 8 byte DMA
>aligned" from Oct 15, 2015, leads to the following static checker
>warning:
>
>   drivers/scsi/megaraid/megaraid_sas_base.c:1784
>megasas_set_dynamic_target_properties()
>   warn: if statement not indented

I will post patch to fix this indentation issue.
>
>drivers/scsi/megaraid/megaraid_sas_base.c
>  1757  void megasas_set_dynamic_target_properties(struct scsi_device
*sdev)
>  1758  {
>  1759  u16 pd_index = 0, ld;
>  1760  u32 device_id;
>  1761  struct megasas_instance *instance;
>  1762  struct fusion_context *fusion;
>  1763  struct MR_PRIV_DEVICE *mr_device_priv_data;
>  1764  struct MR_PD_CFG_SEQ_NUM_SYNC *pd_sync;
>  1765  struct MR_LD_RAID *raid;
>  1766  struct MR_DRV_RAID_MAP_ALL *local_map_ptr;
>  1767
>  1768  instance = megasas_lookup_instance(sdev->host->host_no);
>  1769  fusion = instance->ctrl_context;
>  1770  mr_device_priv_data = sdev->hostdata;
>  1771
>  1772  if (!fusion || !mr_device_priv_data)
>  1773  return;
>  1774
>  1775  if (MEGASAS_IS_LOGICAL(sdev)) {
>  1776  device_id = ((sdev->channel % 2) *
>MEGASAS_MAX_DEV_PER_CHANNEL)
>  1777  + sdev->id;
>  1778  local_map_ptr =
fusion->ld_drv_map[(instance->map_id & 1)];
>  1779  ld = MR_TargetIdToLdGet(device_id,
local_map_ptr);
>  1780  if (ld >= instance->fw_supported_vd_count)
>  1781  return;
>  1782  raid = MR_LdRaidGet(ld, local_map_ptr);
>  1783
>  1784  if (raid->capability.ldPiMode ==
>MR_PROT_INFO_TYPE_CONTROLLER)
>  1785
blk_queue_update_dma_alignment(sdev->request_queue, 0x7);
>
>
>
>  1786
>  1787  mr_device_priv_data->is_tm_capable =
>  1788  raid->capability.tmCapable;
>  1789  } else if (instance->use_seqnum_jbod_fp) {
>  1790  pd_index = (sdev->channel *
>MEGASAS_MAX_DEV_PER_CHANNEL) +
>  1791  sdev->id;
>  1792  pd_sync = (void *)fusion->pd_seq_sync
>  1793  [(instance->pd_seq_map_id - 1) &
1];
>  1794  mr_device_priv_data->is_tm_capable =
>  1795
pd_sync->seq[pd_index].capability.tmCapable;
>  1796  }
>  1797  }
>
>
>regards,
>dan carpenter


RE: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI commands to be retried

2016-12-13 Thread Sumit Saxena
Adding direct email addresses of few people to avoid any filters.

Hannes/Martin/James/Tomas/Christoph,

Can you please comment on this?

Thanks,
Sumit

>-Original Message-
>From: Sumit Saxena [mailto:sumit.sax...@broadcom.com]
>Sent: Tuesday, December 13, 2016 6:50 PM
>To: 'linux-scsi'
>Subject: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI
>commands to be retried
>
>Hi all,
>
>I have query regarding usage of host_byte DID_REQUEUE vs DID_RESET
returned
>by LLD to SCSI mid layer.
>
>Let me give some background here.
>I am using megaraid_sas controller. megaraid_sas driver returns all
outstanding
>SCSI commands back to SCSI layer with DID_RESET host_byte before
resetting
>controller.
>The intent is- all these commands returned with DID_RESET before
controller
>reset should be retried by SCSI.
>
>In few distros, I have observed that if SYNCHRONIZE_CACHE command(should
be
>applicable for all non Read write commands) is outstanding before
resetting
>controller  and driver returns those commands back with DID_RESET then
>SYNCHRONIZE_CACHE command not retried but failed to upper layer but other
>READ/WRITE commands were not failed but retried. I was running filesystem
IOs
>and SYNHRONIZE_CACHE returned with error cause filesystem to go in READ
only
>mode.
>
>Later I checked and realized below commit was missing in that distro
kernel and
>seems to cause the problem-
>
>a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands
>
>But distro kernel has below commit-
>
>89fb4cd scsi: handle flush errors properly
>
>Issue does not hit on the kernels which don't have both commits but hits
when
>commit- "89fb4cd scsi: handle flush errors properly " is there but
commit-
>"a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS
commands" is
>missing.
>
>This issue is observed with mpt3sas driver as well and should be
applicable to all
>LLDs returning non read write commands with DID_RESET.
>
>Returning DID_REQUEUE instead of DID_RESET from driver solves the problem
>irrespective of whether these above mentioned commits are there or not in
>kernel.
>So I am thinking to use DID_REQUEUE instead of DID_RESET in megaraid_sas
>driver for all SCSI commands(not only limited to SYNCHRONIZE_CACHE or non
>read write commands) before resetting controller. As I mentioned intent
is those
>outstanding commands returned by driver before doing controller reset
should be
>retried and as soon as reset is complete, driver will be processing those
>commands. There is no sense key associated with SCSI commands returned.
>
>I browsed SCSI code and get to know DID_REQUEUE causes command to be
>retried by calling- scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY).
>This seems to be good enough for our requirement of commands to be
re-tried
>by SCSI layer.
>
>Please provide feedback if anyone forsee any issue with using DID_REQUEUE
for
>this use case.
>I will be doing some testing with DID_REQUEUE in place of DID_RESET in
>megaraid_sas driver.
>
>I have attached here a proposed patch for megaraid_sas driver.
>If there are no concerns, I will send this patch to SCSI mailing list.
>
>Thanks,
>Sumit
--- Begin Message ---
Driver returns outstanding SCSI commands to SCSI layer with host_byte
set to DID_RESET before resetting controller so that SCSI layer should
retry
those commands.
Sending DID_RESET for non RW commands(e.g SYNCHRONIZE_CACHE) may cause
those commands getting failed and returning I/O erros on few distros which
has included commit- 89fb4cd scsi: handle flush errors properly but missed
commit- a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS
commands.
However Read write commands returned with DID_RESET are not failed but
retried.

DID_REQUEUE seems safer to use instead of DID_RESET for all outstanding
commands before doing chip reset as it serves purpose of getting all
commands
to be retried by SCSI layer.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 4 ++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 6484c38..959ce3e 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1662,7 +1662,7 @@ megasas_queue_command(struct Scsi_Host *shost,
struct scsi_cmnd *scmd)
/* Check for an mpio path and adjust behavior */
if (atomic_read(>adprecovery) ==
MEGASAS_ADPRESET_SM_INFAULT) {
if (megasas_check_mpio_paths(instance, scmd) ==
-   (DID_RESET << 16)) {
+   

SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI commands to be retried

2016-12-13 Thread Sumit Saxena
Hi all,

I have query regarding usage of host_byte DID_REQUEUE vs DID_RESET
returned by LLD to SCSI mid layer.

Let me give some background here.
I am using megaraid_sas controller. megaraid_sas driver returns all
outstanding SCSI commands back to SCSI layer with DID_RESET host_byte
before resetting controller.
The intent is- all these commands returned with DID_RESET before
controller reset should be retried by SCSI.

In few distros, I have observed that if SYNCHRONIZE_CACHE command(should
be applicable for all non Read write commands) is outstanding before
resetting controller  and driver returns those commands back with
DID_RESET then SYNCHRONIZE_CACHE command not retried but failed to upper
layer
but other READ/WRITE commands were not failed but retried. I was running
filesystem IOs and SYNHRONIZE_CACHE returned with error cause filesystem
to go in READ only mode.

Later I checked and realized below commit was missing in that distro
kernel and seems to cause the problem-

a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands

But distro kernel has below commit-

89fb4cd scsi: handle flush errors properly

Issue does not hit on the kernels which don't have both commits but hits
when commit- "89fb4cd scsi: handle flush errors properly " is there
but commit-  "a621bac scsi_lib: correctly retry failed zero length
REQ_TYPE_FS commands" is missing.

This issue is observed with mpt3sas driver as well and should be
applicable to all LLDs returning non read write commands with DID_RESET.

Returning DID_REQUEUE instead of DID_RESET from driver solves the problem
irrespective of whether these above mentioned commits are there or not in
kernel.
So I am thinking to use DID_REQUEUE instead of DID_RESET in megaraid_sas
driver for all SCSI commands(not only limited to SYNCHRONIZE_CACHE or non
read write commands)
before resetting controller. As I mentioned intent is those outstanding
commands returned by driver before doing controller reset should be
retried and as soon as reset is complete,
driver will be processing those commands. There is no sense key associated
with SCSI commands returned.

I browsed SCSI code and get to know DID_REQUEUE causes command to be
retried by calling- scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY).
This seems to be good enough for our requirement of commands to be
re-tried by SCSI layer.

Please provide feedback if anyone forsee any issue with using DID_REQUEUE
for this use case.
I will be doing some testing with DID_REQUEUE in place of DID_RESET in
megaraid_sas driver.

I have attached here a proposed patch for megaraid_sas driver.
If there are no concerns, I will send this patch to SCSI mailing list.

Thanks,
Sumit
--- Begin Message ---
Driver returns outstanding SCSI commands to SCSI layer with host_byte
set to DID_RESET before resetting controller so that SCSI layer should
retry
those commands.
Sending DID_RESET for non RW commands(e.g SYNCHRONIZE_CACHE) may cause
those commands getting failed and returning I/O erros on few distros which
has included commit- 89fb4cd scsi: handle flush errors properly but missed
commit- a621bac scsi_lib: correctly retry failed zero length REQ_TYPE_FS
commands.
However Read write commands returned with DID_RESET are not failed but
retried.

DID_REQUEUE seems safer to use instead of DID_RESET for all outstanding
commands before doing chip reset as it serves purpose of getting all
commands
to be retried by SCSI layer.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 4 ++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 6484c38..959ce3e 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1662,7 +1662,7 @@ megasas_queue_command(struct Scsi_Host *shost,
struct scsi_cmnd *scmd)
/* Check for an mpio path and adjust behavior */
if (atomic_read(>adprecovery) ==
MEGASAS_ADPRESET_SM_INFAULT) {
if (megasas_check_mpio_paths(instance, scmd) ==
-   (DID_RESET << 16)) {
+   (DID_REQUEUE << 16)) {
return SCSI_MLQUEUE_HOST_BUSY;
} else {
scmd->result = DID_NO_CONNECT << 16;
@@ -2483,7 +2483,7 @@ static int megasas_wait_for_outstanding(struct
megasas_instance *instance)
struct megasas_cmd, list);
list_del_init(_cmd->list);
if (reset_cmd->scmd) {
-   reset_cmd->scmd->result = DID_RESET << 16;
+   reset_cmd->scmd->result = DID_REQUEUE <

RE: [PATCH RESEND] Update 3ware driver email addresses

2016-12-11 Thread Sumit Saxena
>-Original Message-
>From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>ow...@vger.kernel.org] On Behalf Of adam radford
>Sent: Saturday, December 10, 2016 12:38 AM
>To: linux-scsi
>Subject: [PATCH RESEND] Update 3ware driver email addresses
>
>This change updates the 3ware drivers (3w-, 3w-9xxx, 3w-sas) email
>addresses from linuxr...@lsi.com to aradf...@gmail.com, since the old email
>address doesn't exist.
>
>This patch was updated to remove www.lsi.com text.
>
>Signed-off-by: Adam Radford <aradf...@gmail.com>
>---
> MAINTAINERS| 2 +-
> drivers/scsi/3w-9xxx.c | 9 +++--
> drivers/scsi/3w-9xxx.h | 9 +++--
> drivers/scsi/3w-sas.c  | 7 ++-
> drivers/scsi/3w-sas.h  | 7 ++-
> drivers/scsi/3w-.c | 7 ++-
> drivers/scsi/3w-.h | 7 ++-
> 7 files changed, 15 insertions(+), 33 deletions(-)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index b3a7774..1b5ddd0 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -138,7 +138,7 @@ S:  Maintained
> F: drivers/net/ethernet/3com/typhoon*
>
> 3WARE SAS/SATA-RAID SCSI DRIVERS (3W-, 3W-9XXX, 3W-SAS)
>-M: Adam Radford <linuxr...@lsi.com>
>+M: Adam Radford <aradf...@gmail.com>
> L: linux-scsi@vger.kernel.org
> W: http://www.lsi.com
> S: Supported
>diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c index
>a56a7b2..316f87f 100644
>--- a/drivers/scsi/3w-9xxx.c
>+++ b/drivers/scsi/3w-9xxx.c
>@@ -1,8 +1,8 @@
> /*
>3w-9xxx.c -- 3ware 9000 Storage Controller device driver for Linux.
>
>-   Written By: Adam Radford <linuxr...@lsi.com>
>-   Modifications By: Tom Couch <linuxr...@lsi.com>
>+   Written By: Adam Radford <aradf...@gmail.com>
>+   Modifications By: Tom Couch
>
>Copyright (C) 2004-2009 Applied Micro Circuits Corporation.
>Copyright (C) 2010 LSI Corporation.
>@@ -41,10 +41,7 @@
>Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
> USA
>
>Bugs/Comments/Suggestions should be mailed to:
>-   linuxr...@lsi.com
>-
>-   For more information, goto:
>-   http://www.lsi.com
>+   aradf...@gmail.com
>
>Note: This version of the driver does not contain a bundled firmware
>  image.
>diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h index
>0fdc83c..b6c208c 100644
>--- a/drivers/scsi/3w-9xxx.h
>+++ b/drivers/scsi/3w-9xxx.h
>@@ -1,8 +1,8 @@
> /*
>3w-9xxx.h -- 3ware 9000 Storage Controller device driver for Linux.
>
>-   Written By: Adam Radford <linuxr...@lsi.com>
>-   Modifications By: Tom Couch <linuxr...@lsi.com>
>+   Written By: Adam Radford <aradf...@gmail.com>
>+   Modifications By: Tom Couch
>
>Copyright (C) 2004-2009 Applied Micro Circuits Corporation.
>Copyright (C) 2010 LSI Corporation.
>@@ -41,10 +41,7 @@
>Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
> USA
>
>Bugs/Comments/Suggestions should be mailed to:
>-   linuxr...@lsi.com
>-
>-   For more information, goto:
>-   http://www.lsi.com
>+   aradf...@gmail.com
> */
>
> #ifndef _3W_9XXX_H
>diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c index
>f837485..970d8fa
>100644
>--- a/drivers/scsi/3w-sas.c
>+++ b/drivers/scsi/3w-sas.c
>@@ -1,7 +1,7 @@
> /*
>3w-sas.c -- LSI 3ware SAS/SATA-RAID Controller device driver for Linux.
>
>-   Written By: Adam Radford <linuxr...@lsi.com>
>+   Written By: Adam Radford <aradf...@gmail.com>
>
>Copyright (C) 2009 LSI Corporation.
>
>@@ -43,10 +43,7 @@
>LSI 3ware 9750 6Gb/s SAS/SATA-RAID
>
>Bugs/Comments/Suggestions should be mailed to:
>-   linuxr...@lsi.com
>-
>-   For more information, goto:
>-   http://www.lsi.com
[]
>+   aradf...@gmail.com
>
>History
>---
>diff --git a/drivers/scsi/3w-sas.h b/drivers/scsi/3w-sas.h index
>fec6449..05e77d8
>100644
>--- a/drivers/scsi/3w-sas.h
>+++ b/drivers/scsi/3w-sas.h
>@@ -1,7 +1,7 @@
> /*
>3w-sas.h -- LSI 3ware SAS/SATA-RAID Controller device driver for Linux.
>
>-   Written By: Adam Radford <linuxr...@lsi.com>
>+   Written By: Adam Radford <aradf...@gmail.com>
>
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>Copyright (C) 2009 LSI Corporation.
>
>@@ -39,10 +39,7 @@
>Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
> USA
>
>Bugs/Comments/Suggestions should be mailed to:
>-   linuxr...@lsi.com
>-
>-   For more information, goto:
>-   http://www.lsi.com
>+   aradf...@gmail.com
> */
>
> #ifndef _3W_SAS_H
>diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c index

RE: [PATCH] megaraid_sas: switch to pci_alloc_irq_vectors

2016-12-06 Thread Sumit Saxena
@ -6155,9 +6147,15 @@ static void megasas_shutdown_controller(struct
>megasas_instance *instance,
>   goto fail_ready_state;
>
>   /* Now re-enable MSI-X */
>-  if (instance->msix_vectors &&
>-  pci_enable_msix_exact(instance->pdev, instance->msixentry,
>-instance->msix_vectors))
>+  if (instance->msix_vectors) {
>+  irq_flags = PCI_IRQ_MSIX;
>+  if (smp_affinity_enable)
>+  irq_flags |= PCI_IRQ_AFFINITY;
>+  }
>+  rval = pci_alloc_irq_vectors(instance->pdev, 1,
>+   instance->msix_vectors ?
>+       instance->msix_vectors : 1,
irq_flags);
>+  if (rval < 0)
>   goto fail_reenable_msix;
>
>   if (instance->ctrl_context) {
>@@ -6330,7 +6328,7 @@ static void megasas_detach_one(struct pci_dev
*pdev)
>   megasas_destroy_irqs(instance);
>
>   if (instance->msix_vectors)
>-  pci_disable_msix(instance->pdev);
>+  pci_free_irq_vectors(instance->pdev);
>
>   if (instance->ctrl_context) {
>   megasas_release_fusion(instance);
>@@ -6425,7 +6423,7 @@ static void megasas_shutdown(struct pci_dev *pdev)
>   megasas_destroy_irqs(instance);
>
>   if (instance->msix_vectors)
>-  pci_disable_msix(instance->pdev);
>+  pci_free_irq_vectors(instance->pdev);
> }
>
Looks good to me. There are few patches for megaraid_sas pending posted by
Sasikumar so either you have to rebase this patch once Sasi's patches are
committed
Or Sasi has to rebase his patches once this patch are applied. If you are
ok,  then I can post this patch once Sasi's patches are committed.

Acked by: Sumit Saxena<sumit.sax...@broadcom.com>

> /**
>--
>1.8.5.6
>
>--
>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
--
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


RE: [PATCH] megaraid-sas: request irqs later

2016-11-15 Thread Sumit Saxena
>-Original Message-
>From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
>Sent: Tuesday, November 15, 2016 5:18 AM
>To: Tomas Henzl
>Cc: linux-scsi@vger.kernel.org; sumit.sax...@broadcom.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH] megaraid-sas: request irqs later
>
>>>>>> "Tomas" == Tomas Henzl <the...@redhat.com> writes:
>
>Tomas> It is not good when an irq arrives before driver structures are
>Tomas> allocated.
>
>Sumit, Kashyap: Please review!

Looks good.. I think I have acked this patch earlier also.
Acked-by: Sumit Saxena<sumit.sax...@broadcom.com>
>
>--
>Martin K. Petersen Oracle Linux Engineering
--
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


RE: [PATCH 4/5] megaraid_sas: scsi-mq support

2016-11-11 Thread Sumit Saxena
>-Original Message-
>From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
>Sent: Friday, November 11, 2016 3:15 PM
>To: Martin K. Petersen
>Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
>s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke
>Subject: [PATCH 4/5] megaraid_sas: scsi-mq support
>
>This patch enables full scsi multiqueue support. But as I have been
seeing
>performance regressions I've also added a module parameter 'use_blk_mq',
>allowing multiqueue to be switched off if required.

I may need sometime to comment on this patch. I will have some performance
runs with this patch. Can you share your test configuration details?

Thanks,
Sumit
>
>Signed-off-by: Hannes Reinecke <h...@suse.com>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c   | 22 +
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 38
>+
> 2 files changed, 50 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index d580406..1af47e6 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -48,6 +48,7 @@
> #include 
> #include 
> #include 
>+#include 
>
> #include 
> #include 
>@@ -104,6 +105,9 @@
> module_param(scmd_timeout, int, S_IRUGO);
>MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default
>90s. See megasas_reset_timer.");
>
>+bool use_blk_mq = true;
>+module_param_named(use_blk_mq, use_blk_mq, bool, 0);
>+
> MODULE_LICENSE("GPL");
> MODULE_VERSION(MEGASAS_VERSION);
> MODULE_AUTHOR("megaraidlinux@avagotech.com");
>@@ -1882,6 +1886,17 @@ static void megasas_slave_destroy(struct
scsi_device
>*sdev)
>   sdev->hostdata = NULL;
> }
>
>+static int megasas_map_queues(struct Scsi_Host *shost) {
>+  struct megasas_instance *instance = (struct megasas_instance *)
>+  shost->hostdata;
>+
>+  if (!instance->ctrl_context)
>+  return 0;
>+
>+  return blk_mq_pci_map_queues(>tag_set, instance->pdev, 0);
}
>+
> /*
> * megasas_complete_outstanding_ioctls - Complete outstanding ioctls
after a
> *   kill adapter
>@@ -2986,6 +3001,7 @@ struct device_attribute *megaraid_host_attrs[] = {
>   .slave_configure = megasas_slave_configure,
>   .slave_alloc = megasas_slave_alloc,
>   .slave_destroy = megasas_slave_destroy,
>+  .map_queues = megasas_map_queues,
>   .queuecommand = megasas_queue_command,
>   .eh_target_reset_handler = megasas_reset_target,
>   .eh_abort_handler = megasas_task_abort, @@ -5610,6 +5626,12 @@
>static int megasas_io_attach(struct megasas_instance *instance)
>   host->max_id = MEGASAS_MAX_DEV_PER_CHANNEL;
>   host->max_lun = MEGASAS_MAX_LUN;
>   host->max_cmd_len = 16;
>+  host->nr_hw_queues = instance->msix_vectors ?
>+  instance->msix_vectors : 1;
>+  if (use_blk_mq) {
>+  host->can_queue = instance->max_scsi_cmds /
>host->nr_hw_queues;
>+  host->use_blk_mq = 1;
>+  }
>
>   /*
>* Notify the mid-layer about the new controller diff --git
>a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index eb3cb0f..aba53c0 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -1703,6 +1703,7 @@ static int megasas_create_sg_sense_fusion(struct
>megasas_instance *instance)
>   struct IO_REQUEST_INFO io_info;
>   struct fusion_context *fusion;
>   struct MR_DRV_RAID_MAP_ALL *local_map_ptr;
>+  u16 msix_index;
>   u8 *raidLUN;
>
>   device_id = MEGASAS_DEV_INDEX(scp);
>@@ -1792,11 +1793,13 @@ static int megasas_create_sg_sense_fusion(struct
>megasas_instance *instance)
>   fp_possible = io_info.fpOkForIo;
>   }
>
>-  /* Use raw_smp_processor_id() for now until cmd->request->cpu is
>CPU
>- id by default, not CPU group id, otherwise all MSI-X queues
>won't
>- be utilized */
>-  cmd->request_desc->SCSIIO.MSIxIndex = instance->msix_vectors ?
>-  raw_smp_processor_id() % instance->msix_vectors : 0;
>+  if (shost_use_blk_mq(instance->host)) {
>+  u32 blk_tag = blk_mq_unique_tag(scp->request);
>+  msix_index = blk_mq_unique_tag_to_hwq(blk_tag);
>+  } else
>+  msix_index = instance->msix_vectors ?
>+  raw_sm

RE: [PATCH 3/5] megaraid_sas: do not crash on invalid completion

2016-11-11 Thread Sumit Saxena
>-Original Message-
>From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
>Sent: Friday, November 11, 2016 3:15 PM
>To: Martin K. Petersen
>Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
>s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke
>Subject: [PATCH 3/5] megaraid_sas: do not crash on invalid completion
>
>Avoid a kernel oops when receiving an invalid command completion.
scmd_local set to NULL(for cases MPI2_FUNCTION_SCSI_IO_REQUEST and
MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST) will be serious bug(either in driver
or firmware) which should be debugged
and driver should not really continue beyond that. This indicates that
driver internal frames are corrupted. If needed, whenever driver detects
it, it can mark the adapter as dead(stopping further activities).
If OS is installed behind megasas controller then after declaring adapter
dead, system reboot will be required. Kernel panic may give here more
information whenever this condition hits so we kept it like this.
If you are facing this issue, please share the details. I will work on
this.

Thanks,
Sumit

>
>Signed-off-by: Hannes Reinecke <h...@suse.com>
>---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index 38137de..eb3cb0f 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -2298,13 +2298,15 @@ static void megasas_build_ld_nonrw_fusion(struct
>megasas_instance *instance,
>   break;
>   case MPI2_FUNCTION_SCSI_IO_REQUEST:  /*Fast Path IO.*/
>   /* Update load balancing info */
>-  device_id = MEGASAS_DEV_INDEX(scmd_local);
>-  lbinfo = >load_balance_info[device_id];
>-  if (cmd_fusion->scmd->SCp.Status &
>-  MEGASAS_LOAD_BALANCE_FLAG) {
>-
>atomic_dec(>scsi_pending_cmds[cmd_fusion->pd_r1_lb]);
>-  cmd_fusion->scmd->SCp.Status &=
>-  ~MEGASAS_LOAD_BALANCE_FLAG;
>+  if (scmd_local) {
>+  device_id = MEGASAS_DEV_INDEX(scmd_local);
>+  lbinfo =
>>load_balance_info[device_id];
>+  if (cmd_fusion->scmd->SCp.Status &
>+  MEGASAS_LOAD_BALANCE_FLAG) {
>+
>atomic_dec(>scsi_pending_cmds[cmd_fusion->pd_r1_lb]);
>+  cmd_fusion->scmd->SCp.Status &=
>+
>~MEGASAS_LOAD_BALANCE_FLAG;
>+  }
>   }
>   if (reply_descript_type ==
>   MPI2_RPY_DESCRIPT_FLAGS_SCSI_IO_SUCCESS) { @@
>-2315,6 +2317,12 @@ static void megasas_build_ld_nonrw_fusion(struct
>megasas_instance *instance,
>   /* Fall thru and complete IO */
>   case MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST: /* LD-IO
>Path */
>   /* Map the FW Cmd Status */
>+  if (!scmd_local) {
>+  dev_err(>pdev->dev,
>+  "cmd[%d:%d] already completed\n",
>+  MSIxIndex, smid);
>+  break;
>+  }
>   map_cmd_status(cmd_fusion, status, extStatus);
>   scsi_io_req->RaidContext.status = 0;
>   scsi_io_req->RaidContext.exStatus = 0;
>--
>1.8.5.6
>
>--
>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
--
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


RE: [PATCH 1/5] megaraid_sas: switch to pci_alloc_irq_vectors

2016-11-11 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Friday, November 11, 2016 3:15 PM
>To: Martin K. Petersen
>Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
>s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke
>Subject: [PATCH 1/5] megaraid_sas: switch to pci_alloc_irq_vectors
>
>Cleanup the MSI-X handling allowing us to use the PCI-layer provided
vector
>allocation.
>
>Signed-off-by: Hannes Reinecke <h...@suse.com>
>---
> drivers/scsi/megaraid/megaraid_sas.h  |  1 -
> drivers/scsi/megaraid/megaraid_sas_base.c | 63
++-
> 2 files changed, 29 insertions(+), 35 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>b/drivers/scsi/megaraid/megaraid_sas.h
>index ca86c88..8f1d2b4 100644
>--- a/drivers/scsi/megaraid/megaraid_sas.h
>+++ b/drivers/scsi/megaraid/megaraid_sas.h
>@@ -2118,7 +2118,6 @@ struct megasas_instance {
>   u32 ctrl_context_pages;
>   struct megasas_ctrl_info *ctrl_info;
>   unsigned int msix_vectors;
>-  struct msix_entry msixentry[MEGASAS_MAX_MSIX_QUEUES];
>   struct megasas_irq_context
>irq_context[MEGASAS_MAX_MSIX_QUEUES];
>   u64 map_id;
>   u64 pd_seq_map_id;
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index 3236632..e7e3efd 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -4843,7 +4843,7 @@ int megasas_set_crash_dump_params(struct
>megasas_instance *instance,  }
>
> /*
>- * megasas_setup_irqs_msix -  register legacy interrupts.
>+ * megasas_setup_irqs_ioapic -register legacy
interrupts.
>  * @instance: Adapter soft state
>  *
>  * Do not enable interrupt, only setup ISRs.
>@@ -4858,8 +4858,9 @@ int megasas_set_crash_dump_params(struct
>megasas_instance *instance,
>   pdev = instance->pdev;
>   instance->irq_context[0].instance = instance;
>   instance->irq_context[0].MSIxIndex = 0;
>-  if (request_irq(pdev->irq, instance->instancet->service_isr,
>-  IRQF_SHARED, "megasas", >irq_context[0])) {
>+  if (request_irq(pci_irq_vector(pdev, 0),
>+  instance->instancet->service_isr, IRQF_SHARED,
>+  "megasas", >irq_context[0])) {
>   dev_err(>pdev->dev,
>   "Failed to register IRQ from %s %d\n",
>   __func__, __LINE__);
>@@ -4880,28 +4881,23 @@ int megasas_set_crash_dump_params(struct
>megasas_instance *instance,  static int  megasas_setup_irqs_msix(struct
>megasas_instance *instance, u8 is_probe)  {
>-  int i, j, cpu;
>+  int i, j;
>   struct pci_dev *pdev;
>
>   pdev = instance->pdev;
>
>   /* Try MSI-x */
>-  cpu = cpumask_first(cpu_online_mask);
>   for (i = 0; i < instance->msix_vectors; i++) {
>   instance->irq_context[i].instance = instance;
>   instance->irq_context[i].MSIxIndex = i;
>-  if (request_irq(instance->msixentry[i].vector,
>+  if (request_irq(pci_irq_vector(pdev, i),
>   instance->instancet->service_isr, 0, "megasas",
>   >irq_context[i])) {
>   dev_err(>pdev->dev,
>   "Failed to register IRQ for vector %d.\n",
i);
>-  for (j = 0; j < i; j++) {
>-  if (smp_affinity_enable)
>-  irq_set_affinity_hint(
>-
instance->msixentry[j].vector,
>NULL);
>-  free_irq(instance->msixentry[j].vector,
>-  >irq_context[j]);
>-  }
>+  for (j = 0; j < i; j++)
>+  free_irq(pci_irq_vector(pdev, j),
>+   >irq_context[j]);
>   /* Retry irq register for IO_APIC*/
>   instance->msix_vectors = 0;
>   if (is_probe)
>@@ -4909,14 +4905,6 @@ int megasas_set_crash_dump_params(struct
>megasas_instance *instance,
>   else
>   return -1;
>   }
>-  if (smp_affinity_enable) {
>-  if
(irq_set_affinity_hint(instance->msixentry[i].vector,
>-  get_cpu_mask(cpu)))
>-  dev_err(>pdev->dev,
>- 

RE: [PATCH 5/5] megaraid_sas: add mmio barrier after register writes

2016-11-11 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Friday, November 11, 2016 3:15 PM
>To: Martin K. Petersen
>Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
>s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke
>Subject: [PATCH 5/5] megaraid_sas: add mmio barrier after register writes
>
>The megaraid_sas HBA only has a single register for I/O submission, which
will be
>hit pretty hard with scsi-mq. To ensure that the PCI writes have made it
across we
>need to add a mmio barrier after each write; otherwise I've been seeing
spurious
>command completions and I/O stalls.
>
>Signed-off-by: Hannes Reinecke <h...@suse.com>
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>index aba53c0..729a654 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>@@ -196,6 +196,7 @@ inline void megasas_return_cmd_fusion(struct
>megasas_instance *instance,
>   le32_to_cpu(req_desc->u.low));
>
>   writeq(req_data, >reg_set->inbound_low_queue_port);
>+  mmiowb();
> #else
>   unsigned long flags;
>
>--
>1.8.5.6
--
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


RE: [PATCH 2/5] megaraid_sas: avoid calling megasas_lookup_instance()

2016-11-11 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Friday, November 11, 2016 3:15 PM
>To: Martin K. Petersen
>Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux-
>s...@vger.kernel.org; Hannes Reinecke; Hannes Reinecke
>Subject: [PATCH 2/5] megaraid_sas: avoid calling
megasas_lookup_instance()
>
>It's quite pointless to call megasas_lookup_instance() if we can derive a
pointer
>to the structure directly.
>
>Signed-off-by: Hannes Reinecke <h...@suse.com>
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>---
> drivers/scsi/megaraid/megaraid_sas.h|  3 ++-
> drivers/scsi/megaraid/megaraid_sas_base.c   | 24
+++-
> drivers/scsi/megaraid/megaraid_sas_fusion.c |  2 +-
> 3 files changed, 14 insertions(+), 15 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>b/drivers/scsi/megaraid/megaraid_sas.h
>index 8f1d2b4..296e692 100644
>--- a/drivers/scsi/megaraid/megaraid_sas.h
>+++ b/drivers/scsi/megaraid/megaraid_sas.h
>@@ -2375,7 +2375,8 @@ void megasas_return_mfi_mpt_pthr(struct
>megasas_instance *instance,  int megasas_cmd_type(struct scsi_cmnd *cmd);
>void megasas_setup_jbod_map(struct megasas_instance *instance);
>
>-void megasas_update_sdev_properties(struct scsi_device *sdev);
>+void megasas_update_sdev_properties(struct megasas_instance *instance,
>+  struct scsi_device *sdev);
> int megasas_reset_fusion(struct Scsi_Host *shost, int reason);  int
>megasas_task_abort_fusion(struct scsi_cmnd *scmd);  int
>megasas_reset_target_fusion(struct scsi_cmnd *scmd); diff --git
>a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index e7e3efd..d580406 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -1736,22 +1736,22 @@ static struct megasas_instance
>*megasas_lookup_instance(u16 host_no)
> /*
> * megasas_update_sdev_properties - Update sdev structure based on
>controller's FW capabilities
> *
>+* @instance: Megasas instance
> * @sdev: OS provided scsi device
> *
> * Returns void
> */
>-void megasas_update_sdev_properties(struct scsi_device *sdev)
>+void megasas_update_sdev_properties(struct megasas_instance *instance,
>+  struct scsi_device *sdev)
> {
>   u16 pd_index = 0;
>   u32 device_id, ld;
>-  struct megasas_instance *instance;
>   struct fusion_context *fusion;
>   struct MR_PRIV_DEVICE *mr_device_priv_data;
>   struct MR_PD_CFG_SEQ_NUM_SYNC *pd_sync;
>   struct MR_LD_RAID *raid;
>   struct MR_DRV_RAID_MAP_ALL *local_map_ptr;
>
>-  instance = megasas_lookup_instance(sdev->host->host_no);
>   fusion = instance->ctrl_context;
>   mr_device_priv_data = sdev->hostdata;
>
>@@ -1780,13 +1780,11 @@ void megasas_update_sdev_properties(struct
>scsi_device *sdev)
>   }
> }
>
>-static void megasas_set_device_queue_depth(struct scsi_device *sdev)
>+static void megasas_set_device_queue_depth(struct megasas_instance
>*instance,
>+ struct scsi_device *sdev)
> {
>   u16 pd_index = 0;
>   int ret = DCMD_FAILED;
>-  struct megasas_instance *instance;
>-
>-  instance = megasas_lookup_instance(sdev->host->host_no);
>
>   if (sdev->channel < MEGASAS_MAX_PD_CHANNELS) {
>   pd_index = (sdev->channel *
>MEGASAS_MAX_DEV_PER_CHANNEL) + sdev->id; @@ -1822,9 +1820,9 @@
>static void megasas_set_device_queue_depth(struct scsi_device *sdev)
static int
>megasas_slave_configure(struct scsi_device *sdev)  {
>   u16 pd_index = 0;
>-  struct megasas_instance *instance;
>+  struct megasas_instance *instance = (struct megasas_instance *)
>+  sdev->host->hostdata;
>
>-  instance = megasas_lookup_instance(sdev->host->host_no);
>   if (instance->pd_list_not_supported) {
>   if (sdev->channel < MEGASAS_MAX_PD_CHANNELS &&
>   sdev->type == TYPE_DISK) {
>@@ -1835,8 +1833,8 @@ static int megasas_slave_configure(struct
scsi_device
>*sdev)
>   return -ENXIO;
>   }
>   }
>-  megasas_set_device_queue_depth(sdev);
>-  megasas_update_sdev_properties(sdev);
>+  megasas_set_device_queue_depth(instance, sdev);
>+  megasas_update_sdev_properties(instance, sdev);
>
>   /*
>* The RAID firmware may require extended timeouts.
>@@ -1850,10 +1848,10 @@ static int megasas_slave_configure(struct
>scsi_device *sdev)  static

[PATCH] megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression caused by commit 1e793f6fc0db920400574211c48f9157a37e3945

2016-11-09 Thread Sumit Saxena
This patch will fix regression caused by below commit-
1e793f6 scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
devices

The problem was MEGASAS_IS_LOGICAL macro does not have braces and because of 
above commit 
using this macro was exposing lot of non-existing SCSI devices(all SCSI 
commands to channels-1,2,3 was
returned as SUCCESS-DID_OK by driver).

Fixes: 1e793f6fc0db920400574211c48f9157a37e3945 
Reported-by: Jens Axboe <ax...@kernel.dk>
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Tested-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index ca86c88..3aaea71 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2233,7 +2233,7 @@ struct megasas_instance_template {
 };
 
 #define MEGASAS_IS_LOGICAL(scp)
\
-   (scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1
+   ((scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1)
 
 #define MEGASAS_DEV_INDEX(scp) \
(((scp->device->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) +   \
-- 
1.8.3.1

--
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


RE: [PATCH] megaraid-sas: request irqs later

2016-11-02 Thread Sumit Saxena
>-Original Message-
>From: Tomas Henzl [mailto:the...@redhat.com]
>Sent: Tuesday, November 01, 2016 10:02 PM
>To: linux-scsi@vger.kernel.org
>Cc: sumit.sax...@broadcom.com; kashyap.de...@broadcom.com
>Subject: [PATCH] megaraid-sas: request irqs later
>
>It is not good when an irq arrives before driver structures are
allocated.
>
>Signed-off-by: Tomas Henzl <the...@redhat.com>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index c3efcc7255..e207410150 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -5155,11 +5155,6 @@ static int megasas_init_fw(struct megasas_instance
>*instance)
>   tasklet_init(>isr_tasklet, instance->instancet->tasklet,
>   (unsigned long)instance);
>
>-  if (instance->msix_vectors ?
>-  megasas_setup_irqs_msix(instance, 1) :
>-  megasas_setup_irqs_ioapic(instance))
>-  goto fail_setup_irqs;
>-
>   instance->ctrl_info = kzalloc(sizeof(struct megasas_ctrl_info),
>   GFP_KERNEL);
>   if (instance->ctrl_info == NULL)
>@@ -5175,6 +5170,10 @@ static int megasas_init_fw(struct megasas_instance
>*instance)
>   if (instance->instancet->init_adapter(instance))
>   goto fail_init_adapter;
>
>+  if (instance->msix_vectors ?
>+  megasas_setup_irqs_msix(instance, 1) :
>+  megasas_setup_irqs_ioapic(instance))
>+  goto fail_init_adapter;
>
>   instance->instancet->enable_intr(instance);
>
>@@ -5314,9 +5313,8 @@ static int megasas_init_fw(struct megasas_instance
>*instance)
>
> fail_get_pd_list:
>   instance->instancet->disable_intr(instance);
>-fail_init_adapter:
>   megasas_destroy_irqs(instance);
>-fail_setup_irqs:
>+fail_init_adapter:
>   if (instance->msix_vectors)
>   pci_disable_msix(instance->pdev);
>   instance->msix_vectors = 0;
Looks good to me. Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.7.4
--
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


[PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-20 Thread Sumit Saxena
>From previous patch we have below changes in v2 -
1.  Updated change log.  Provided more detail in change log.
2.  Agreed to remove module parameter. If we remove module parameter, we 
can ask customer to disable WCE on drive to get similar impact.
3.  Always Send SYNCHRONIZE_CACHE  for JBOD (non Raid) Device to Firmware.
 
Current megaraid_sas driver returns SYNCHRONIZE_CACHE(related to Drive
Cache)  command  back to SCSI layer without sending it down to firmware as
firmware supposed to take care of flushing disk cache for all drives
belongs to Virtual Disk at the time of system reboot/shutdown.
 
We evaluate and understood that for Raid Volume, why driver should not
send SYNC_CACHE command to the Firmware.
There may be a some reason in past, but now it looks to be not required and
we have fixed this issue as part of this patch.

Commit- " 02b01e0 [SCSI] megaraid_sas: return sync cache call with success"
added the code in driver to return SYNCHRONIZE_CACHE without sending it to 
firmware back in 2007. Earlier MR was mainly for Virtual Disk,
so same code continue for JBOD as well whenever JBOD support was added and it 
introduced bug that
SYNCHRONIZE_CACHE is not passed to FW for JBOD (non Raid disk).

But our recent analysis indicates that, From Day-1 MR Firmware always
expect Driver to forward SYNCHRONIZE_CACHE for JBOD (non Raid disk) to the
Firmware.
We have fixed this as part of this patch.
 
 - Additional background -
There are some instance of MegaRaid FW (E.a Gen2 and Gen2.5 FW) set WCE bit
for Virtual Disk but firmware does not reply correct status for SYNCH_CACHE.
It is very difficult to find out which Device ID and firmware has capability
to manage SYNC_CACHE, so we managed to figure out which are the new firmware
(canHandleSyncCache is set in scratch pad register at 0xB4) and use that
interface for correct behavior as explained above.
 
E.g Liberator/Thunderbolt MegaRaid FW returns SYNC_CACHE as Unsupported
command (this is a firmware bug) and eventually command will be failed to SML.
This will cause File system to go Read-only.
 
 - New behavior described -
 
IF application requests SYNCH_CACHE
   IF 'JBOD'
  Driver sends SYNCH_CACHE command to the FW
   FW sends SYNCH_CACHE to drive
   FW obtains status from drive and returns same status back to 
driver
   ELSEIF 'VirtualDisk'
   IF any FW which supports new API bit called canHandleSyncCache
  Driver sends SYNCH_CACHE command to the FW
  FW does not send SYNCH_CACHE to drives
  FW returns SUCCESS
   ELSE
  Driver does not send SYNCH_CACHE command to the 
FW.
  Driver return SUCCESS for that command.
   ENDIF
ENDIF
ENDIF

CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|  3 +++
 drivers/scsi/megaraid/megaraid_sas_base.c   | 10 ++
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  5 +
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index ca86c88..43fd14f 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
 #define MR_MAX_MSIX_REG_ARRAY   16
 #define MR_RDPQ_MODE_OFFSET0X0080
+#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100
+
 /*
 * register set for both 1068 and 1078 controllers
 * structure extended for 1078 registers
@@ -2140,6 +2142,7 @@ struct megasas_instance {
u8 is_imr;
u8 is_rdpq;
bool dev_handle;
+   bool fw_sync_cache_support;
 };
 struct MR_LD_VF_MAP {
u32 size;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 3236632..f7a2ab1 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1700,16 +1700,10 @@ inline int megasas_cmd_type(struct scsi_cmnd *cmd)
goto out_done;
}
 
-   switch (scmd->cmnd[0]) {
-   case SYNCHRONIZE_CACHE:
-   /*
-* FW takes care of flush cache on its own
-* No need to send it down
-*/
+   if (MEGASAS_IS_LOGICAL(scmd) && (scmd->cmnd[0] == SYNCHRONIZE_CACHE) &&
+   (!instance->fw_sync_cache_support)) {
scmd->result = DID_OK << 16;
goto out_done;
-   default:
-   break;
}
 
return instance->instancet->build_and_issue_cmd(instance, scmd);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusi

[PATCH v2 7/7] megaraid_sas: driver version upgrade

2016-10-20 Thread Sumit Saxena
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 43fd14f..1d4de90 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
 /*
  * MegaRAID SAS Driver meta data
  */
-#define MEGASAS_VERSION"06.811.02.00-rc1"
-#define MEGASAS_RELDATE"April 12, 2016"
+#define MEGASAS_VERSION"06.812.07.00-rc1"
+#define MEGASAS_RELDATE"August 22, 2016"
 
 /*
  * Device IDs
-- 
1.8.3.1

--
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


[PATCH v2 0/7] megaraid_sas: Updates for scsi-next

2016-10-20 Thread Sumit Saxena
Changes in v2:
1.  Removed unconditional msleep and moved calls to atomic_read into 
megasas_wait_for_adapter_operational
2.  Updated change log for patch #4.  Provided more detail in change log.
3.  Agreed to remove module parameter. If we remove module parameter,
we can ask customer to disable WCE on drive to get similar impact.
4.  Always Send SYNCHRONIZE_CACHE for JBOD (non Raid) Device to Firmware.
5. Add log message printing the state of FW sync cache support
6. Moved version update patch to end of series

Sumit Saxena (7):
  megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for
30secs before reset
  megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade
  megaraid_sas: Do not fire DCMDs during PCI shutdown/detach
  megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
  MAINTAINERS: Update megaraid maintainers list
  megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which
does not support JBOD sequence map
  megaraid_sas: driver version upgrade

 MAINTAINERS | 10 +++---
 drivers/scsi/megaraid/megaraid_sas.h|  7 +++--
 drivers/scsi/megaraid/megaraid_sas_base.c   | 49 -
 drivers/scsi/megaraid/megaraid_sas_fp.c |  6 ++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 23 +-
 5 files changed, 71 insertions(+), 24 deletions(-)

-- 
1.8.3.1

--
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


[PATCH v2 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

2016-10-20 Thread Sumit Saxena
For SRIOV enabled firmware, if there is a OCR(online controller reset)
possibility driver set the convert flag to 1, which is not happening if
there are outstanding commands even after 180 seconds.
As driver does not set convert flag to 1 and still making the OCR to run,
VF(Virtual function) driver is directly writing on to the register
instead of waiting for 30 seconds. Setting convert flag to 1 will cause
VF driver will wait for 30 secs before going for reset.

CC: sta...@vger.kernel.org
Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 52d8bbf..61be7ed 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2823,6 +2823,7 @@ int megasas_wait_for_outstanding_fusion(struct 
megasas_instance *instance,
dev_err(>pdev->dev, "pending commands remain after 
waiting, "
   "will reset adapter scsi%d.\n",
   instance->host->host_no);
+   *convert = 1;
retval = 1;
}
 out:
-- 
1.8.3.1

--
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


[PATCH v2 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade

2016-10-20 Thread Sumit Saxena
This patch fixes the issue of wrong PhysArm was sent to firmware for R1
VD downgrade.

Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_fp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c 
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index e413113..f237d00 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -782,7 +782,8 @@ static u8 mr_spanset_get_phy_params(struct megasas_instance 
*instance, u32 ld,
(raid->regTypeReqOnRead != REGION_TYPE_UNUSED
pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE;
else if (raid->level == 1) {
-   pd = MR_ArPdGet(arRef, physArm + 1, map);
+   physArm = physArm + 1;
+   pd = MR_ArPdGet(arRef, physArm, map);
if (pd != MR_PD_INVALID)
*pDevHandle = MR_PdDevHandleGet(pd, map);
}
@@ -879,7 +880,8 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 
ld, u64 stripRow,
pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE;
else if (raid->level == 1) {
/* Get alternate Pd. */
-   pd = MR_ArPdGet(arRef, physArm + 1, map);
+   physArm = physArm + 1;
+   pd = MR_ArPdGet(arRef, physArm, map);
if (pd != MR_PD_INVALID)
/* Get dev handle from Pd */
*pDevHandle = MR_PdDevHandleGet(pd, map);
-- 
1.8.3.1

--
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


[PATCH v2 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

2016-10-20 Thread Sumit Saxena
This patch addresses the issue of driver firing DCMDs in PCI
shutdown/detach path irrespective of firmware state.
Driver will check for whether firmware is operational state or not
before firing DCMDs. If firmware is in unrecoverbale
state or does not become operational within specfied time, driver will
skip firing DCMDs.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Signed-off-by: Shivasharan Srikanteshwara 
<shivasharan.srikanteshw...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 39 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  9 ---
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9ff57de..3236632 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -6248,6 +6248,34 @@ static void megasas_shutdown_controller(struct 
megasas_instance *instance,
 #define megasas_resume NULL
 #endif
 
+static inline int
+megasas_wait_for_adapter_operational(struct megasas_instance *instance)
+{
+   int wait_time = MEGASAS_RESET_WAIT_TIME * 2;
+   int i;
+
+   if (atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
+   return 1;
+
+   for (i = 0; i < wait_time; i++) {
+   if (atomic_read(>adprecovery) == 
MEGASAS_HBA_OPERATIONAL)
+   break;
+
+   if (!(i % MEGASAS_RESET_NOTICE_INTERVAL))
+   dev_notice(>pdev->dev, "waiting for 
controller reset to finish\n");
+
+   msleep(1000);
+   }
+
+   if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) {
+   dev_info(>pdev->dev, "%s timed out while waiting for 
HBA to recover.\n",
+   __func__);
+   return 1;
+   }
+
+   return 0;
+}
+
 /**
  * megasas_detach_one -PCI hot"un"plug entry point
  * @pdev:  PCI device structure
@@ -6272,9 +6300,14 @@ static void megasas_detach_one(struct pci_dev *pdev)
if (instance->fw_crash_state != UNAVAILABLE)
megasas_free_host_crash_buffer(instance);
scsi_remove_host(instance->host);
+
+   if (megasas_wait_for_adapter_operational(instance))
+   goto skip_firing_dcmds;
+
megasas_flush_cache(instance);
megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN);
 
+skip_firing_dcmds:
/* cancel the delayed work if this work still in queue*/
if (instance->ev != NULL) {
struct megasas_aen_event *ev = instance->ev;
@@ -6388,8 +6421,14 @@ static void megasas_shutdown(struct pci_dev *pdev)
struct megasas_instance *instance = pci_get_drvdata(pdev);
 
instance->unload = 1;
+
+   if (megasas_wait_for_adapter_operational(instance))
+   goto skip_firing_dcmds;
+
megasas_flush_cache(instance);
megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN);
+
+skip_firing_dcmds:
instance->instancet->disable_intr(instance);
megasas_destroy_irqs(instance);
 
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 61be7ed..2159f6a 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2463,12 +2463,15 @@ irqreturn_t megasas_isr_fusion(int irq, void *devp)
/* Start collecting crash, if DMA bit is done */
if ((fw_state == MFI_STATE_FAULT) && dma_state)
schedule_work(>crash_init);
-   else if (fw_state == MFI_STATE_FAULT)
-   schedule_work(>work_init);
+   else if (fw_state == MFI_STATE_FAULT) {
+   if (instance->unload == 0)
+   schedule_work(>work_init);
+   }
} else if (fw_state == MFI_STATE_FAULT) {
dev_warn(>pdev->dev, "Iop2SysDoorbellInt"
   "for scsi%d\n", instance->host->host_no);
-   schedule_work(>work_init);
+   if (instance->unload == 0)
+   schedule_work(>work_init);
}
}
 
-- 
1.8.3.1

--
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


[PATCH v2 5/7] MAINTAINERS: Update megaraid maintainers list

2016-10-20 Thread Sumit Saxena
Update MEGARAID drivers maintainers list.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Reviewed-by: Hannes Reinecke <h...@suse.com>
---
 MAINTAINERS | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4c1f3f9..05c0624 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7823,12 +7823,12 @@ S:  Maintained
 F: drivers/net/wireless/mediatek/mt7601u/
 
 MEGARAID SCSI/SAS DRIVERS
-M: Kashyap Desai <kashyap.de...@avagotech.com>
-M: Sumit Saxena <sumit.sax...@avagotech.com>
-M: Uday Lingala <uday.ling...@avagotech.com>
-L: megaraidlinux@avagotech.com
+M: Kashyap Desai <kashyap.de...@broadcom.com>
+M: Sumit Saxena <sumit.sax...@broadcom.com>
+M: Shivasharan S <shivasharan.srikanteshw...@broadcom.com>
+L: megaraidlinux@broadcom.com
 L: linux-scsi@vger.kernel.org
-W: http://www.lsi.com
+W: http://www.avagotech.com/support/
 S: Maintained
 F: Documentation/scsi/megaraid.txt
 F: drivers/scsi/megaraid.*
-- 
1.8.3.1

--
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


[PATCH v2 6/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

2016-10-20 Thread Sumit Saxena
CC: sta...@vger.kernel.org
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 2e61306..24778ba 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2005,6 +2005,8 @@ static void megasas_build_ld_nonrw_fusion(struct 
megasas_instance *instance,
io_request->DevHandle = pd_sync->seq[pd_index].devHandle;
pRAID_Context->regLockFlags |=

(MR_RL_FLAGS_SEQ_NUM_ENABLE|MR_RL_FLAGS_GRANT_DESTINATION_CUDA);
+   pRAID_Context->Type = MPI2_TYPE_CUDA;
+   pRAID_Context->nseg = 0x1;
} else if (fusion->fast_path_io) {
pRAID_Context->VirtualDiskTgtId = cpu_to_le16(device_id);
pRAID_Context->configSeqNum = 0;
@@ -2040,12 +2042,10 @@ static void megasas_build_ld_nonrw_fusion(struct 
megasas_instance *instance,
pRAID_Context->timeoutValue =
cpu_to_le16((os_timeout_value > timeout_limit) ?
timeout_limit : os_timeout_value);
-   if (fusion->adapter_type == INVADER_SERIES) {
-   pRAID_Context->Type = MPI2_TYPE_CUDA;
-   pRAID_Context->nseg = 0x1;
+   if (fusion->adapter_type == INVADER_SERIES)
io_request->IoFlags |=

cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH);
-   }
+
cmd->request_desc->SCSIIO.RequestFlags =
(MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
-- 
1.8.3.1

--
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


RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-18 Thread Sumit Saxena
>-Original Message-
>From: James Bottomley [mailto:j...@linux.vnet.ibm.com]
>Sent: Monday, October 17, 2016 11:22 PM
>To: Kashyap Desai; Ric Wheeler; Hannes Reinecke; Sumit Saxena; linux-
>s...@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com; Christoph Hellwig;
>Martin
>K. Petersen; Jeff Moyer; Gris Ge; Ewan Milne; Jens Axboe
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to
>firmware
>
>On Mon, 2016-10-17 at 23:06 +0530, Kashyap Desai wrote:
>> > -Original Message-
>> > From: James Bottomley [mailto:j...@linux.vnet.ibm.com]
>> > Sent: Monday, October 17, 2016 10:50 PM
>> > To: Ric Wheeler; Hannes Reinecke; Sumit Saxena;
>> > linux-scsi@vger.kernel.org
>> > Cc: martin.peter...@oracle.com; the...@redhat.com;
>> > kashyap.de...@broadcom.com; Christoph Hellwig; Martin K. Petersen;
>> > Jeff Moyer; Gris Ge; Ewan Milne; Jens Axboe
>> > Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE
>> > command to firmware
>> >
>> > On Mon, 2016-10-17 at 12:27 -0400, Ric Wheeler wrote:
>> > > On 10/17/2016 12:20 PM, James Bottomley wrote:
>> > > > On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote:
>> > > > > On 10/17/2016 07:34 AM, Hannes Reinecke wrote:
>> > > > > > On 10/17/2016 12:24 PM, Sumit Saxena wrote:
>> > > > > > > megaraid_sas driver returns SYNCHRONIZE_CACHE command back
>> > > > > > > to SCSI layer without sending it to firmware as firmware
>> > > > > > > takes care of flushing cache.  This patch will change the
>> > > > > > > driver behavior wrt SYNCHRONIZE_CACHE handling. If
>> > > > > > > underlying firmware has support to handle the
>> > > > > > > SYNCHORNIZE_CACHE, driver will send it for firmware
>> > > > > > > otherwise complete it back to SCSI layer with SUCCESS
>> > > > > > > immediately.  If  Firmware  handle SYNCHORNIZE_CACHE for
>> > > > > > > both VD and JBOD "canHandleSyncCache"
>> > > > > > > bit in scratch pad register(offset
>> > > > > > > 0x00B4) will be set.
>> > > > > > >
>> > > > > > > This behavior can be controlled via module parameter and
>> > > > > > > user can fallback to old behavior of returning
>> > > > > > > SYNCHRONIZE_CACHE by driver only without sending it to
>> > > > > > > firmware.
>> > > > > > >
>> > > > > > > Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>> > > > > > > Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
>> > > > > > > ---
>> > > > > > >drivers/scsi/megaraid/megaraid_sas.h|  3 +++
>> > > > > > >drivers/scsi/megaraid/megaraid_sas_base.c   | 14
>> > > > > > > ++---
>> > > > > > > -
>> > > > > > >drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 +++
>> > > > > > >drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 ++
>> > > > > > >4 files changed, 14 insertions(+), 8 deletions(-)
>> > > > > > >
>> > > > > > > diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> > > > > > > b/drivers/scsi/megaraid/megaraid_sas.h
>> > > > > > > index ca86c88..43fd14f 100644
>> > > > > > > --- a/drivers/scsi/megaraid/megaraid_sas.h
>> > > > > > > +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> > > > > > > @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>> > > > > > >#define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>> > > > > > >#define MR_MAX_MSIX_REG_ARRAY   16
>> > > > > > >#define MR_RDPQ_MODE_OFFSET   0X0
>> > > > > > > 0800
>> > > > > > > 000
>> > > > > > > +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0
>> > > > > > > X010
>> > > > > > > 
>> > > > > > > 0
>> > > > > > > +
>> > > > > > >/*
>> > > > > > >* register set for both 1068 and 1078 controllers
>> > > > > &g

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-18 Thread Sumit Saxena
>-Original Message-
>From: Ric Wheeler [mailto:ricwhee...@gmail.com]
>Sent: Tuesday, October 18, 2016 6:38 PM
>To: Tomas Henzl; Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; Kashyap Desai
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to
>firmware
>
>On 10/17/2016 09:57 AM, Tomas Henzl wrote:
>> On 17.10.2016 15:28, Sumit Saxena wrote:
>>>> -Original Message-
>>>> From: Tomas Henzl [mailto:the...@redhat.com]
>>>> Sent: Monday, October 17, 2016 6:44 PM
>>>> To: Sumit Saxena; linux-scsi@vger.kernel.org
>>>> Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com;
>>>> kashyap.de...@broadcom.com
>>>> Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE
>>>> command to firmware
>>>>
>>>> On 17.10.2016 12:24, Sumit Saxena wrote:
>>>>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI
>>>>> layer without sending it to firmware as firmware takes care of
>>>>> flushing
>>> cache.
>>>>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE
>>> handling.
>>>>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE,
>>>>> driver will send it for firmware otherwise complete it back to SCSI
>>>>> layer with SUCCESS immediately.
>>>>> If  Firmware  handle SYNCHORNIZE_CACHE for both VD and JBOD
>>>>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4)
>>>>> will be set.
>>>>>
>>>>> This behavior can be controlled via module parameter and user can
>>>>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver
>>>>> only without sending it to firmware.
>>>>>
>>>>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>>>>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
>>>>> ---
>>>>>   drivers/scsi/megaraid/megaraid_sas.h|  3 +++
>>>>>   drivers/scsi/megaraid/megaraid_sas_base.c   | 14 ++
>>>>>   drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 +++
>>>>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 ++
>>>>>   4 files changed, 14 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>>>> index ca86c88..43fd14f 100644
>>>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>>>>   #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>>>>   #define MR_MAX_MSIX_REG_ARRAY   16
>>>>>   #define MR_RDPQ_MODE_OFFSET 0X0080
>>>>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
>>>>> +
>>>>>   /*
>>>>>   * register set for both 1068 and 1078 controllers
>>>>>   * structure extended for 1078 registers @@ -2140,6 +2142,7 @@
>>>>> struct megasas_instance {
>>>>>   u8 is_imr;
>>>>>   u8 is_rdpq;
>>>>>   bool dev_handle;
>>>>> + bool fw_sync_cache_support;
>>>>>   };
>>>>>   struct MR_LD_VF_MAP {
>>>>>   u32 size;
>>>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>>>>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>>>>> index 092387f..a4a8e2f 100644
>>>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>>>>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>>>>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout =
>>>>> MEGASAS_DEFAULT_CMD_TIMEOUT;  module_param(scmd_timeout, int,
>>>>> S_IRUGO);  MODULE_PARM_DESC(scmd_timeout, "scsi command timeout
>>>>> (10-90s), default 90s. See megasas_reset_timer.");
>>>>>
>>>>> +bool block_sync_cache;
>>>>> +module_param(block_sync_cache, bool, S_IRUGO);
>>>>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver
>>>>> +Default: 0(Send it to firmware)");
>>>>> +
>>>>>   MODULE_LICENSE("GPL");
>>>>>   MODULE_VERSION(MEGASAS_VERSION);
>>>>>   MODULE_AUTHOR(&quo

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-17 Thread Sumit Saxena
>-Original Message-
>From: Tomas Henzl [mailto:the...@redhat.com]
>Sent: Monday, October 17, 2016 7:27 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; Kashyap Desai
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to
>firmware
>
>On 17.10.2016 15:28, Sumit Saxena wrote:
>>> -Original Message-
>>> From: Tomas Henzl [mailto:the...@redhat.com]
>>> Sent: Monday, October 17, 2016 6:44 PM
>>> To: Sumit Saxena; linux-scsi@vger.kernel.org
>>> Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com;
>>> kashyap.de...@broadcom.com
>>> Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE
>command
>>> to firmware
>>>
>>> On 17.10.2016 12:24, Sumit Saxena wrote:
>>>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI
>>>> layer without sending it to firmware as firmware takes care of
>>>> flushing
>> cache.
>>>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE
>> handling.
>>>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE,
>>>> driver will send it for firmware otherwise complete it back to SCSI
>>>> layer with SUCCESS immediately.
>>>> If  Firmware  handle SYNCHORNIZE_CACHE for both VD and JBOD
>>>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will
>>>> be set.
>>>>
>>>> This behavior can be controlled via module parameter and user can
>>>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver
>>>> only without sending it to firmware.
>>>>
>>>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>>>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
>>>> ---
>>>>  drivers/scsi/megaraid/megaraid_sas.h|  3 +++
>>>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 14 ++
>>>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 +++
>>>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 ++
>>>>  4 files changed, 14 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>>> index ca86c88..43fd14f 100644
>>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>>>  #define MR_MAX_MSIX_REG_ARRAY   16
>>>>  #define MR_RDPQ_MODE_OFFSET   0X0080
>>>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET   0X0100
>>>> +
>>>>  /*
>>>>  * register set for both 1068 and 1078 controllers
>>>>  * structure extended for 1078 registers @@ -2140,6 +2142,7 @@
>>>> struct megasas_instance {
>>>>u8 is_imr;
>>>>u8 is_rdpq;
>>>>bool dev_handle;
>>>> +  bool fw_sync_cache_support;
>>>>  };
>>>>  struct MR_LD_VF_MAP {
>>>>u32 size;
>>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> index 092387f..a4a8e2f 100644
>>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>>>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout =
>>>> MEGASAS_DEFAULT_CMD_TIMEOUT;  module_param(scmd_timeout, int,
>>>> S_IRUGO);  MODULE_PARM_DESC(scmd_timeout, "scsi command timeout
>>>> (10-90s), default 90s. See megasas_reset_timer.");
>>>>
>>>> +bool block_sync_cache;
>>>> +module_param(block_sync_cache, bool, S_IRUGO);
>>>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver
>>>> +Default: 0(Send it to firmware)");
>>>> +
>>>>  MODULE_LICENSE("GPL");
>>>>  MODULE_VERSION(MEGASAS_VERSION);
>>>>  MODULE_AUTHOR("megaraidlinux@avagotech.com");
>>>> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host
>>> *shost, struct scsi_cmnd *scmd)
>>>>goto out_done;
>>>>}
>>>>
>>>> -  switch (scmd->cmnd[0]) {
>>>> -  case SYNCHRONIZE_CACHE:
>>>> -  /*
>>>> -   * FW takes ca

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-17 Thread Sumit Saxena
>-Original Message-
>From: Ric Wheeler [mailto:rwhee...@redhat.com]
>Sent: Monday, October 17, 2016 6:31 PM
>To: Hannes Reinecke; Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com; Christoph Hellwig; Martin K. Petersen; Jeff
>Moyer; Gris Ge; Ewan Milne; Jens Axboe
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to
>firmware
>
>On 10/17/2016 07:34 AM, Hannes Reinecke wrote:
>> On 10/17/2016 12:24 PM, Sumit Saxena wrote:
>>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI
>>> layer without sending it to firmware as firmware takes care of
flushing cache.
>>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE
handling.
>>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE,
>>> driver will send it for firmware otherwise complete it back to SCSI
>>> layer with SUCCESS immediately.
>>> If  Firmware  handle SYNCHORNIZE_CACHE for both VD and JBOD
>>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will
>>> be set.
>>>
>>> This behavior can be controlled via module parameter and user can
>>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver
>>> only without sending it to firmware.
>>>
>>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
>>> ---
>>>   drivers/scsi/megaraid/megaraid_sas.h|  3 +++
>>>   drivers/scsi/megaraid/megaraid_sas_base.c   | 14 ++
>>>   drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 +++
>>>   drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 ++
>>>   4 files changed, 14 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>> index ca86c88..43fd14f 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>>   #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>>   #define MR_MAX_MSIX_REG_ARRAY   16
>>>   #define MR_RDPQ_MODE_OFFSET   0X0080
>>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100
>>> +
>>>   /*
>>>   * register set for both 1068 and 1078 controllers
>>>   * structure extended for 1078 registers @@ -2140,6 +2142,7 @@
>>> struct megasas_instance {
>>> u8 is_imr;
>>> u8 is_rdpq;
>>> bool dev_handle;
>>> +   bool fw_sync_cache_support;
>>>   };
>>>   struct MR_LD_VF_MAP {
>>> u32 size;
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>>> index 092387f..a4a8e2f 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout =
>MEGASAS_DEFAULT_CMD_TIMEOUT;
>>>   module_param(scmd_timeout, int, S_IRUGO);
>>>   MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s),
>>> default 90s. See megasas_reset_timer.");
>>>
>>> +bool block_sync_cache;
>>> +module_param(block_sync_cache, bool, S_IRUGO);
>>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver
>>> +Default: 0(Send it to firmware)");
>>> +
>>>   MODULE_LICENSE("GPL");
>>>   MODULE_VERSION(MEGASAS_VERSION);
>>>   MODULE_AUTHOR("megaraidlinux@avagotech.com");
>>> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host
>*shost, struct scsi_cmnd *scmd)
>>> goto out_done;
>>> }
>>>
>>> -   switch (scmd->cmnd[0]) {
>>> -   case SYNCHRONIZE_CACHE:
>>> -   /*
>>> -* FW takes care of flush cache on its own
>>> -* No need to send it down
>>> -*/
>>> +   if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) &&
>>> +   (!instance->fw_sync_cache_support)) {
>>> scmd->result = DID_OK << 16;
>>> goto out_done;
>>> -   default:
>>> -   break;
>>> }
>>>
>>> return instance->instancet->build_and_issue_cmd(instance, scmd);
>>> diff --git a/drivers/scsi/megaraid/mega

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-17 Thread Sumit Saxena
>-Original Message-
>From: Tomas Henzl [mailto:the...@redhat.com]
>Sent: Monday, October 17, 2016 6:44 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to
>firmware
>
>On 17.10.2016 12:24, Sumit Saxena wrote:
>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI
>> layer without sending it to firmware as firmware takes care of flushing
cache.
>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE
handling.
>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE,
>> driver will send it for firmware otherwise complete it back to SCSI
>> layer with SUCCESS immediately.
>> If  Firmware  handle SYNCHORNIZE_CACHE for both VD and JBOD
>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will
>> be set.
>>
>> This behavior can be controlled via module parameter and user can
>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver only
>> without sending it to firmware.
>>
>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  3 +++
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 14 ++
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 +++
>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 ++
>>  4 files changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index ca86c88..43fd14f 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>  #define MR_MAX_MSIX_REG_ARRAY   16
>>  #define MR_RDPQ_MODE_OFFSET 0X0080
>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100
>> +
>>  /*
>>  * register set for both 1068 and 1078 controllers
>>  * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ struct
>> megasas_instance {
>>  u8 is_imr;
>>  u8 is_rdpq;
>>  bool dev_handle;
>> +bool fw_sync_cache_support;
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 092387f..a4a8e2f 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout =
>> MEGASAS_DEFAULT_CMD_TIMEOUT;  module_param(scmd_timeout, int,
>> S_IRUGO);  MODULE_PARM_DESC(scmd_timeout, "scsi command timeout
>> (10-90s), default 90s. See megasas_reset_timer.");
>>
>> +bool block_sync_cache;
>> +module_param(block_sync_cache, bool, S_IRUGO);
>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver
>> +Default: 0(Send it to firmware)");
>> +
>>  MODULE_LICENSE("GPL");
>>  MODULE_VERSION(MEGASAS_VERSION);
>>  MODULE_AUTHOR("megaraidlinux@avagotech.com");
>> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host
>*shost, struct scsi_cmnd *scmd)
>>  goto out_done;
>>  }
>>
>> -switch (scmd->cmnd[0]) {
>> -case SYNCHRONIZE_CACHE:
>> -/*
>> - * FW takes care of flush cache on its own
>> - * No need to send it down
>> - */
>> +if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) &&
>> +(!instance->fw_sync_cache_support)) {
>
>Maybe I'm wrong, but isn't the logic inverted?
>when fw_sync_cache_support is true  it means that there is a flash cache
or a
>battery and we don't have to send the command down ?
>

If "instance->fw_sync_cache_support" is set to true, it means driver can
send SYNCHRONIZE_CACHE to firmware(firmware has infrastructure to support
SYNCHRONIZE_CACHE).
If "instance->fw_sync_cache_support" is set to false, it means FW does not
support to handle SYNCHRONIZE_CACHE and FW will flush cache during
shutdown.

>tomash
>
>>  scmd->result = DID_OK << 16;
>>  goto out_done;
>> -default:
>> -break;
>>  }
>>
>>  return instance->instancet->build_and_issue_cmd(instance, scmd);
>&

RE: [PATCH 5/7] megaraid_sas: driver version upgrade

2016-10-17 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Monday, October 17, 2016 5:05 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 5/7] megaraid_sas: driver version upgrade
>
>On 10/17/2016 12:24 PM, Sumit Saxena wrote:
>> Upgrade driver version.
>>
>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 43fd14f..1d4de90 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -35,8 +35,8 @@
>>  /*
>>   * MegaRAID SAS Driver meta data
>>   */
>> -#define MEGASAS_VERSION "06.811.02.00-rc1"
>> -#define MEGASAS_RELDATE "April 12, 2016"
>> +#define MEGASAS_VERSION "06.812.06.00-rc1"
>> +#define MEGASAS_RELDATE "August 22, 2016"
>>
>>  /*
>>   * Device IDs
>>
>Please move this patch to the end of the series.
>Otherwise it's impossible to tell if the following patches should be part
of the new
>version or not.

Sure..I will rectify and resend the patches.
>
>Cheers,
>
>Hannes
>--
>Dr. Hannes Reinecke   Teamlead Storage & Networking
>h...@suse.de  +49 911 74053 688
>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
>GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton 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


RE: [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

2016-10-17 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Monday, October 17, 2016 5:01 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI
>shutdown/detach
>
>On 10/17/2016 12:24 PM, Sumit Saxena wrote:
>> This patch addresses the issue of driver firing DCMDs in PCI
>> shutdown/detach path irrespective of firmware state.
>> Driver will check for whether firmware is operational state or not
>> before firing DCMDs. If firmware is in unrecoverbale state or does not
>> become operational within specfied time, driver will skip firing
>> DCMDs.
>>
>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 46
>+
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  9 --
>>  2 files changed, 52 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 9ff57de..092387f 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -6248,6 +6248,32 @@ fail_reenable_msix:
>>  #define megasas_resume  NULL
>>  #endif
>>
>> +static inline int
>> +megasas_wait_for_adapter_operational(struct megasas_instance
>> +*instance) {
>> +int wait_time = MEGASAS_RESET_WAIT_TIME * 2;
>> +int i;
>> +
>> +for (i = 0; i < wait_time; i++) {
>> +if (atomic_read(>adprecovery)
>> +== MEGASAS_HBA_OPERATIONAL)
>> +break;
>> +
>> +if (!(i % MEGASAS_RESET_NOTICE_INTERVAL))
>> +dev_notice(>pdev->dev, "waiting for
>controller reset to
>> +finish\n");
>> +
>> +msleep(1000);
>> +}
>> +
>> +if (atomic_read(>adprecovery) !=
>MEGASAS_HBA_OPERATIONAL) {
>> +dev_info(>pdev->dev, "%s timed out while waiting
for
>HBA to recover.\n",
>> +__func__);
>> +return 1;
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  /**
>>   * megasas_detach_one - PCI hot"un"plug entry point
>>   * @pdev:   PCI device structure
>> @@ -6272,9 +6298,18 @@ static void megasas_detach_one(struct pci_dev
>*pdev)
>>  if (instance->fw_crash_state != UNAVAILABLE)
>>  megasas_free_host_crash_buffer(instance);
>>  scsi_remove_host(instance->host);
>> +
>> +msleep(1000);
>> +if ((atomic_read(>adprecovery) ==
>MEGASAS_HW_CRITICAL_ERROR)
>> +|| ((atomic_read(>adprecovery)
>> +!= MEGASAS_HBA_OPERATIONAL) &&
>> +megasas_wait_for_adapter_operational(instance)))
>> +goto skip_firing_dcmds;
>> +
>>  megasas_flush_cache(instance);
>>  megasas_shutdown_controller(instance,
>MR_DCMD_CTRL_SHUTDOWN);
>>
>> +skip_firing_dcmds:
>>  /* cancel the delayed work if this work still in queue*/
>>  if (instance->ev != NULL) {
>>  struct megasas_aen_event *ev = instance->ev;
>Why not move the 'msleep' and 'atomic_read' into the call to
>megasas_wait_for_adapter_operational?
I will rectify this in next version of this patch.

>Plus I'm not sure if the unconditional 'msleep' is a good idea here;
maybe one
>should read 'adprecovery' first and _then_ call msleep if required?
Agreed.. I will cleanup this and resend the patch.

Thanks,
Sumit
>
>Cheers,
>
>Hannes
>--
>Dr. Hannes Reinecke   Teamlead Storage & Networking
>h...@suse.de  +49 911 74053 688
>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
>GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton 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


RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-17 Thread Sumit Saxena
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Monday, October 17, 2016 5:04 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to
>firmware
>
>On 10/17/2016 12:24 PM, Sumit Saxena wrote:
>> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI
>> layer without sending it to firmware as firmware takes care of flushing
cache.
>> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE
handling.
>> If underlying firmware has support to handle the SYNCHORNIZE_CACHE,
>> driver will send it for firmware otherwise complete it back to SCSI
>> layer with SUCCESS immediately.
>> If  Firmware  handle SYNCHORNIZE_CACHE for both VD and JBOD
>> "canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will
>> be set.
>>
>> This behavior can be controlled via module parameter and user can
>> fallback to old behavior of returning SYNCHRONIZE_CACHE by driver only
>> without sending it to firmware.
>>
>> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>> Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  3 +++
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 14 ++
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 +++
>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 ++
>>  4 files changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index ca86c88..43fd14f 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>  #define MR_MAX_MSIX_REG_ARRAY   16
>>  #define MR_RDPQ_MODE_OFFSET 0X0080
>> +#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100
>> +
>>  /*
>>  * register set for both 1068 and 1078 controllers
>>  * structure extended for 1078 registers @@ -2140,6 +2142,7 @@ struct
>> megasas_instance {
>>  u8 is_imr;
>>  u8 is_rdpq;
>>  bool dev_handle;
>> +bool fw_sync_cache_support;
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 092387f..a4a8e2f 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -104,6 +104,10 @@ unsigned int scmd_timeout =
>> MEGASAS_DEFAULT_CMD_TIMEOUT;  module_param(scmd_timeout, int,
>> S_IRUGO);  MODULE_PARM_DESC(scmd_timeout, "scsi command timeout
>> (10-90s), default 90s. See megasas_reset_timer.");
>>
>> +bool block_sync_cache;
>> +module_param(block_sync_cache, bool, S_IRUGO);
>> +MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver
>> +Default: 0(Send it to firmware)");
>> +
>>  MODULE_LICENSE("GPL");
>>  MODULE_VERSION(MEGASAS_VERSION);
>>  MODULE_AUTHOR("megaraidlinux@avagotech.com");
>> @@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host
>*shost, struct scsi_cmnd *scmd)
>>  goto out_done;
>>  }
>>
>> -switch (scmd->cmnd[0]) {
>> -case SYNCHRONIZE_CACHE:
>> -/*
>> - * FW takes care of flush cache on its own
>> - * No need to send it down
>> - */
>> +if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) &&
>> +(!instance->fw_sync_cache_support)) {
>>  scmd->result = DID_OK << 16;
>>  goto out_done;
>> -default:
>> -break;
>>  }
>>
>>  return instance->instancet->build_and_issue_cmd(instance, scmd);
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> index 2159f6a..8237580 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> @@ -747,6 +747,9 @@ megasas_ioc_init_fusion(struct megasas_instance
>*instance)
>>  ret = 1;
>>  goto fail_fw_init;
>>  }
>> +if (!block_sync_cache)
>> +instance->fw_sync_cache_support = (scratch

[PATCH 5/7] megaraid_sas: driver version upgrade

2016-10-17 Thread Sumit Saxena
Upgrade driver version.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 43fd14f..1d4de90 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
 /*
  * MegaRAID SAS Driver meta data
  */
-#define MEGASAS_VERSION"06.811.02.00-rc1"
-#define MEGASAS_RELDATE"April 12, 2016"
+#define MEGASAS_VERSION"06.812.06.00-rc1"
+#define MEGASAS_RELDATE"August 22, 2016"
 
 /*
  * Device IDs
-- 
1.8.3.1

--
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


[PATCH 7/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

2016-10-17 Thread Sumit Saxena
Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does
not support JBOD sequence map.

CC: sta...@vger.kernel.org
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 8237580..25b7720 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2003,6 +2003,8 @@ megasas_build_syspd_fusion(struct megasas_instance 
*instance,
io_request->DevHandle = pd_sync->seq[pd_index].devHandle;
pRAID_Context->regLockFlags |=

(MR_RL_FLAGS_SEQ_NUM_ENABLE|MR_RL_FLAGS_GRANT_DESTINATION_CUDA);
+   pRAID_Context->Type = MPI2_TYPE_CUDA;
+   pRAID_Context->nseg = 0x1;
} else if (fusion->fast_path_io) {
pRAID_Context->VirtualDiskTgtId = cpu_to_le16(device_id);
pRAID_Context->configSeqNum = 0;
@@ -2038,12 +2040,10 @@ megasas_build_syspd_fusion(struct megasas_instance 
*instance,
pRAID_Context->timeoutValue =
cpu_to_le16((os_timeout_value > timeout_limit) ?
timeout_limit : os_timeout_value);
-   if (fusion->adapter_type == INVADER_SERIES) {
-   pRAID_Context->Type = MPI2_TYPE_CUDA;
-   pRAID_Context->nseg = 0x1;
+   if (fusion->adapter_type == INVADER_SERIES)
io_request->IoFlags |=

cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH);
-   }
+
cmd->request_desc->SCSIIO.RequestFlags =
(MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
-- 
1.8.3.1

--
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


[PATCH 6/7] MAINTAINERS: Update megaraid maintainers list

2016-10-17 Thread Sumit Saxena
Update MEGARAID drivers maintainers list.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 MAINTAINERS | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f0ee7a6..8b9117f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7612,12 +7612,12 @@ S:  Maintained
 F: drivers/net/wireless/mediatek/mt7601u/
 
 MEGARAID SCSI/SAS DRIVERS
-M: Kashyap Desai <kashyap.de...@avagotech.com>
-M: Sumit Saxena <sumit.sax...@avagotech.com>
-M: Uday Lingala <uday.ling...@avagotech.com>
-L: megaraidlinux@avagotech.com
+M: Kashyap Desai <kashyap.de...@broadcom.com>
+M: Sumit Saxena <sumit.sax...@broadcom.com>
+M: Shivasharan S <shivasharan.srikanteshw...@broadcom.com>
+L: megaraidlinux@broadcom.com
 L: linux-scsi@vger.kernel.org
-W: http://www.lsi.com
+W: http://www.avagotech.com/support/
 S: Maintained
 F: Documentation/scsi/megaraid.txt
 F: drivers/scsi/megaraid.*
-- 
1.8.3.1

--
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


[PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

2016-10-17 Thread Sumit Saxena
megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer
without sending it to firmware as firmware takes care of flushing cache.
This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling.
If underlying firmware has support to handle the SYNCHORNIZE_CACHE, driver
will send it for firmware otherwise complete it back to SCSI layer with
SUCCESS immediately.
If  Firmware  handle SYNCHORNIZE_CACHE for both VD and JBOD
"canHandleSyncCache" bit in scratch pad register(offset 0x00B4) will be
set.

This behavior can be controlled via module parameter and user can fallback
to old behavior of returning SYNCHRONIZE_CACHE by driver only without
sending it to firmware.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|  3 +++
 drivers/scsi/megaraid/megaraid_sas_base.c   | 14 ++
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 +++
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 ++
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index ca86c88..43fd14f 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
 #define MR_MAX_MSIX_REG_ARRAY   16
 #define MR_RDPQ_MODE_OFFSET0X0080
+#define MR_CAN_HANDLE_SYNC_CACHE_OFFSET0X0100
+
 /*
 * register set for both 1068 and 1078 controllers
 * structure extended for 1078 registers
@@ -2140,6 +2142,7 @@ struct megasas_instance {
u8 is_imr;
u8 is_rdpq;
bool dev_handle;
+   bool fw_sync_cache_support;
 };
 struct MR_LD_VF_MAP {
u32 size;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 092387f..a4a8e2f 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -104,6 +104,10 @@ unsigned int scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT;
 module_param(scmd_timeout, int, S_IRUGO);
 MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default 90s. 
See megasas_reset_timer.");
 
+bool block_sync_cache;
+module_param(block_sync_cache, bool, S_IRUGO);
+MODULE_PARM_DESC(block_sync_cache, "Block SYNC CACHE by driver Default: 0(Send 
it to firmware)");
+
 MODULE_LICENSE("GPL");
 MODULE_VERSION(MEGASAS_VERSION);
 MODULE_AUTHOR("megaraidlinux@avagotech.com");
@@ -1700,16 +1704,10 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
scsi_cmnd *scmd)
goto out_done;
}
 
-   switch (scmd->cmnd[0]) {
-   case SYNCHRONIZE_CACHE:
-   /*
-* FW takes care of flush cache on its own
-* No need to send it down
-*/
+   if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) &&
+   (!instance->fw_sync_cache_support)) {
scmd->result = DID_OK << 16;
goto out_done;
-   default:
-   break;
}
 
return instance->instancet->build_and_issue_cmd(instance, scmd);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 2159f6a..8237580 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -747,6 +747,9 @@ megasas_ioc_init_fusion(struct megasas_instance *instance)
ret = 1;
goto fail_fw_init;
}
+   if (!block_sync_cache)
+   instance->fw_sync_cache_support = (scratch_pad_2 &
+   MR_CAN_HANDLE_SYNC_CACHE_OFFSET) ? 1 : 0;
 
IOCInitMessage =
  dma_alloc_coherent(>pdev->dev,
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h 
b/drivers/scsi/megaraid/megaraid_sas_fusion.h
index e3bee04..2857154 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
@@ -72,6 +72,8 @@
 #define MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET   (0x030C)
 #define MPI2_REPLY_POST_HOST_INDEX_OFFSET  (0x006C)
 
+extern bool block_sync_cache;
+
 /*
  * Raid context flags
  */
-- 
1.8.3.1

--
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


[PATCH 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade

2016-10-17 Thread Sumit Saxena
This patch fixes the issue of wrong PhysArm was sent to firmware for R1
VD downgrade.

Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_fp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c 
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index e413113..f237d00 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -782,7 +782,8 @@ static u8 mr_spanset_get_phy_params(struct megasas_instance 
*instance, u32 ld,
(raid->regTypeReqOnRead != REGION_TYPE_UNUSED
pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE;
else if (raid->level == 1) {
-   pd = MR_ArPdGet(arRef, physArm + 1, map);
+   physArm = physArm + 1;
+   pd = MR_ArPdGet(arRef, physArm, map);
if (pd != MR_PD_INVALID)
*pDevHandle = MR_PdDevHandleGet(pd, map);
}
@@ -879,7 +880,8 @@ u8 MR_GetPhyParams(struct megasas_instance *instance, u32 
ld, u64 stripRow,
pRAID_Context->regLockFlags = REGION_TYPE_EXCLUSIVE;
else if (raid->level == 1) {
/* Get alternate Pd. */
-   pd = MR_ArPdGet(arRef, physArm + 1, map);
+   physArm = physArm + 1;
+   pd = MR_ArPdGet(arRef, physArm, map);
if (pd != MR_PD_INVALID)
/* Get dev handle from Pd */
*pDevHandle = MR_PdDevHandleGet(pd, map);
-- 
1.8.3.1

--
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


[PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

2016-10-17 Thread Sumit Saxena
This patch addresses the issue of driver firing DCMDs in PCI
shutdown/detach path irrespective of firmware state.
Driver will check for whether firmware is operational state or not
before firing DCMDs. If firmware is in unrecoverbale
state or does not become operational within specfied time, driver will
skip firing DCMDs.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 46 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  9 --
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9ff57de..092387f 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -6248,6 +6248,32 @@ fail_reenable_msix:
 #define megasas_resume NULL
 #endif
 
+static inline int
+megasas_wait_for_adapter_operational(struct megasas_instance *instance)
+{
+   int wait_time = MEGASAS_RESET_WAIT_TIME * 2;
+   int i;
+
+   for (i = 0; i < wait_time; i++) {
+   if (atomic_read(>adprecovery)
+   == MEGASAS_HBA_OPERATIONAL)
+   break;
+
+   if (!(i % MEGASAS_RESET_NOTICE_INTERVAL))
+   dev_notice(>pdev->dev, "waiting for 
controller reset to finish\n");
+
+   msleep(1000);
+   }
+
+   if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) {
+   dev_info(>pdev->dev, "%s timed out while waiting for 
HBA to recover.\n",
+   __func__);
+   return 1;
+   }
+
+   return 0;
+}
+
 /**
  * megasas_detach_one -PCI hot"un"plug entry point
  * @pdev:  PCI device structure
@@ -6272,9 +6298,18 @@ static void megasas_detach_one(struct pci_dev *pdev)
if (instance->fw_crash_state != UNAVAILABLE)
megasas_free_host_crash_buffer(instance);
scsi_remove_host(instance->host);
+
+   msleep(1000);
+   if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
+   || ((atomic_read(>adprecovery)
+   != MEGASAS_HBA_OPERATIONAL) &&
+   megasas_wait_for_adapter_operational(instance)))
+   goto skip_firing_dcmds;
+
megasas_flush_cache(instance);
megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN);
 
+skip_firing_dcmds:
/* cancel the delayed work if this work still in queue*/
if (instance->ev != NULL) {
struct megasas_aen_event *ev = instance->ev;
@@ -6388,8 +6423,19 @@ static void megasas_shutdown(struct pci_dev *pdev)
struct megasas_instance *instance = pci_get_drvdata(pdev);
 
instance->unload = 1;
+
+   msleep(1000);
+
+   if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
+   || ((atomic_read(>adprecovery)
+   != MEGASAS_HBA_OPERATIONAL)
+   && megasas_wait_for_adapter_operational(instance)))
+   goto skip_firing_dcmds;
+
megasas_flush_cache(instance);
megasas_shutdown_controller(instance, MR_DCMD_CTRL_SHUTDOWN);
+
+skip_firing_dcmds:
instance->instancet->disable_intr(instance);
megasas_destroy_irqs(instance);
 
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 61be7ed..2159f6a 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2463,12 +2463,15 @@ irqreturn_t megasas_isr_fusion(int irq, void *devp)
/* Start collecting crash, if DMA bit is done */
if ((fw_state == MFI_STATE_FAULT) && dma_state)
schedule_work(>crash_init);
-   else if (fw_state == MFI_STATE_FAULT)
-   schedule_work(>work_init);
+   else if (fw_state == MFI_STATE_FAULT) {
+   if (instance->unload == 0)
+   schedule_work(>work_init);
+   }
} else if (fw_state == MFI_STATE_FAULT) {
dev_warn(>pdev->dev, "Iop2SysDoorbellInt"
   "for scsi%d\n", instance->host->host_no);
-   schedule_work(>work_init);
+   if (instance->unload == 0)
+   schedule_work(>work_init);
}
}
 
-- 
1.8.3.1

--
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


[PATCH 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

2016-10-17 Thread Sumit Saxena
For SRIOV enabled firmware, if there is a OCR(online controller reset)
possibility driver set the convert flag to 1, which is not happening if
there are outstanding commands even after 180 seconds.
As driver does not set convert flag to 1 and still making the OCR to run,
VF(Virtual function) driver is directly writing on to the register
instead of waiting for 30 seconds. Setting convert flag to 1 will cause
VF driver will wait for 30 secs before going for reset.

CC: sta...@vger.kernel.org
Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kast...@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 52d8bbf..61be7ed 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2823,6 +2823,7 @@ int megasas_wait_for_outstanding_fusion(struct 
megasas_instance *instance,
dev_err(>pdev->dev, "pending commands remain after 
waiting, "
   "will reset adapter scsi%d.\n",
   instance->host->host_no);
+   *convert = 1;
retval = 1;
}
 out:
-- 
1.8.3.1

--
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


[PATCH 0/7] megaraid_sas: Updates for scsi-next

2016-10-17 Thread Sumit Saxena
Sumit Saxena (7):
  megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for
30secs before reset
  megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade
  megaraid_sas: Do not fire DCMDs during PCI shutdown/detach
  megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware
  megaraid_sas: driver version upgrade
  MAINTAINERS: Update megaraid maintainers list
  megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which
does not support JBOD sequence map

 MAINTAINERS | 10 ++---
 drivers/scsi/megaraid/megaraid_sas.h|  7 +++-
 drivers/scsi/megaraid/megaraid_sas_base.c   | 60 +
 drivers/scsi/megaraid/megaraid_sas_fp.c |  6 ++-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 21 ++
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +
 6 files changed, 82 insertions(+), 24 deletions(-)

-- 
1.8.3.1

--
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


RE: [PATCH 1/3] megaraid_sas: mark symbols static where possible

2016-09-25 Thread Sumit Saxena
 @@ build_mpt_cmd(struct megasas_instance *instance, struct
>megasas_cmd *cmd)
>  * @cmd:  mfi cmd pointer
>  *
>  */
>-int
>+static int
> megasas_issue_dcmd_fusion(struct megasas_instance *instance,
> struct megasas_cmd *cmd)
> {
>@@ -2748,8 +2748,9 @@ megasas_check_reset_fusion(struct megasas_instance
>*instance,  }
>
> /* This function waits for outstanding commands on fusion to complete */
-int
>megasas_wait_for_outstanding_fusion(struct megasas_instance *instance,
>-  int reason, int *convert)
>+static int
>+megasas_wait_for_outstanding_fusion(struct megasas_instance *instance,
>+  int reason, int *convert)
> {
>   int i, outstanding, retval = 0, hb_seconds_missed = 0;
>   u32 fw_state;
>@@ -2849,7 +2850,7 @@ void  megasas_reset_reply_desc(struct
>megasas_instance *instance)
>  * megasas_refire_mgmt_cmd :  Re-fire management commands
>  * @instance: Controller's soft instance
> */
>-void megasas_refire_mgmt_cmd(struct megasas_instance *instance)
>+static void megasas_refire_mgmt_cmd(struct megasas_instance *instance)
> {
>   int j;
>   struct megasas_cmd_fusion *cmd_fusion; @@ -3332,7 +,8 @@ int
>megasas_reset_target_fusion(struct scsi_cmnd *scmd)  }
>
> /*SRIOV get other instance in cluster if any*/ -struct megasas_instance
>*megasas_get_peer_instance(struct megasas_instance *instance)
>+static struct megasas_instance *
>+megasas_get_peer_instance(struct megasas_instance *instance)
> {
>   int i;
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>
 >
>--
>2.7.4
--
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


RE: [PATCH] megaraid_sas: clean function declarations in megaraid_sas_base.c up

2016-09-19 Thread Sumit Saxena
>-Original Message-
>From: Baoyou Xie [mailto:baoyou@linaro.org]
>Sent: Sunday, September 18, 2016 5:38 PM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org; a...@arndb.de; baoyou@linaro.org;
>xie.bao...@zte.com.cn
>Subject: [PATCH] megaraid_sas: clean function declarations in
>megaraid_sas_base.c up
>
>We get a few warnings when building kernel with W=1:
>drivers/scsi/megaraid/megaraid_sas_fusion.c:281:1: warning: no previous
>prototype for 'megasas_free_cmds_fusion' [-Wmissing-prototypes]
>drivers/scsi/megaraid/megaraid_sas_fusion.c:714:1: warning: no previous
>prototype for 'megasas_ioc_init_fusion' [-Wmissing-prototypes] 
>
>In fact, these functions are declared in
>drivers/scsi/megaraid/megaraid_sas_base.c, but should be declared in a
header
>file, thus can be recognized in other file.
>
>So this patch adds the declarations into
>drivers/scsi/megaraid/megaraid_sas_fusion.h.
>
>Signed-off-by: Baoyou Xie <baoyou@linaro.org>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c   | 13 -
> drivers/scsi/megaraid/megaraid_sas_fusion.h |  9 +
> 2 files changed, 9 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index 2d62d71..b73b6f3 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -189,25 +189,12 @@ u32
> megasas_build_and_issue_cmd(struct megasas_instance *instance,
>   struct scsi_cmnd *scmd);
> static void megasas_complete_cmd_dpc(unsigned long instance_addr); -void
-
>megasas_release_fusion(struct megasas_instance *instance); -int -
>megasas_ioc_init_fusion(struct megasas_instance *instance); -void -
>megasas_free_cmds_fusion(struct megasas_instance *instance);
>-u8
>-megasas_get_map_info(struct megasas_instance *instance); -int -
>megasas_sync_map_info(struct megasas_instance *instance);  int
>wait_and_poll(struct megasas_instance *instance, struct megasas_cmd *cmd,
>   int seconds);
>-void megasas_reset_reply_desc(struct megasas_instance *instance);  void
>megasas_fusion_ocr_wq(struct work_struct *work);  static int
>megasas_get_ld_vf_affiliation(struct megasas_instance *instance,
>int initial);
>-int megasas_check_mpio_paths(struct megasas_instance *instance,
>-   struct scsi_cmnd *scmd);
>
> int
> megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd
>*cmd) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h
>b/drivers/scsi/megaraid/megaraid_sas_fusion.h
>index 80eaee2..3fe730a 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
>+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
>@@ -991,5 +991,14 @@ union desc_value {
>   } u;
> };
>
>+void megasas_free_cmds_fusion(struct megasas_instance *instance); int
>+megasas_ioc_init_fusion(struct megasas_instance *instance);
>+u8 megasas_get_map_info(struct megasas_instance *instance); int
>+megasas_sync_map_info(struct megasas_instance *instance); void
>+megasas_release_fusion(struct megasas_instance *instance); void
>+megasas_reset_reply_desc(struct megasas_instance *instance); int
>+megasas_check_mpio_paths(struct megasas_instance *instance,
>+struct scsi_cmnd *scmd);
>+void megasas_fusion_ocr_wq(struct work_struct *work);
>
> #endif /* _MEGARAID_SAS_FUSION_H_ */
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.7.4
--
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


RE: [PATCH] scsi: megaraid_sas: add in missing white space in error message text

2016-09-13 Thread Sumit Saxena
>-Original Message-
>From: Colin King [mailto:colin.k...@canonical.com]
>Sent: Monday, September 12, 2016 6:12 PM
>To: Kashyap Desai; Sumit Saxena; Uday Lingala; James E . J . Bottomley;
>Martin K
>. Petersen; megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org
>Cc: linux-ker...@vger.kernel.org
>Subject: [PATCH] scsi: megaraid_sas: add in missing white space in error
>message
>text
>
>From: Colin Ian King <colin.k...@canonical.com>
>
>A dev_printk message spans two lines and the literal string is missing a
>white
>space between words. Add the white space.
>
>Signed-off-by: Colin Ian King <colin.k...@canonical.com>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index 2d62d71..c236c4d 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -5782,7 +5782,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
>>consumer_h);
>
>   if (!instance->producer || !instance->consumer) {
>-  dev_printk(KERN_DEBUG, >dev, "Failed to
>allocate"
>+  dev_printk(KERN_DEBUG, >dev, "Failed to
>allocate "
>  "memory for producer, consumer\n");
>   goto fail_alloc_dma_buf;
>   }
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>
>--
>2.9.3
--
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


RE: [PATCH] megaraid_sas: Fix the search of first memory bar

2016-08-25 Thread Sumit Saxena
>-Original Message-
>From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
>Sent: Sunday, August 21, 2016 1:58 PM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org; kernel-janit...@vger.kernel.org; Christophe JAILLET
>Subject: [PATCH] megaraid_sas: Fix the search of first memory bar
>
>The 2nd parameter of 'find_first_bit' is the number of bits to search.
>In this case, we are passing 'sizeof(unsigned long)' which is likely to be
>4.
>
>It is likely that the number of bits in a long was expected here, so use
>BITS_PER_LONG instead.
>
>Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr>
>---
>Other options are possible:
>  - 'bar_list' being a 'unsigned long', use __ffs to reduce code verbosity
>  - PCI_NUM_RESOURCES, which is the maximum number of bits that can be set
>by 'pci_select_bars()'
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index c1ed25adb17e..7d3de811d33c 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -5036,7 +5036,7 @@ static int megasas_init_fw(struct megasas_instance
>*instance)
>
>   /* Find first memory bar */
>   bar_list = pci_select_bars(instance->pdev, IORESOURCE_MEM);
>-  instance->bar = find_first_bit(_list, sizeof(unsigned long));
>+  instance->bar = find_first_bit(_list, BITS_PER_LONG);
>   if (pci_request_selected_regions(instance->pdev, 1<bar,
>        "megasas: LSI")) {
>   dev_printk(KERN_DEBUG, >pdev->dev, "IO memory
>region busy!\n");

Acked by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.7.4
>
>
>---
>L'absence de virus dans ce courrier électronique a été vérifiée par le
>logiciel
>antivirus Avast.
>https://www.avast.com/antivirus
--
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


RE: [PATCH] megaraid_sas: Use memdup_user() rather than duplicating its implementation

2016-08-22 Thread Sumit Saxena
>-Original Message-
>From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net]
>Sent: Sunday, August 21, 2016 2:19 PM
>To: linux-scsi@vger.kernel.org; megaraidlinux@avagotech.com; James E.
>J.
>Bottomley; Kashyap Desai; Martin K. Petersen; Sumit Saxena; Uday Lingala
>Cc: LKML; kernel-janit...@vger.kernel.org; Julia Lawall
>Subject: [PATCH] megaraid_sas: Use memdup_user() rather than duplicating
>its
>implementation
>
>From: Markus Elfring <elfr...@users.sourceforge.net>
>Date: Sun, 21 Aug 2016 10:39:04 +0200
>
>Reuse existing functionality from memdup_user() instead of keeping
>duplicate
>source code.
>
>This issue was detected by using the Coccinelle software.
>
>Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index c1ed25a..9a2fe4e 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -6711,14 +6711,9 @@ static int megasas_mgmt_ioctl_fw(struct file *file,
>unsigned long arg)
>   unsigned long flags;
>   u32 wait_time = MEGASAS_RESET_WAIT_TIME;
>
>-  ioc = kmalloc(sizeof(*ioc), GFP_KERNEL);
>-  if (!ioc)
>-  return -ENOMEM;
>-
>-  if (copy_from_user(ioc, user_ioc, sizeof(*ioc))) {
>-  error = -EFAULT;
>-  goto out_kfree_ioc;
>-  }
>+  ioc = memdup_user(user_ioc, sizeof(*ioc));
>+  if (IS_ERR(ioc))
>+  return PTR_ERR(ioc);
>
>   instance = megasas_lookup_instance(ioc->host_no);
>   if (!instance) {

Acked by: Sumit Saxena <sumit.sax...@broadcom.com>

>--
>2.9.3
--
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


[PATCH] megaraid_sas: Do not fire MR_DCMD_PD_LIST_QUERY to controllers which do not support it

2016-07-08 Thread Sumit Saxena
There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue reported,
megaraid_sas driver goes into an infinite error reporting loop as soon as there 
is a change
in the status of one of the arrays (degrade, resync online etc …).
Below are the error logs reported continuously- 

Jun 25 08:49:30 ns8 kernel: [  757.757017] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.778017] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.799017] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.820018] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.841018] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115

This issue is very much specific to controllers which do not support DCMD- 
MR_DCMD_PD_LIST_QUERY.
In case of any hotplugging/rescanning of drives, AEN thread will be scheduled 
by driver and fire
DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will fail 
this event processing
and will not go ahead for further events. This will cause infinite loop of same 
event getting
retried infinitely and causing above mentioned logs.

Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for controllers 
which do not
support it and send DCMD SUCCESS status to AEN function so that it can go ahead 
with other event
processing.

Reported-by: Lucz Geza <g...@lucz.com>
Cc: <sta...@vger.kernel.org>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>

---
 drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index f4b0690..2dab3dc 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4079,6 +4079,12 @@ megasas_get_pd_list(struct megasas_instance *instance)
struct MR_PD_ADDRESS *pd_addr;
dma_addr_t ci_h = 0;
 
+   if (instance->pd_list_not_supported) {
+   dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY "
+   "not supported by firmware\n");
+   return ret;
+   }
+
cmd = megasas_get_cmd(instance);
 
if (!cmd) {
-- 
2.4.11

--
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


RE: [PATCH] Do not fire MR_DCMD_PD_LIST_QUERY to controllers which do not support it

2016-07-08 Thread Sumit Saxena
Please ignore this patch. I missed to add megaraid_sas in subject line. I
realized after sending. Will be resending with proper subject. Sorry for
spamming.

> -Original Message-
> From: Sumit Saxena [mailto:sumit.sax...@broadcom.com]
> Sent: Friday, July 08, 2016 3:51 PM
> To: james.bottom...@hansenpartnership.com; martin.peter...@oracle.com
> Cc: linux-scsi@vger.kernel.org; kashyap.de...@broadcom.com;
> l...@geza.com; sta...@vger.kernel.org; Sumit Saxena
> Subject: [PATCH] Do not fire MR_DCMD_PD_LIST_QUERY to controllers which
> do not support it
>
> There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue
> reported,
> driver goes into an infinite error reporting loop as soon as there is a
> change in
> the status of one of the arrays (degrade, resync online etc …).
> Below are the error logs reported continuously-
>
> Jun 25 08:49:30 ns8 kernel: [  757.757017] megaraid_sas :02:00.0: DCMD
> failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30
> ns8 kernel: [  757.778017] megaraid_sas :02:00.0: DCMD failed/not
> supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8
> kernel: [
> 757.799017] megaraid_sas :02:00.0: DCMD failed/not supported by
> firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [
> 757.820018]
> megaraid_sas :02:00.0: DCMD failed/not supported by firmware:
> megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [  757.841018]
> megaraid_sas :02:00.0: DCMD failed/not supported by firmware:
> megasas_get_pd_list 4115
>
> This issue is very much specific to controllers which do not support DCMD-
> MR_DCMD_PD_LIST_QUERY.
> In case of any hotplugging/rescanning of drives, AEN thread will be
> scheduled by
> driver and fire
> DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will
> fail this event processing and will not go ahead for further events. This
> will cause
> infinite loop of same event getting retried infinitely and causing above
> mentioned logs.
>
> Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for
> controllers which do not support it and send DCMD SUCCESS status to AEN
> function so that it can go ahead with other event processing.
>
> Reported-by: Lucz Geza <g...@lucz.com>
> Cc: <sta...@vger.kernel.org>
> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
>
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index f4b0690..2dab3dc 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4079,6 +4079,12 @@ megasas_get_pd_list(struct megasas_instance
> *instance)
>   struct MR_PD_ADDRESS *pd_addr;
>   dma_addr_t ci_h = 0;
>
> + if (instance->pd_list_not_supported) {
> + dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY
> "
> + "not supported by firmware\n");
> + return ret;
> + }
> +
>   cmd = megasas_get_cmd(instance);
>
>   if (!cmd) {
> --
> 2.4.11
--
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


[PATCH] Do not fire MR_DCMD_PD_LIST_QUERY to controllers which do not support it

2016-07-08 Thread Sumit Saxena
There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue reported,
driver goes into an infinite error reporting loop as soon as there is a change
in the status of one of the arrays (degrade, resync online etc …).
Below are the error logs reported continuously- 

Jun 25 08:49:30 ns8 kernel: [  757.757017] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.778017] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.799017] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.820018] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115
Jun 25 08:49:30 ns8 kernel: [  757.841018] megaraid_sas :02:00.0: DCMD 
failed/not supported by firmware: megasas_get_pd_list 4115

This issue is very much specific to controllers which do not support DCMD- 
MR_DCMD_PD_LIST_QUERY.
In case of any hotplugging/rescanning of drives, AEN thread will be scheduled 
by driver and fire
DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will fail 
this event processing
and will not go ahead for further events. This will cause infinite loop of same 
event getting
retried infinitely and causing above mentioned logs.

Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for controllers 
which do not
support it and send DCMD SUCCESS status to AEN function so that it can go ahead 
with other event
processing.

Reported-by: Lucz Geza <g...@lucz.com>
Cc: <sta...@vger.kernel.org>
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>

---
 drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index f4b0690..2dab3dc 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4079,6 +4079,12 @@ megasas_get_pd_list(struct megasas_instance *instance)
struct MR_PD_ADDRESS *pd_addr;
dma_addr_t ci_h = 0;
 
+   if (instance->pd_list_not_supported) {
+   dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY "
+   "not supported by firmware\n");
+   return ret;
+   }
+
cmd = megasas_get_cmd(instance);
 
if (!cmd) {
-- 
2.4.11

--
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


RE: [PATCH] megaraid: add scsi_cmnd NULL check before use

2016-05-13 Thread Sumit Saxena
> -Original Message-
> From: Finn Thain [mailto:fth...@telegraphics.com.au]
> Sent: Friday, May 13, 2016 1:14 PM
> To: Sumit Saxena
> Cc: Dan Carpenter; Petros Koutoupis; kashyap.de...@avagotech.com;
> sumit.sax...@avagotech.com; uday.ling...@avagotech.com;
> megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org
> Subject: RE: [PATCH] megaraid: add scsi_cmnd NULL check before use
>
>
> On Thu, 12 May 2016, Sumit Saxena wrote:
>
> > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > >
> > > Also when I'm doing static analysis people always tell me that "that
> > > bug is impossible, trust me." and instead of trusting people I
> > > really wish they would just show me the relevant code that prevents
> > > it from happening.
> >
> > Inside megasas_build_io_fusion() function, driver sets "cmd->scmd"
> > pointer(SCSI command pointer received from SCSI mid layer). Functions
> > called inside megasas_build_io_fusion()(which actually builds frame to
> > be sent to firmware) are setting Function type-
> > MPI2_FUNCTION_SCSI_IO_REQUEST (or)
> MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST.
> > So in case Function type set to any one these two, there must be valid
> > "cmd->scmd".
>
> That doesn't show what prevents the bug. It merely shows that the bug
does not
> always manifest.
>
> For example, you might check whether anything prevents
> megasas_build_io_fusion() from returning before assigning cmd->scmd,
like
> so:
>
> 2112  if (sge_count > instance->max_num_sge) {
> 2113  dev_err(>pdev->dev, "Error. sge_count (0x%x)
> exceeds "
> 2114 "max (0x%x) allowed\n", sge_count,
> 2115 instance->max_num_sge);
> 2116  return 1;
> 2117  }
>
> Another possibility: cmd->io_request->Function is valid yet cmd->scmd is
NULL
> when seen from the interrupt handler if it intervenes between the two
> statements in megasas_return_cmd_fusion():

For IOs returned by above error are not actually fired to firmware so
there will be no interrupt handler called for the same.
Anyways, if anyone has logs pertaining to the failure, please attach..
>
> 180 inline void megasas_return_cmd_fusion(struct megasas_instance
*instance,
> 181   struct megasas_cmd_fusion *cmd)
> 182 {
> 183   cmd->scmd = NULL;
> 184   memset(cmd->io_request, 0, sizeof(struct
> MPI2_RAID_SCSI_IO_REQUEST));
> 185 }
>
> You might want to confirm that locking always prevents that.
>
> OTOH, without an actual backtrace, I too might be reluctant to pursue
this kind
> of speculation.
>
> --
--
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


RE: [PATCH] megaraid: add scsi_cmnd NULL check before use

2016-05-12 Thread Sumit Saxena
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, May 12, 2016 12:05 PM
> To: Petros Koutoupis
> Cc: Sumit Saxena; Finn Thain; kashyap.de...@avagotech.com;
> sumit.sax...@avagotech.com; uday.ling...@avagotech.com;
> megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use
>
> On Wed, May 11, 2016 at 08:49:51PM -0500, Petros Koutoupis wrote:
> > Sumit,
> >
> > I will resubmit the patch with all the recommendations. Thank you. In
> > case you are interested, I have a crash file showcasing the error. I
> > can always provide this outside of this mailing thread.
> >
>
> Please send it to the thread.
>
> To be honest, I totally can't understand this thread.  Sumit says it is
impossible
> and you are saying that you have seen it happen in real life.
> Are you using out of tree code or something?  What are you doing that is
> unexpected?
>
> I don't see the point of adding a WARN_ON().  NULL derefs normally
generate a
> pretty clear stack trace already (unless they are caused by memory
corruption).
> Why are we not just fixing the bugs instead of warning and then
crashing.
Agree, if there scsi_cmnd is coming as NULL, please attach logs. I will
look into them.
>
> Also when I'm doing static analysis people always tell me that "that bug
is
> impossible, trust me." and instead of trusting people I really wish they
would just
> show me the relevant code that prevents it from happening.
Inside megasas_build_io_fusion() function,  driver sets "cmd->scmd"
pointer(SCSI command pointer received from SCSI mid layer). Functions
called inside megasas_build_io_fusion()(which actually builds frame to be
sent to firmware)
are setting Function type- MPI2_FUNCTION_SCSI_IO_REQUEST (or)
MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST. So in case Function type set to any
one these two, there must be valid "cmd->scmd".

Thanks,
Sumit

>
> regards,
> dan carpenter
--
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


RE: [PATCH] megaraid: add scsi_cmnd NULL check before use

2016-05-11 Thread Sumit Saxena
> -Original Message-
> From: Petros Koutoupis [mailto:pet...@petroskoutoupis.com]
> Sent: Tuesday, May 10, 2016 2:59 AM
> To: Sumit Saxena; Dan Carpenter; Finn Thain
> Cc: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
> uday.ling...@avagotech.com; megaraidlinux@avagotech.com; linux-
> s...@vger.kernel.org
> Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use
>
> On Mon, 2016-05-09 at 15:18 +0530, Sumit Saxena wrote:
> > >
> > > -Original Message-
> > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > > Sent: Monday, May 09, 2016 1:36 PM
> > > To: Finn Thain
> > > Cc: Petros Koutoupis; kashyap.de...@avagotech.com;
> > > sumit.sax...@avagotech.com; uday.ling...@avagotech.com;
> > > megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org
> > > Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use
> > >
> > > Smatch doesn't quite catch it because we check "cmd_fusion->scmd"
> > > for
> > NULL
> > >
> > > then assign "scmd_local = cmd_fusion->scmd;" and dereference
> > > scmd_local unconditionally...
> > >
> > > It does catch part of the bug if you have cross function analysis:
> > >
> > >   drivers/scsi/megaraid/megaraid_sas_fusion.c:2318
> > > complete_cmd_fusion()
> > >   error: we previously assumed 'cmd_fusion->scmd' could be null (see
> > line 2281)
> > >
> > >
> > > But that code was from 2010 so I never reported it to the original
> > author or the
> > >
> > > list.
> > "cmd_fusion->scmd" should not be NULL if scsi_io_req->Function is set
> > to MPI2_FUNCTION_SCSI_IO_REQUEST (OR)
> > MEGASAS_MPI2_FUNCTION_LD_IO_REQUES
> > (inside these two cases only, cmd_fusion->scmd will be dereferenced).
> > If cmd_fusion->scmd is NULL for these "scsi_io_req->Function", that
> > will a BUG and should not continue with other commands processing in
> > that case.
> >
>
> Sumit,
>
> To clarify, a detection of cmd_fusion->scmd being NULL with scsi_io_req-
> >Function set to MPI2_FUNCTION_SCSI_IO_REQUEST or
> MEGASAS_MPI2_FUNCTION_LD_IO_REQUEST should instead trigger a
> BUG() and not attempt to iterate to the next command in the list. Thank
> you.

Petros,

WARN_ON() can be used in this case. Upstream may have concerns on using
BUG_ON() and also BUG_ON() won't help in this case. In production
environment we never encountered this.

Thanks,
Sumit
>
> --
> Petros
--
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


RE: [PATCH] megaraid: add scsi_cmnd NULL check before use

2016-05-09 Thread Sumit Saxena
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Monday, May 09, 2016 1:36 PM
> To: Finn Thain
> Cc: Petros Koutoupis; kashyap.de...@avagotech.com;
> sumit.sax...@avagotech.com; uday.ling...@avagotech.com;
> megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH] megaraid: add scsi_cmnd NULL check before use
>
> Smatch doesn't quite catch it because we check "cmd_fusion->scmd" for
NULL
> then assign "scmd_local = cmd_fusion->scmd;" and dereference scmd_local
> unconditionally...
>
> It does catch part of the bug if you have cross function analysis:
>
>   drivers/scsi/megaraid/megaraid_sas_fusion.c:2318 complete_cmd_fusion()
>   error: we previously assumed 'cmd_fusion->scmd' could be null (see
line 2281)
>
> But that code was from 2010 so I never reported it to the original
author or the
> list.
"cmd_fusion->scmd" should not be NULL if scsi_io_req->Function is set to
MPI2_FUNCTION_SCSI_IO_REQUEST (OR) MEGASAS_MPI2_FUNCTION_LD_IO_REQUES
(inside these two cases only, cmd_fusion->scmd will be dereferenced). If
cmd_fusion->scmd is NULL for these "scsi_io_req->Function", that will a
BUG and
should not continue with other commands processing in that case.

>
> regards,
> dan carpenter
--
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


RE: [PATCH v2] megaraid: Downgrade two success messages to info

2016-05-04 Thread Sumit Saxena
> -Original Message-
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Tuesday, May 03, 2016 10:55 PM
> To: Kashyap Desai; Sumit Saxena; Uday Lingala
> Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; Andy
> Lutomirski
> Subject: [PATCH v2] megaraid: Downgrade two success messages to info
>
> I actually read the error messages in my logs, and successful
initialization is not
> an error.
>
> Arguably these log lines could be deleted entirely.
>
> Signed-off-by: Andy Lutomirski <l...@kernel.org>
> ---
>
> Changes from v2: Remove hunk that didn't belong
>
> drivers/scsi/megaraid/megaraid_sas_base.c   | 2 +-
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index e6ebc7ae2df1..d020919e8085 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5152,7 +5152,7 @@ static int megasas_init_fw(struct megasas_instance
> *instance)
>
>   instance->instancet->enable_intr(instance);
>
> - dev_err(>pdev->dev, "INIT adapter done\n");
> + dev_info(>pdev->dev, "INIT adapter done\n");
>
>   megasas_setup_jbod_map(instance);
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 98a848bdfdc2..9375805670a9 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -851,7 +851,7 @@ megasas_ioc_init_fusion(struct megasas_instance
> *instance)
>   ret = 1;
>   goto fail_fw_init;
>   }
> - dev_err(>pdev->dev, "Init cmd success\n");
> + dev_info(>pdev->dev, "Init cmd success\n");
>
>   ret = 0;
Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

>
> --
> 2.5.5
--
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


[PATCH 4/4] megaraid_sas: driver version upgrade

2016-04-15 Thread Sumit Saxena
Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 1784b09..ca86c88 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
 /*
  * MegaRAID SAS Driver meta data
  */
-#define MEGASAS_VERSION"06.810.09.00-rc1"
-#define MEGASAS_RELDATE"Jan. 28, 2016"
+#define MEGASAS_VERSION"06.811.02.00-rc1"
+#define MEGASAS_RELDATE"April 12, 2016"
 
 /*
  * Device IDs
-- 
2.4.11

--
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


[PATCH 3/4] megaraid_sas: task management code optimizations

2016-04-15 Thread Sumit Saxena
This patch will do code optmization for task management functions.
Below are key changes-
1. Remove reset_device hook as it was not being used and driver was setting 
this to NULL.
2. Create wrapper functions for task abort and target reset and inside these 
functions
   adapter specific calls be made. e.g. fusion adapters support task abort and 
target reset
   so task abort and target reset should be issued to fusion adapters only and 
for MFI adapters,
   print a message saying feature not supported.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 67 +--
 1 file changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 8588202..b84756c 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -2670,17 +2670,6 @@ blk_eh_timer_return megasas_reset_timer(struct scsi_cmnd 
*scmd)
 }
 
 /**
- * megasas_reset_device -  Device reset handler entry point
- */
-static int megasas_reset_device(struct scsi_cmnd *scmd)
-{
-   /*
-* First wait for all commands to complete
-*/
-   return megasas_generic_reset(scmd);
-}
-
-/**
  * megasas_reset_bus_host -Bus & host reset handler entry point
  */
 static int megasas_reset_bus_host(struct scsi_cmnd *scmd)
@@ -2702,6 +2691,50 @@ static int megasas_reset_bus_host(struct scsi_cmnd *scmd)
 }
 
 /**
+ * megasas_task_abort - Issues task abort request to firmware
+ * (supported only for fusion adapters)
+ * @scmd:  SCSI command pointer
+ */
+static int megasas_task_abort(struct scsi_cmnd *scmd)
+{
+   int ret;
+   struct megasas_instance *instance;
+
+   instance = (struct megasas_instance *)scmd->device->host->hostdata;
+
+   if (instance->ctrl_context)
+   ret = megasas_task_abort_fusion(scmd);
+   else {
+   sdev_printk(KERN_NOTICE, scmd->device, "TASK ABORT not 
supported\n");
+   ret = FAILED;
+   }
+
+   return ret;
+}
+
+/**
+ * megasas_reset_target:  Issues target reset request to firmware
+ *(supported only for fusion adapters)
+ * @scmd: SCSI command pointer
+ */
+static int megasas_reset_target(struct scsi_cmnd *scmd)
+{
+   int ret;
+   struct megasas_instance *instance;
+
+   instance = (struct megasas_instance *)scmd->device->host->hostdata;
+
+   if (instance->ctrl_context)
+   ret = megasas_reset_target_fusion(scmd);
+   else {
+   sdev_printk(KERN_NOTICE, scmd->device, "TARGET RESET not 
supported\n");
+   ret = FAILED;
+   }
+
+   return ret;
+}
+
+/**
  * megasas_bios_param - Returns disk geometry for a disk
  * @sdev:  device handle
  * @bdev:  block device
@@ -2969,8 +3002,8 @@ static struct scsi_host_template megasas_template = {
.slave_alloc = megasas_slave_alloc,
.slave_destroy = megasas_slave_destroy,
.queuecommand = megasas_queue_command,
-   .eh_device_reset_handler = megasas_reset_device,
-   .eh_bus_reset_handler = megasas_reset_bus_host,
+   .eh_target_reset_handler = megasas_reset_target,
+   .eh_abort_handler = megasas_task_abort,
.eh_host_reset_handler = megasas_reset_bus_host,
.eh_timed_out = megasas_reset_timer,
.shost_attrs = megaraid_host_attrs,
@@ -5598,14 +5631,6 @@ static int megasas_io_attach(struct megasas_instance 
*instance)
host->max_lun = MEGASAS_MAX_LUN;
host->max_cmd_len = 16;
 
-   /* Fusion only supports host reset */
-   if (instance->ctrl_context) {
-   host->hostt->eh_device_reset_handler = NULL;
-   host->hostt->eh_bus_reset_handler = NULL;
-   host->hostt->eh_target_reset_handler = 
megasas_reset_target_fusion;
-   host->hostt->eh_abort_handler = megasas_task_abort_fusion;
-   }
-
/*
 * Notify the mid-layer about the new controller
 */
-- 
2.4.11

--
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


[PATCH 2/4] megaraid_sas: call ISR function to clean up pending replies in OCR path

2016-04-15 Thread Sumit Saxena
In OCR path, before calling chip reset calls function 
megasas_wait_for_outstanding_fusion to check reason
of OCR. In case of firmware FAULT initiated OCR and DCMD timeout initiated 
timeout, driver will clear any
outstanding reply(yet to be processed by driver) in reply queues before going 
for chip reset.
This code is added to handle a scenario when IO timeout initiated adapter reset 
and management application
initiated adapter reset(by sending command to FAULT firmware) happens 
simultaneously since adapter reset
function is safe-guarded by reset_mutex so only thread will be doing controller 
reset. Consider IO timeout
thread gets mutex and proceeds with adapter reset process after disabling 
interrupts and by the time
managementapplication has fired command to firmware to do adapter reset and the 
same command is completed by
firmware but since interrupts are disabled, driver will not get completion and 
the same command will be in
outstanding/pendingcommands list of driver and refires same command from IO 
timeout thread after chip reset
which will again FAULT firmware and evntually causes kill adapter.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 320c1a0..e2dc205 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2762,6 +2762,7 @@ int megasas_wait_for_outstanding_fusion(struct 
megasas_instance *instance,
dev_warn(>pdev->dev, "Found FW in FAULT 
state,"
   " will reset adapter scsi%d.\n",
instance->host->host_no);
+   megasas_complete_cmd_dpc_fusion((unsigned 
long)instance);
retval = 1;
goto out;
}
@@ -2769,6 +2770,7 @@ int megasas_wait_for_outstanding_fusion(struct 
megasas_instance *instance,
if (reason == MFI_IO_TIMEOUT_OCR) {
dev_info(>pdev->dev,
"MFI IO is timed out, initiating OCR\n");
+   megasas_complete_cmd_dpc_fusion((unsigned 
long)instance);
retval = 1;
goto out;
}
-- 
2.4.11

--
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


[PATCH 1/4] megaraid_sas: reduce memory footprints in kdump mode

2016-04-15 Thread Sumit Saxena
This patch will reduce memory footprints of megaraid_sas driver when booted in 
kdump mode.
Driver will not allocate memory for optional and perfromance oriented features.
Below are key changes done in megaraid_sas driver to do this-
1. Limit Controller's queue depth to 100 in kdump mode.
2. Do not allocate memory for system info buffer and PD info buffer.
3. Disable performance oriented features e.g. Disable RDPQ mode, disable dual 
queue depth,
   restrict to single MSI-x vector. 

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|  2 ++
 drivers/scsi/megaraid/megaraid_sas_base.c   | 48 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  3 ++
 3 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index fce414a..1784b09 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1344,6 +1344,8 @@ struct megasas_ctrl_info {
 #define SCAN_PD_CHANNEL0x1
 #define SCAN_VD_CHANNEL0x2
 
+#define MEGASAS_KDUMP_QUEUE_DEPTH   100
+
 enum MR_SCSI_CMD_TYPE {
READ_WRITE_LDIO = 0,
NON_READ_WRITE_LDIO = 1,
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index e6ebc7a..8588202 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5761,13 +5761,6 @@ static int megasas_probe_one(struct pci_dev *pdev,
break;
}
 
-   instance->system_info_buf = pci_zalloc_consistent(pdev,
-   sizeof(struct MR_DRV_SYSTEM_INFO),
-   >system_info_h);
-
-   if (!instance->system_info_buf)
-   dev_info(>pdev->dev, "Can't allocate system info 
buffer\n");
-
/* Crash dump feature related initialisation*/
instance->drv_buf_index = 0;
instance->drv_buf_alloc = 0;
@@ -5777,14 +5770,6 @@ static int megasas_probe_one(struct pci_dev *pdev,
spin_lock_init(>crashdump_lock);
instance->crash_dump_buf = NULL;
 
-   if (!reset_devices)
-   instance->crash_dump_buf = pci_alloc_consistent(pdev,
-   CRASH_DMA_BUF_SIZE,
-   >crash_dump_h);
-   if (!instance->crash_dump_buf)
-   dev_err(>dev, "Can't allocate Firmware "
-   "crash dump DMA buffer\n");
-
megasas_poll_wait_aen = 0;
instance->flag_ieee = 0;
instance->ev = NULL;
@@ -5803,11 +5788,26 @@ static int megasas_probe_one(struct pci_dev *pdev,
goto fail_alloc_dma_buf;
}
 
-   instance->pd_info = pci_alloc_consistent(pdev,
-   sizeof(struct MR_PD_INFO), >pd_info_h);
+   if (!reset_devices) {
+   instance->system_info_buf = pci_zalloc_consistent(pdev,
+   sizeof(struct MR_DRV_SYSTEM_INFO),
+   >system_info_h);
+   if (!instance->system_info_buf)
+   dev_info(>pdev->dev, "Can't allocate system 
info buffer\n");
+
+   instance->pd_info = pci_alloc_consistent(pdev,
+   sizeof(struct MR_PD_INFO), >pd_info_h);
 
-   if (!instance->pd_info)
-   dev_err(>pdev->dev, "Failed to alloc mem for 
pd_info\n");
+   if (!instance->pd_info)
+   dev_err(>pdev->dev, "Failed to alloc mem for 
pd_info\n");
+
+   instance->crash_dump_buf = pci_alloc_consistent(pdev,
+   CRASH_DMA_BUF_SIZE,
+   >crash_dump_h);
+   if (!instance->crash_dump_buf)
+   dev_err(>dev, "Can't allocate Firmware "
+   "crash dump DMA buffer\n");
+   }
 
/*
 * Initialize locks and queues
@@ -7174,6 +7174,16 @@ static int __init megasas_init(void)
int rval;
 
/*
+* Booted in kdump kernel, minimize memory footprints by
+* disabling few features
+*/
+   if (reset_devices) {
+   msix_vectors = 1;
+   rdpq_enable = 0;
+   dual_qdepth_disable = 1;
+   }
+
+   /*
 * Announce driver version and other information
 */
pr_info("megasas: %s\n", MEGASAS_VERSION);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 98a848b..320c1a0 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@

[PATCH 0/4] megaraid_sas: Updates for scsi-next

2016-04-15 Thread Sumit Saxena
This patchset has few small fixes/optimizations. Please consider this
for next release.

Sumit Saxena (4):
  megaraid_sas: reduce memory footprints in kdump mode
  megaraid_sas: call ISR function to clean up pending replies in OCR
path
  megaraid_sas: task management code optimizations
  megaraid_sas: driver version upgrade

 drivers/scsi/megaraid/megaraid_sas.h|   6 +-
 drivers/scsi/megaraid/megaraid_sas_base.c   | 115 ++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c |   5 ++
 3 files changed, 84 insertions(+), 42 deletions(-)

-- 
2.4.11

--
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


RE: [PATCH] megaraid_sas: fix missing { }, nullify kbuff_arr[i] only when necessary

2016-03-22 Thread Sumit Saxena
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Sunday, March 20, 2016 10:34 PM
> To: Kashyap Desai; Sumit Saxena; James Bottomley; Martin K . Petersen;
> megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Subject: [PATCH] megaraid_sas: fix missing { }, nullify kbuff_arr[i]
only when
> necessary
>
> From: Colin Ian King <colin.k...@canonical.com>
>
> Fix missing { } on if statement, this change will nullify kbuff_arr[i]
only where
> necessary as the code intended.
>
> detected using static analysis with smatch
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 69d375b..e6ebc7a 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -6656,12 +6656,13 @@ out:
>   }
>
>   for (i = 0; i < ioc->sge_count; i++) {
> - if (kbuff_arr[i])
> + if (kbuff_arr[i]) {
>   dma_free_coherent(>pdev->dev,
>
le32_to_cpu(kern_sge32[i].length),
> kbuff_arr[i],
>
> le32_to_cpu(kern_sge32[i].phys_addr));
>   kbuff_arr[i] = NULL;
> + }
>   }
>
>   megasas_return_cmd(instance, cmd);

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

> --
> 2.7.3
--
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


RE: [PATCH 3/3] megaraid_sas: add missing curly braces in ioctl handler

2016-03-15 Thread Sumit Saxena
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Monday, March 14, 2016 8:00 PM
> To: martin.peter...@oracle.com; james.bottom...@hansenpartnership.com;
> Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley
> Cc: linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; Arnd
Bergmann;
> Tomas Henzl; Bjorn Helgaas; megaraidlinux@avagotech.com
> Subject: [PATCH 3/3] megaraid_sas: add missing curly braces in ioctl
handler
>
> gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl
> function:
>
> drivers/scsi/megaraid/megaraid_sas_base.c: In function
> 'megasas_mgmt_fw_ioctl':
> drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is
> indented as if it were guarded by... [-Wmisleading-indentation]
> kbuff_arr[i] = NULL;
> ^
> drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if'
clause, but
> it is not
>if (kbuff_arr[i])
>^~
>
> The code is actually correct, as there is no downside in clearing a NULL
pointer
> again.
>
> This clarifies the code and avoids the warning by adding extra curly
braces.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Fixes: 90dc9d98f01b ("megaraid_sas : MFI MPT linked list corruption
fix")
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 5c08568ccfbf..2627200d4f82 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -6650,12 +6650,13 @@ out:
>   }
>
>   for (i = 0; i < ioc->sge_count; i++) {
> - if (kbuff_arr[i])
> + if (kbuff_arr[i]) {
>   dma_free_coherent(>pdev->dev,
>
le32_to_cpu(kern_sge32[i].length),
> kbuff_arr[i],
>
> le32_to_cpu(kern_sge32[i].phys_addr));
>   kbuff_arr[i] = NULL;
> + }
>   }
>
>   megasas_return_cmd(instance, cmd);

Acked-by: Sumit Saxena <sumit.sax...@broadcom.com>

> --
> 2.7.0
--
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


[PATCH] megaraid_sas: Don't issue kill adapter for MFI controllers in case of PD list DCMD failure

2016-03-10 Thread Sumit Saxena
There are few MFI adapters which do not support MR_DCMD_PD_LIST_QUERY so
if MFI adapters fail this DCMD, it should not be considered as FATAL and
driver should not issue kill adapter and set per controller's instance
variable- pd_list_not_supported so that same variable can be used inside
functions- slave_alloc and slave_configure to allow firmware scan.

Killing adapter because of DCMD failure when this DCMD is not supported
causes driver's probe getting failed. This issue got introduced because
of below commit when MFI IO timeout handling was introduced-

6d40afb megaraid_sas: MFI IO timeout handling

Killing adapter in case of this DCMD failure should be limited to Fusion
adapters only. Per controller's instance variable allow_fw_scan is removed
as pd_list_not_supported better reflect the purpose.

Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com>
---
 drivers/scsi/megaraid/megaraid_sas.h  |  2 +-
 drivers/scsi/megaraid/megaraid_sas_base.c | 14 ++
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 4484e63..fce414a 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2097,7 +2097,7 @@ struct megasas_instance {
u8 UnevenSpanSupport;
 
u8 supportmax256vd;
-   u8 allow_fw_scan;
+   u8 pd_list_not_supported;
u16 fw_supported_vd_count;
u16 fw_supported_pd_count;
 
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 5c08568..69d375b 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1838,7 +1838,7 @@ static int megasas_slave_configure(struct scsi_device 
*sdev)
struct megasas_instance *instance;
 
instance = megasas_lookup_instance(sdev->host->host_no);
-   if (instance->allow_fw_scan) {
+   if (instance->pd_list_not_supported) {
if (sdev->channel < MEGASAS_MAX_PD_CHANNELS &&
sdev->type == TYPE_DISK) {
pd_index = (sdev->channel * 
MEGASAS_MAX_DEV_PER_CHANNEL) +
@@ -1874,7 +1874,8 @@ static int megasas_slave_alloc(struct scsi_device *sdev)
pd_index =
(sdev->channel * MEGASAS_MAX_DEV_PER_CHANNEL) +
sdev->id;
-   if ((instance->allow_fw_scan || 
instance->pd_list[pd_index].driveState ==
+   if ((instance->pd_list_not_supported ||
+   instance->pd_list[pd_index].driveState ==
MR_PD_STATE_SYSTEM)) {
goto scan_target;
}
@@ -4087,7 +4088,13 @@ megasas_get_pd_list(struct megasas_instance *instance)
 
switch (ret) {
case DCMD_FAILED:
-   megaraid_sas_kill_hba(instance);
+   dev_info(>pdev->dev, "MR_DCMD_PD_LIST_QUERY "
+   "failed/not supported by firmware\n");
+
+   if (instance->ctrl_context)
+   megaraid_sas_kill_hba(instance);
+   else
+   instance->pd_list_not_supported = 1;
break;
case DCMD_TIMEOUT:
 
@@ -5034,7 +5041,6 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
case PCI_DEVICE_ID_DELL_PERC5:
default:
instance->instancet = _instance_template_xscale;
-   instance->allow_fw_scan = 1;
break;
}
 
-- 
2.4.3

--
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


RE: megaraid_sas: Task management support

2016-02-12 Thread Sumit Saxena
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Monday, February 08, 2016 11:52 PM
> To: sumit.sax...@avagotech.com
> Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org
> Subject: re: megaraid_sas: Task management support
>
> Hello Sumit Saxena,
>
> The patch 31796fa184ee: "megaraid_sas: Task management support" from Jan
> 28, 2016, leads to the following static checker warning:
>
>   drivers/scsi/megaraid/megaraid_sas_base.c:1788
> megasas_update_sdev_properties()
>   warn: if statement not indented
>
> drivers/scsi/megaraid/megaraid_sas_base.c
>   1781  } else {
>   1782  device_id = ((sdev->channel % 2) *
> MEGASAS_MAX_DEV_PER_CHANNEL)
>   1783  + sdev->id;
>   1784  local_map_ptr =
fusion->ld_drv_map[(instance->map_id & 1)];
>   1785  ld = MR_TargetIdToLdGet(device_id,
local_map_ptr);
>   1786  raid = MR_LdRaidGet(ld, local_map_ptr);
>   1787
>   1788  if (raid->capability.ldPiMode ==
> MR_PROT_INFO_TYPE_CONTROLLER)
>   1789
blk_queue_update_dma_alignment(sdev->request_queue, 0x7);
>
> It looks like the code is correct but the patch just deleted a tab
accidentally.
Yes code is correct, tab got deleted accidentally.
>
>   1790  mr_device_priv_data->is_tm_capable =
>   1791  raid->capability.tmCapable;
>   1792  }
>
> regards,
> dan carpenter
--
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


RE: [PATCH] megaraid: fix null pointer check in megasas_detach_one().

2016-02-02 Thread Sumit Saxena
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, February 02, 2016 7:24 AM
> To: Maurizio Lombardi
> Cc: sumit.sax...@avagotech.com; kashyap.de...@avagotech.com;
> uday.ling...@avagotech.com; linux-scsi@vger.kernel.org;
> jbottom...@parallels.com; the...@redhat.com
> Subject: Re: [PATCH] megaraid: fix null pointer check in
megasas_detach_one().
>
> > "Maurizio" == Maurizio Lombardi  writes:
>
> Maurizio> The pd_seq_sync pointer can't be NULL, we have to check its
> Maurizio> entries instead.
>
> Sumit?
Martin,
Patch looks good but it needs to be rebased with latest repo as very
recently you have checked in few megaraid_sas patches and there are two
critical patches for megaraid_sas are yet pending.
Once we get status of those two outstanding patches, I will ask submitter
to rebase and send this patch again or I will be resending.

Thanks,
Sumit
>
> --
> Martin K. PetersenOracle Linux Engineering
--
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


[PATCH v2 04/15] megaraid_sas: Task management support

2016-01-28 Thread Sumit Saxena
This patch will add task management(TM) support for SCSI commands in 
megaraid_sas driver.
Added TM functions are below-
1)Task abort
2)Target reset

Below are few key points-

1. Currently, megaraid_sas driver performs Controller reset when any IO times 
out.
With these TM support added in driver, in case of IO timeout task abort and 
target
reset will be tried to recover timed out IO. If both fails to recover IO, then
Controller reset will be called. If the TM request times out, fail the TM and 
escalate
to the next level(Controller reset).

2. mr_device_priv_data will be allocated for all generation of controller, but 
is_tm_capable
flag will never be set for older controllers (prior to Invader series) as 
firmware support is not
available for T.M functionality.

3. whichever firmware is capable for TM will set is_tm_capable flag in firmware 
API, which will be used
by Driver to pass TM frame to firmware or return back to OS as Failure to 
escalate next level of Error handling.

Additionally, Tomas Henzl's feedback has been accomodated in this patch- return 
MFI frame used for task management(TM)
in case of TM timeout and error cases. 

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|  13 +
 drivers/scsi/megaraid/megaraid_sas_base.c   |  60 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 474 +++-
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 ++-
 4 files changed, 646 insertions(+), 18 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index dcc6ff8..0fcb156 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1520,6 +1520,15 @@ union megasas_frame {
u8 raw_bytes[64];
 };
 
+/**
+ * struct MR_PRIV_DEVICE - sdev private hostdata
+ * @is_tm_capable: firmware managed tm_capable flag
+ * @tm_busy: TM request is in progress
+ */
+struct MR_PRIV_DEVICE {
+   bool is_tm_capable;
+   bool tm_busy;
+};
 struct megasas_cmd;
 
 union megasas_evt_class_locale {
@@ -2073,4 +2082,8 @@ void megasas_return_mfi_mpt_pthr(struct megasas_instance 
*instance,
 int megasas_cmd_type(struct scsi_cmnd *cmd);
 void megasas_setup_jbod_map(struct megasas_instance *instance);
 
+void megasas_update_sdev_properties(struct scsi_device *sdev);
+int megasas_reset_fusion(struct Scsi_Host *shost, int reason);
+int megasas_task_abort_fusion(struct scsi_cmnd *scmd);
+int megasas_reset_target_fusion(struct scsi_cmnd *scmd);
 #endif /*LSI_MEGARAID_SAS_H */
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 380c627..57cf4e3 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -189,7 +189,6 @@ int
 wait_and_poll(struct megasas_instance *instance, struct megasas_cmd *cmd,
int seconds);
 void megasas_reset_reply_desc(struct megasas_instance *instance);
-int megasas_reset_fusion(struct Scsi_Host *shost, int iotimeout);
 void megasas_fusion_ocr_wq(struct work_struct *work);
 static int megasas_get_ld_vf_affiliation(struct megasas_instance *instance,
 int initial);
@@ -1645,6 +1644,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
scsi_cmnd *scmd)
 {
struct megasas_instance *instance;
unsigned long flags;
+   struct MR_PRIV_DEVICE *mr_device_priv_data;
 
instance = (struct megasas_instance *)
scmd->device->host->hostdata;
@@ -1681,11 +1681,24 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
scsi_cmnd *scmd)
return 0;
}
 
+   mr_device_priv_data = scmd->device->hostdata;
+   if (!mr_device_priv_data) {
+   spin_unlock_irqrestore(>hba_lock, flags);
+   scmd->result = DID_NO_CONNECT << 16;
+   scmd->scsi_done(scmd);
+   return 0;
+   }
+
if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) {
spin_unlock_irqrestore(>hba_lock, flags);
return SCSI_MLQUEUE_HOST_BUSY;
}
 
+   if (mr_device_priv_data->tm_busy) {
+   spin_unlock_irqrestore(>hba_lock, flags);
+   return SCSI_MLQUEUE_DEVICE_BUSY;
+   }
+
spin_unlock_irqrestore(>hba_lock, flags);
 
scmd->result = 0;
@@ -1736,27 +1749,39 @@ static struct megasas_instance 
*megasas_lookup_instance(u16 host_no)
 }
 
 /*
-* megasas_set_dma_alignment - Set DMA alignment for PI enabled VD
+* megasas_update_sdev_properties - Update sdev structure based on controller's 
FW capabilities
 *
 * @sdev: OS provided scsi device
 *
 * Returns void
 */
-static void megasas_set_dma_alignment(struct scsi_device *sdev)
+void megasas_update_sdev_properties(struct scsi_device *sdev)
 {
+  

[PATCH v2 01/15] megaraid_sas: Do not allow PCI access during OCR

2016-01-28 Thread Sumit Saxena
This patch will do synhronization between OCR function and AEN function using 
"reset_mutex" lock.
reset_mutex will be acquire only in first half of the AEN function which issue 
DCMD. Second half
of the function calls SCSI API (scsi_add_device/scsi_remove_device) should be 
out of reset_mutex
to avoid deadlock between scsi_eh thread and Driver.

During chip reset(inside OCR function), there should not be any PCI access and 
AEN function
(which is called in delayed context) may be firirng DCMDs(doing PCI writes) 
when chip reset is
happening in parallel which will cause FW fault. This patch will solve the 
problem by making
AEN thread and OCR thread mutually exclusive.

There are no changes in this patch from last time sent patch.

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas.h  |   2 +
 drivers/scsi/megaraid/megaraid_sas_base.c | 254 ++
 2 files changed, 82 insertions(+), 174 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index c0f7c8c..ef4ff03 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1083,6 +1083,8 @@ struct megasas_ctrl_info {
 
 #define VD_EXT_DEBUG 0
 
+#define SCAN_PD_CHANNEL0x1
+#define SCAN_VD_CHANNEL0x2
 
 enum MR_SCSI_CMD_TYPE {
READ_WRITE_LDIO = 0,
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 97a1c1c..9650487 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5476,7 +5476,6 @@ static int megasas_probe_one(struct pci_dev *pdev,
spin_lock_init(>hba_lock);
spin_lock_init(>completion_lock);
 
-   mutex_init(>aen_mutex);
mutex_init(>reset_mutex);
 
/*
@@ -6442,10 +6441,10 @@ static int megasas_mgmt_ioctl_aen(struct file *file, 
unsigned long arg)
}
spin_unlock_irqrestore(>hba_lock, flags);
 
-   mutex_lock(>aen_mutex);
+   mutex_lock(>reset_mutex);
error = megasas_register_aen(instance, aen.seq_num,
 aen.class_locale_word);
-   mutex_unlock(>aen_mutex);
+   mutex_unlock(>reset_mutex);
return error;
 }
 
@@ -6647,6 +6646,7 @@ megasas_aen_polling(struct work_struct *work)
int i, j, doscan = 0;
u32 seq_num, wait_time = MEGASAS_RESET_WAIT_TIME;
int error;
+   u8  dcmd_ret = 0;
 
if (!instance) {
printk(KERN_ERR "invalid instance!\n");
@@ -6659,16 +6659,7 @@ megasas_aen_polling(struct work_struct *work)
wait_time = MEGASAS_ROUTINE_WAIT_TIME_VF;
 
/* Don't run the event workqueue thread if OCR is running */
-   for (i = 0; i < wait_time; i++) {
-   if (instance->adprecovery == MEGASAS_HBA_OPERATIONAL)
-   break;
-   if (!(i % MEGASAS_RESET_NOTICE_INTERVAL)) {
-   dev_notice(>pdev->dev, "%s waiting for "
-  "controller reset to finish for scsi%d\n",
-  __func__, instance->host->host_no);
-   }
-   msleep(1000);
-   }
+   mutex_lock(>reset_mutex);
 
instance->ev = NULL;
host = instance->host;
@@ -6676,212 +6667,127 @@ megasas_aen_polling(struct work_struct *work)
megasas_decode_evt(instance);
 
switch (le32_to_cpu(instance->evt_detail->code)) {
-   case MR_EVT_PD_INSERTED:
-   if (megasas_get_pd_list(instance) == 0) {
-   for (i = 0; i < MEGASAS_MAX_PD_CHANNELS; i++) {
-   for (j = 0;
-   j < MEGASAS_MAX_DEV_PER_CHANNEL;
-   j++) {
-
-   pd_index =
-   (i * MEGASAS_MAX_DEV_PER_CHANNEL) + j;
-
-   sdev1 = scsi_device_lookup(host, i, j, 0);
-
-   if (instance->pd_list[pd_index].driveState
-   == MR_PD_STATE_SYSTEM) {
-   if (!sdev1)
-   scsi_add_device(host, i, j, 0);
-
-   if (sdev1)
-   scsi_device_put(sdev1);
-   }
-   }
-   }
-   }
-   doscan = 0;
-   break;
 
+   case MR_EVT_PD_INSERTED:
case MR_EVT_PD_REMOVED:
-

[PATCH v2 02/15] megaraid_sas: MFI IO timeout handling

2016-01-28 Thread Sumit Saxena
This patch will do proper error handling for DCMD timeout and failed cases for 
fusion adapters.
Below are few key design points-
1. For MFI adapters, in case of DCMD timeout(DCMD which must return SUCCESS) 
driver will call kill adapter. 
2. What action needs to be taken in case of DCMD timeout is decided by function 
dcmd_timeout_ocr_possible().
DCMD timeout causing OCR is applicable to below DCMDs-

MR_DCMD_PD_LIST_QUERY
MR_DCMD_LD_GET_LIST
MR_DCMD_LD_LIST_QUERY
MR_DCMD_CTRL_SET_CRASH_DUMP_PARAMS
MR_DCMD_SYSTEM_PD_MAP_GET_INFO(for non pended DCMD)
MR_DCMD_LD_MAP_GET_INFO(for non pended DCMD)

3. If DCMD fails from Driver init path, there are certain DCMD which is must to 
be return SUCCESS. If those DCMD fails,
driver bail out load. For optional DCMD like pd_info etc, driver continue 
without executing certain functionality.

There are no changes in this patch from last time sent patch.

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|  22 +-
 drivers/scsi/megaraid/megaraid_sas_base.c   | 372 +---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  54 ++--
 3 files changed, 338 insertions(+), 110 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index ef4ff03..dcc6ff8 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -170,6 +170,7 @@
 
 /* Driver internal */
 #define DRV_DCMD_POLLED_MODE   0x1
+#define DRV_DCMD_SKIP_REFIRE   0x2
 
 /*
  * Definition for cmd_status
@@ -1093,6 +1094,11 @@ enum MR_SCSI_CMD_TYPE {
NON_READ_WRITE_SYSPDIO = 3,
 };
 
+enum DCMD_TIMEOUT_ACTION {
+   INITIATE_OCR = 0,
+   KILL_ADAPTER = 1,
+   IGNORE_TIMEOUT = 2,
+};
 /* Frame Type */
 #define IO_FRAME   0
 #define PTHRU_FRAME1
@@ -1139,6 +1145,7 @@ enum MR_SCSI_CMD_TYPE {
 
 #define MFI_OB_INTR_STATUS_MASK0x0002
 #define MFI_POLL_TIMEOUT_SECS  60
+#define MFI_IO_TIMEOUT_SECS180
 #define MEGASAS_SRIOV_HEARTBEAT_INTERVAL_VF(5 * HZ)
 #define MEGASAS_OCR_SETTLE_TIME_VF (1000 * 30)
 #define MEGASAS_ROUTINE_WAIT_TIME_VF   300
@@ -1918,7 +1925,7 @@ struct megasas_instance_template {
u32 (*init_adapter)(struct megasas_instance *);
u32 (*build_and_issue_cmd) (struct megasas_instance *,
struct scsi_cmnd *);
-   void (*issue_dcmd) (struct megasas_instance *instance,
+   int (*issue_dcmd)(struct megasas_instance *instance,
struct megasas_cmd *cmd);
 };
 
@@ -2016,6 +2023,19 @@ struct megasas_mgmt_info {
int max_index;
 };
 
+enum MEGASAS_OCR_CAUSE {
+   FW_FAULT_OCR= 0,
+   SCSIIO_TIMEOUT_OCR  = 1,
+   MFI_IO_TIMEOUT_OCR  = 2,
+};
+
+enum DCMD_RETURN_STATUS {
+   DCMD_SUCCESS= 0,
+   DCMD_TIMEOUT= 1,
+   DCMD_FAILED = 2,
+   DCMD_NOT_FIRED  = 3,
+};
+
 u8
 MR_BuildRaidContext(struct megasas_instance *instance,
struct IO_REQUEST_INFO *io_info,
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9650487..380c627 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -196,11 +196,12 @@ static int megasas_get_ld_vf_affiliation(struct 
megasas_instance *instance,
 int megasas_check_mpio_paths(struct megasas_instance *instance,
 struct scsi_cmnd *scmd);
 
-void
+int
 megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd *cmd)
 {
instance->instancet->fire_cmd(instance,
cmd->frame_phys_addr, 0, instance->reg_set);
+   return 0;
 }
 
 /**
@@ -983,25 +984,20 @@ extern struct megasas_instance_template 
megasas_instance_template_fusion;
 int
 megasas_issue_polled(struct megasas_instance *instance, struct megasas_cmd 
*cmd)
 {
-   int seconds;
struct megasas_header *frame_hdr = >frame->hdr;
 
-   frame_hdr->cmd_status = MFI_CMD_STATUS_POLL_MODE;
+   frame_hdr->cmd_status = MFI_STAT_INVALID_STATUS;
frame_hdr->flags |= cpu_to_le16(MFI_FRAME_DONT_POST_IN_REPLY_QUEUE);
 
-   /*
-* Issue the frame using inbound queue port
-*/
-   instance->instancet->issue_dcmd(instance, cmd);
+   if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+   (instance->instancet->issue_dcmd(instance, cmd))) {
+   dev_err(>pdev->dev, "Failed from %s %d\n",
+   __func__, __LINE__);
+   return DCMD_NOT_FIRED;
+   }
 
-   

[PATCH v2 03/15] megaraid_sas: Syncing request flags macro names with firmware

2016-01-28 Thread Sumit Saxena
There are no changes in this patch from last time sent patch.

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 +++---
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 6e48707..1dc4537 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -1666,7 +1666,7 @@ megasas_build_ldio_fusion(struct megasas_instance 
*instance,
   local_map_ptr, start_lba_lo);
io_request->Function = MPI2_FUNCTION_SCSI_IO_REQUEST;
cmd->request_desc->SCSIIO.RequestFlags =
-   (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY
+   (MPI2_REQ_DESCRIPT_FLAGS_FP_IO
 << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
if (fusion->adapter_type == INVADER_SERIES) {
if (io_request->RaidContext.regLockFlags ==
@@ -1799,7 +1799,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
megasas_instance *instance,
 
/* build request descriptor */
cmd->request_desc->SCSIIO.RequestFlags =
-   (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY <<
+   (MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
cmd->request_desc->SCSIIO.DevHandle = devHandle;
 
@@ -1905,7 +1905,7 @@ megasas_build_syspd_fusion(struct megasas_instance 
*instance,

cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH);
}
cmd->request_desc->SCSIIO.RequestFlags =
-   (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY <<
+   (MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
}
 }
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h 
b/drivers/scsi/megaraid/megaraid_sas_fusion.h
index 473005c..a9e10c4 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
@@ -176,7 +176,8 @@ enum REGION_TYPE {
 #define MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD   (0x0100)
 #define MPI2_SCSIIO_EEDPFLAGS_INSERT_OP (0x0004)
 #define MPI2_FUNCTION_SCSI_IO_REQUEST   (0x00) /* SCSI IO */
-#define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY   (0x06)
+#define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY   (0x03)
+#define MPI2_REQ_DESCRIPT_FLAGS_FP_IO   (0x06)
 #define MPI2_REQ_DESCRIPT_FLAGS_SCSI_IO (0x00)
 #define MPI2_SGE_FLAGS_64_BIT_ADDRESSING(0x02)
 #define MPI2_SCSIIO_CONTROL_WRITE   (0x0100)
-- 
1.8.3.1

--
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


[PATCH v2 00/15] megaraid_sas: Updates for scsi-next

2016-01-28 Thread Sumit Saxena
Changes between v1 and v2:
-Addressed comments provided by Tomas Henzl.
-Return MFI frame used for task management(TM) in case of TM timeout and 
 error cases.
-Fixed few error handling cases inside functions- megasas_alloc_cmdlist_fusion()
 and megasas_alloc_cmds_fusion(), fix typo- disable(old- disbale) in rdpq_enable
 module parameter's description, modify print to reflect RDPQ support statement
 correctly.
-Used atomic_inc_return instead of using atomic_read() and atomic_inc()
 separately inside function- megasas_build_and_issue_cmd_fusion(). 
-Removed the un-necessary code of throttling of IOs against can_queue inside
 function- megasas_build_and_issue_cmd_fusion() as SCSI mid layer will anyways
 does this.
-Removed redundant checks when label- kill_hba_and_failed is being called.
-Removed one patch- *[PATCH 15/15] megaraid_sas: SPERC boot driver reorder*
 from v2 patchset as that was rejected.
-Added one new patch for driver version upgrade.

Sumit Saxena (15):
  megaraid_sas: Do not allow PCI access during OCR
  megaraid_sas: MFI IO timeout handling
  megaraid_sas: Syncing request flags macro names with firmware
  megaraid_sas: Task management support
  megaraid_sas: Update device Queue depth based on interface type
  megaraid_sas: Fastpath region lock bypass
  megaraid_sas: Reply Descriptor Post Queue(RDPQ) support
  megaraid_sas: Code optimization build_and_issue_cmd return-type
  megaraid_sas: Dual Queue depth support
  megaraid_sas: IO throttling support
  megaraid_sas: Make adprecovery variable atomic
  megaraid_sas: MFI adapter's OCR changes
  megaraid_sas: Introduce module parameter for SCSI command-timeout
  megaraid_sas: SPERC OCR changes
  megaraid_sas: driver version upgrade

 drivers/scsi/megaraid/megaraid_sas.h|  338 +++-
 drivers/scsi/megaraid/megaraid_sas_base.c   | 1034 ++
 drivers/scsi/megaraid/megaraid_sas_fp.c |2 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 1244 ---
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  136 ++-
 5 files changed, 2027 insertions(+), 727 deletions(-)

-- 
1.8.3.1

--
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


[PATCH v2 06/15] megaraid_sas: Fastpath region lock bypass

2016-01-28 Thread Sumit Saxena
Firmware will fill per LD data to tell driver that particular LD supports 
Region lock bypass or not. If yes, then 
Driver will send non FP LDIO to region lock bypass FIFO. With this change in 
driver, firmware will optimize certain
code to improve performance.

There are no changes in this patch from last time sent patch.

Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas.h| 8 ++--
 drivers/scsi/megaraid/megaraid_sas_fp.c | 2 ++
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 --
 drivers/scsi/megaraid/megaraid_sas_fusion.h | 8 +---
 4 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 773fc54..01135be 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1528,7 +1528,9 @@ union megasas_sgl_frame {
 typedef union _MFI_CAPABILITIES {
struct {
 #if   defined(__BIG_ENDIAN_BITFIELD)
-   u32 reserved:23;
+   u32 reserved:21;
+   u32 support_fp_rlbypass:1;
+   u32 support_vfid_in_ioframe:1;
u32 support_ext_io_size:1;
u32 support_ext_queue_depth:1;
u32 security_protocol_cmds_fw:1;
@@ -1548,7 +1550,9 @@ typedef union _MFI_CAPABILITIES {
u32 security_protocol_cmds_fw:1;
u32 support_ext_queue_depth:1;
u32 support_ext_io_size:1;
-   u32 reserved:23;
+   u32 support_vfid_in_ioframe:1;
+   u32 support_fp_rlbypass:1;
+   u32 reserved:21;
 #endif
} mfi_capabilities;
__le32  reg;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c 
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index 741509b..e413113 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -1020,6 +1020,8 @@ MR_BuildRaidContext(struct megasas_instance *instance,
/* assume this IO needs the full row - we'll adjust if not true */
regSize = stripSize;
 
+   io_info->do_fp_rlbypass = raid->capability.fpBypassRegionLock;
+
/* Check if we can send this I/O via FastPath */
if (raid->capability.fpCapable) {
if (isRead)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 4b0c86c..518b488 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -666,6 +666,8 @@ megasas_ioc_init_fusion(struct megasas_instance *instance)
if (instance->max_chain_frame_sz > MEGASAS_CHAIN_FRAME_SZ_MIN)
drv_ops->mfi_capabilities.support_ext_io_size = 1;
 
+   drv_ops->mfi_capabilities.support_fp_rlbypass = 1;
+
/* Convert capability to LE32 */
cpu_to_le32s((u32 *)_frame->driver_operations.mfi_capabilities);
 
@@ -1710,8 +1712,8 @@ megasas_build_ldio_fusion(struct megasas_instance 
*instance,
(MEGASAS_REQ_DESCRIPT_FLAGS_LD_IO
 << MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
if (fusion->adapter_type == INVADER_SERIES) {
-   if (io_request->RaidContext.regLockFlags ==
-   REGION_TYPE_UNUSED)
+   if (io_info.do_fp_rlbypass ||
+   (io_request->RaidContext.regLockFlags == 
REGION_TYPE_UNUSED))
cmd->request_desc->SCSIIO.RequestFlags =
(MEGASAS_REQ_DESCRIPT_FLAGS_NO_LOCK <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h 
b/drivers/scsi/megaraid/megaraid_sas_fusion.h
index a1f1c0b..db0978d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
@@ -643,7 +643,8 @@ struct MR_SPAN_BLOCK_INFO {
 struct MR_LD_RAID {
struct {
 #if   defined(__BIG_ENDIAN_BITFIELD)
-   u32 reserved4:6;
+   u32 reserved4:5;
+   u32 fpBypassRegionLock:1;
u32 tmCapable:1;
u32 fpNonRWCapable:1;
u32 fpReadAcrossStripe:1;
@@ -667,7 +668,8 @@ struct MR_LD_RAID {
u32 fpReadAcrossStripe:1;
u32 fpNonRWCapable:1;
u32 tmCapable:1;
-   u32 reserved4:6;
+   u32 fpBypassRegionLock:1;
+   u32 reserved4:5;
 #endif
} capability;
__le32 reserved6;
@@ -737,7 +739,7 @@ struct IO_REQUEST_INFO {
u8 fpOkForIo;
u8 Io

[PATCH v2 15/15] megaraid_sas: driver version upgrade

2016-01-28 Thread Sumit Saxena
Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
---
 drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 3e92f20..b6fdb48 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
 /*
  * MegaRAID SAS Driver meta data
  */
-#define MEGASAS_VERSION"06.808.16.00-rc1"
-#define MEGASAS_RELDATE"Oct. 8, 2015"
+#define MEGASAS_VERSION"06.810.09.00-rc1"
+#define MEGASAS_RELDATE"Jan. 28, 2016"
 
 /*
  * Device IDs
-- 
1.8.3.1

--
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


[PATCH v2 13/15] megaraid_sas: Introduce module parameter for SCSI command-timeout

2016-01-28 Thread Sumit Saxena
This patch will introduce module-parameter for SCSI command timeout value and 
fix setting of resetwaitime beyond a value.

There was some comment from Tomas on last time sent patch regarding why should 
driver provided scmd_timeout module parameter.
This is done for special cases where user wants to tune scmd_timeout value 
during driver load time. Default value is same as before-90 secs.
There are no changes in this patch on top of last time sent patch.

Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 15 ---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  2 +-
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index d2ea977..54922e5 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -83,7 +83,7 @@ module_param(throttlequeuedepth, int, S_IRUGO);
 MODULE_PARM_DESC(throttlequeuedepth,
"Adapter queue depth when throttled due to I/O timeout. Default: 16");
 
-int resetwaittime = MEGASAS_RESET_WAIT_TIME;
+unsigned int resetwaittime = MEGASAS_RESET_WAIT_TIME;
 module_param(resetwaittime, int, S_IRUGO);
 MODULE_PARM_DESC(resetwaittime, "Wait time in seconds after I/O timeout "
 "before resetting adapter. Default: 180");
@@ -100,6 +100,10 @@ unsigned int dual_qdepth_disable;
 module_param(dual_qdepth_disable, int, S_IRUGO);
 MODULE_PARM_DESC(dual_qdepth_disable, "Disable dual queue depth feature. 
Default: 0");
 
+unsigned int scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT;
+module_param(scmd_timeout, int, S_IRUGO);
+MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default 90s. 
See megasas_reset_timer.");
+
 MODULE_LICENSE("GPL");
 MODULE_VERSION(MEGASAS_VERSION);
 MODULE_AUTHOR("megaraidlinux@avagotech.com");
@@ -1850,7 +1854,7 @@ static int megasas_slave_configure(struct scsi_device 
*sdev)
 * The RAID firmware may require extended timeouts.
 */
blk_queue_rq_timeout(sdev->request_queue,
-   MEGASAS_DEFAULT_CMD_TIMEOUT * HZ);
+   scmd_timeout * HZ);
 
return 0;
 }
@@ -2645,7 +2649,7 @@ blk_eh_timer_return megasas_reset_timer(struct scsi_cmnd 
*scmd)
unsigned long flags;
 
if (time_after(jiffies, scmd->jiffies_at_alloc +
-   (MEGASAS_DEFAULT_CMD_TIMEOUT * 2) * HZ)) {
+   (scmd_timeout * 2) * HZ)) {
return BLK_EH_NOT_HANDLED;
}
 
@@ -5254,6 +5258,11 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
instance->throttlequeuedepth =
MEGASAS_THROTTLE_QUEUE_DEPTH;
 
+   if (resetwaittime > MEGASAS_RESET_WAIT_TIME)
+   resetwaittime = MEGASAS_RESET_WAIT_TIME;
+
+   if ((scmd_timeout < 10) || (scmd_timeout > MEGASAS_DEFAULT_CMD_TIMEOUT))
+   scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT;
 
/* Launch SR-IOV heartbeat timer */
if (instance->requestorId) {
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 64926f7..e740e26 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -91,7 +91,7 @@ void megasas_start_timer(struct megasas_instance *instance,
struct timer_list *timer,
 void *fn, unsigned long interval);
 extern struct megasas_mgmt_info megasas_mgmt_info;
-extern int resetwaittime;
+extern unsigned int resetwaittime;
 extern unsigned int dual_qdepth_disable;
 static void megasas_free_rdpq_fusion(struct megasas_instance *instance);
 static void megasas_free_reply_fusion(struct megasas_instance *instance);
-- 
1.8.3.1

--
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


[PATCH v2 05/15] megaraid_sas: Update device Queue depth based on interface type

2016-01-28 Thread Sumit Saxena
This patch will update device Queue depth based on interface type(SAS, SATA..) 
for sysPDs.
For Virtual disks(VDs), there will be no change in queue depth(will remain 256).
To fetch interface type(SAS or SATA or FC..) of syspD, driver will send DCMD 
MR_DCMD_PD_GET_INFO per sysPD.

There are no changes in this patch from last time sent patch. There was some 
feedback to use dma_alloc_coherent
instead of pci_alloc_consistent which will be handled in follow up along with 
several other cases where
dma_alloc_coherent can be used.

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
---
 drivers/scsi/megaraid/megaraid_sas.h  | 270 +-
 drivers/scsi/megaraid/megaraid_sas_base.c | 127 ++
 2 files changed, 396 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 0fcb156..773fc54 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -215,6 +215,7 @@
 
 #define MR_DCMD_CTRL_SET_CRASH_DUMP_PARAMS 0x01190100
 #define MR_DRIVER_SET_APP_CRASHDUMP_MODE   (0xF001 | 0x0600)
+#define MR_DCMD_PD_GET_INFO0x0202
 
 /*
  * Global functions
@@ -435,6 +436,257 @@ enum MR_PD_STATE {
MR_PD_STATE_SYSTEM  = 0x40,
  };
 
+union MR_PD_REF {
+   struct {
+   u16  deviceId;
+   u16  seqNum;
+   } mrPdRef;
+   u32  ref;
+};
+
+/*
+ * define the DDF Type bit structure
+ */
+union MR_PD_DDF_TYPE {
+struct {
+   union {
+   struct {
+#ifndef __BIG_ENDIAN_BITFIELD
+u16 forcedPDGUID:1;
+u16 inVD:1;
+u16 isGlobalSpare:1;
+u16 isSpare:1;
+u16 isForeign:1;
+u16 reserved:7;
+u16 intf:4;
+#else
+u16 intf:4;
+u16 reserved:7;
+u16 isForeign:1;
+u16 isSpare:1;
+u16 isGlobalSpare:1;
+u16 inVD:1;
+u16 forcedPDGUID:1;
+#endif
+} pdType;
+u16 type;
+};
+u16 reserved;
+} ddf;
+struct {
+u32reserved;
+} nonDisk;
+u32 type;
+} __packed;
+
+/*
+ * defines the progress structure
+ */
+union MR_PROGRESS {
+   struct  {
+   u16 progress;
+   union {
+   u16 elapsedSecs;
+   u16 elapsedSecsForLastPercent;
+   };
+   } mrProgress;
+   u32 w;
+} __packed;
+
+/*
+ * defines the physical drive progress structure
+ */
+struct MR_PD_PROGRESS {
+   struct {
+#ifndef MFI_BIG_ENDIAN
+   u32 rbld:1;
+   u32 patrol:1;
+   u32 clear:1;
+   u32 copyBack:1;
+   u32 erase:1;
+   u32 locate:1;
+   u32 reserved:26;
+#else
+   u32 reserved:26;
+   u32 locate:1;
+   u32 erase:1;
+   u32 copyBack:1;
+   u32 clear:1;
+   u32 patrol:1;
+   u32 rbld:1;
+#endif
+   } active;
+   union MR_PROGRESS rbld;
+   union MR_PROGRESS patrol;
+   union {
+   union MR_PROGRESS clear;
+   union MR_PROGRESS erase;
+   };
+
+   struct {
+#ifndef MFI_BIG_ENDIAN
+   u32 rbld:1;
+   u32 patrol:1;
+   u32 clear:1;
+   u32 copyBack:1;
+   u32 erase:1;
+   u32 reserved:27;
+#else
+   u32 reserved:27;
+   u32 erase:1;
+   u32 copyBack:1;
+   u32 clear:1;
+   u32 patrol:1;
+   u32 rbld:1;
+#endif
+   } pause;
+
+   union MR_PROGRESS reserved[3];
+} __packed;
+
+struct  MR_PD_INFO {
+   union MR_PD_REF ref;
+   u8 inquiryData[96];
+   u8 vpdPage83[64];
+   u8 notSupported;
+   u8 scsiDevType;
+
+   union {
+   u8 connectedPortBitmap;
+   u8 connectedPortNumbers;
+   };
+
+   u8 deviceSpeed;
+   u32 mediaErrCount;
+   u32 otherErrCount;
+   u32 predFailCount;
+   u32 lastPredFailEventSeqNum;
+
+   u16 fwState;
+   u8 disabledForRemoval;
+   u8 linkSpeed;
+   union MR_PD_DDF_TYPE state;
+
+   struct {
+   u8 cou

[PATCH v2 07/15] megaraid_sas: Reply Descriptor Post Queue(RDPQ) support

2016-01-28 Thread Sumit Saxena
This patch will create reply queue pool for each MSI-x index and will provide 
array of all reply queue base address
instead of single base address of legacy mode. Using this new interface Driver 
can support higher Queue depth allocating
more reply queue as scattered DMA pool. 

If array mode is not supported driver will fall back to legacy method of 
allocation reply pool. 
This method fall back controller queue depth to 1K max. To enable more than 1K 
QD, driver expect FW to support Array mode 
and scratch_pad3 should provide new queue depth value.

Using this method, Firmware should not allow downgrade (OFU) if latest driver 
and latest FW report 4K QD and Array mode reply queue.
This type of FW upgrade may cause firmware fault and it should not be 
supported. Upgrade of FW will work, 
but queue depth of the controller will be unchanged until reboot/driver reload.

I have accomodated Tomas' comments in this patch- fix few error handling cases 
inside functions-
megasas_alloc_cmdlist_fusion() and megasas_alloc_cmds_fusion(), fix typo- 
disable(old- disbale)
in rdpq_enable module parameter's description, modify print to reflect RDPQ 
support statement correctly.


Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|   6 +-
 drivers/scsi/megaraid/megaraid_sas_base.c   |   9 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 543 
 drivers/scsi/megaraid/megaraid_sas_fusion.h |  12 +-
 4 files changed, 331 insertions(+), 239 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 01135be..3b1ed2d 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -152,6 +152,7 @@
 #define MFI_RESET_FLAGSMFI_INIT_READY| \
MFI_INIT_MFIMODE| \
MFI_INIT_ABORT
+#define MPI2_IOCINIT_MSGFLAG_RDPQ_ARRAY_MODE(0x01)
 
 /*
  * MFI frame flags
@@ -1416,6 +1417,7 @@ enum DCMD_TIMEOUT_ACTION {
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
 #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
 #define MR_MAX_MSIX_REG_ARRAY   16
+#define MR_RDPQ_MODE_OFFSET0X0080
 /*
 * register set for both 1068 and 1078 controllers
 * structure extended for 1078 registers
@@ -1455,8 +1457,9 @@ struct megasas_register_set {
 
u32 outbound_scratch_pad ;  /*00B0h*/
u32 outbound_scratch_pad_2; /*00B4h*/
+   u32 outbound_scratch_pad_3; /*00B8h*/
 
-   u32 reserved_4[2];  /*00B8h*/
+   u32 reserved_4; /*00BCh*/
 
u32 inbound_low_queue_port ;/*00C0h*/
 
@@ -2117,6 +2120,7 @@ struct megasas_instance {
u8 mask_interrupts;
u16 max_chain_frame_sz;
u8 is_imr;
+   u8 is_rdpq;
bool dev_handle;
 };
 struct MR_LD_VF_MAP {
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index ea3994b..8df58c2 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -92,6 +92,10 @@ int smp_affinity_enable = 1;
 module_param(smp_affinity_enable, int, S_IRUGO);
 MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disbale 
Default: enable(1)");
 
+int rdpq_enable = 1;
+module_param(rdpq_enable, int, S_IRUGO);
+MODULE_PARM_DESC(rdpq_enable, " Allocate reply queue in chunks for large queue 
depth enable/disable Default: disable(0)");
+
 MODULE_LICENSE("GPL");
 MODULE_VERSION(MEGASAS_VERSION);
 MODULE_AUTHOR("megaraidlinux@avagotech.com");
@@ -5080,6 +5084,9 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
instance->msix_vectors = ((scratch_pad_2
& MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>> 
MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
+   if (rdpq_enable)
+   instance->is_rdpq = (scratch_pad_2 & 
MR_RDPQ_MODE_OFFSET) ?
+   1 : 0;
fw_msix_count = instance->msix_vectors;
/* Save 1-15 reply post index address to local 
memory
 * Index 0 is already saved from reg offset
@@ -5116,6 +5123,8 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
dev_info(>pdev->dev,
"current msix/online cpus\t: (%d/%d)\n",
instance->msix_vectors, (unsigned int)num_online_cpus());
+   dev_info(>pdev->dev,
+   "RDPQ mod

[PATCH v2 12/15] megaraid_sas: MFI adapter's OCR changes

2016-01-28 Thread Sumit Saxena
Optimized MFI adapters' OCR path, particularly megasas_wait_for_outstanding() 
function.
Accomodated Tomas' comments provided on last time sent patch- remove redundant 
checks when label- kill_hba_and_failed is being called.

Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 101 +++---
 1 file changed, 50 insertions(+), 51 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 1bd5da4..d2ea977 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -2455,15 +2455,19 @@ void megasas_sriov_heartbeat_handler(unsigned long 
instance_addr)
  */
 static int megasas_wait_for_outstanding(struct megasas_instance *instance)
 {
-   int i;
+   int i, sl, outstanding;
u32 reset_index;
u32 wait_time = MEGASAS_RESET_WAIT_TIME;
unsigned long flags;
struct list_head clist_local;
struct megasas_cmd *reset_cmd;
u32 fw_state;
-   u8 kill_adapter_flag;
 
+   if (atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) {
+   dev_info(>pdev->dev, "%s:%d HBA is killed.\n",
+   __func__, __LINE__);
+   return FAILED;
+   }
 
if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) {
 
@@ -2520,7 +2524,7 @@ static int megasas_wait_for_outstanding(struct 
megasas_instance *instance)
}
 
for (i = 0; i < resetwaittime; i++) {
-   int outstanding = atomic_read(>fw_outstanding);
+   outstanding = atomic_read(>fw_outstanding);
 
if (!outstanding)
break;
@@ -2539,65 +2543,60 @@ static int megasas_wait_for_outstanding(struct 
megasas_instance *instance)
}
 
i = 0;
-   kill_adapter_flag = 0;
+   outstanding = atomic_read(>fw_outstanding);
+   fw_state = instance->instancet->read_fw_status_reg(instance->reg_set) & 
MFI_STATE_MASK;
+
+   if ((!outstanding && (fw_state == MFI_STATE_OPERATIONAL)))
+   goto no_outstanding;
+
+   if (instance->disableOnlineCtrlReset)
+   goto kill_hba_and_failed;
do {
-   fw_state = instance->instancet->read_fw_status_reg(
-   instance->reg_set) & MFI_STATE_MASK;
-   if ((fw_state == MFI_STATE_FAULT) &&
-   (instance->disableOnlineCtrlReset == 0)) {
-   if (i == 3) {
-   kill_adapter_flag = 2;
-   break;
-   }
+   if ((fw_state == MFI_STATE_FAULT) || 
atomic_read(>fw_outstanding)) {
+   dev_info(>pdev->dev,
+   "%s:%d waiting_for_outstanding: before issue 
OCR. FW state = 0x%x, oustanding 0x%x\n",
+   __func__, __LINE__, fw_state, 
atomic_read(>fw_outstanding));
+   if (i == 3)
+   goto kill_hba_and_failed;
megasas_do_ocr(instance);
-   kill_adapter_flag = 1;
 
-   /* wait for 1 secs to let FW finish the pending cmds */
-   msleep(1000);
+   if (atomic_read(>adprecovery) == 
MEGASAS_HW_CRITICAL_ERROR) {
+   dev_info(>pdev->dev, "%s:%d OCR 
failed and HBA is killed.\n",
+   __func__, __LINE__);
+   return FAILED;
+   }
+   dev_info(>pdev->dev, "%s:%d 
waiting_for_outstanding: after issue OCR.\n",
+   __func__, __LINE__);
+
+   for (sl = 0; sl < 10; sl++)
+   msleep(500);
+
+   outstanding = atomic_read(>fw_outstanding);
+
+   fw_state = 
instance->instancet->read_fw_status_reg(instance->reg_set) & MFI_STATE_MASK;
+   if ((!outstanding && (fw_state == 
MFI_STATE_OPERATIONAL)))
+   goto no_outstanding;
}
i++;
} while (i <= 3);
 
-   if (atomic_read(>fw_outstanding) && !kill_adapter_flag) {
-   if (instance->disableOnlineCtrlReset == 0) {
-   megasas_do_ocr(instance);
+no_outstanding:
 
-   /* wait for 5 secs to let FW finish the pending cmds */
-   for (i = 0; i < wait_time; i++) {
-   int outstanding =
-  

[PATCH v2 08/15] megaraid_sas: Code optimization build_and_issue_cmd return-type

2016-01-28 Thread Sumit Saxena
build_and_issue_cmd should return SCSI_MLQUEUE_HOST_BUSY for few error case 
instead of returning 1.

There are no changes in this patch from last time sent patch.

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 9 ++---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 4 ++--
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 8df58c2..edf8911 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1636,7 +1636,7 @@ megasas_build_and_issue_cmd(struct megasas_instance 
*instance,
return 0;
 out_return_cmd:
megasas_return_cmd(instance, cmd);
-   return 1;
+   return SCSI_MLQUEUE_HOST_BUSY;
 }
 
 
@@ -1728,12 +1728,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
scsi_cmnd *scmd)
break;
}
 
-   if (instance->instancet->build_and_issue_cmd(instance, scmd)) {
-   dev_err(>pdev->dev, "Err returned from 
build_and_issue_cmd\n");
-   return SCSI_MLQUEUE_HOST_BUSY;
-   }
-
-   return 0;
+   return instance->instancet->build_and_issue_cmd(instance, scmd);
 
  out_done:
scmd->scsi_done(scmd);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 1351cae..f553830 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2125,7 +2125,7 @@ megasas_build_and_issue_cmd_fusion(struct 
megasas_instance *instance,
 
req_desc = megasas_get_request_descriptor(instance, index-1);
if (!req_desc)
-   return 1;
+   return SCSI_MLQUEUE_HOST_BUSY;
 
req_desc->Words = 0;
cmd->request_desc = req_desc;
@@ -2134,7 +2134,7 @@ megasas_build_and_issue_cmd_fusion(struct 
megasas_instance *instance,
megasas_return_cmd_fusion(instance, cmd);
dev_err(>pdev->dev, "Error building command\n");
cmd->request_desc = NULL;
-   return 1;
+   return SCSI_MLQUEUE_HOST_BUSY;
}
 
req_desc = cmd->request_desc;
-- 
1.8.3.1

--
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


[PATCH v2 14/15] megaraid_sas: SPERC OCR changes

2016-01-28 Thread Sumit Saxena
This patch will do some fixes in OCR path of SRIOV enabled series of Avago 
controllers.

1)Removing late detection HB. 
2)Change in the behavior if the FW found in READY/OPERAETIONAL state.

There are no changes in this patch from last time sent patch.

Signed-off-by: Uday Lingala <uday.ling...@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Reviewed-by: Tomas Henzl <the...@redhat.com>
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 73 +++--
 1 file changed, 16 insertions(+), 57 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index e740e26..be9c3f1 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -3462,52 +3462,7 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int 
reason)
/* Let SR-IOV VF & PF sync up if there was a HB failure */
if (instance->requestorId && !reason) {
msleep(MEGASAS_OCR_SETTLE_TIME_VF);
-   /* Look for a late HB update after VF settle time */
-   if (abs_state == MFI_STATE_OPERATIONAL &&
-   (instance->hb_host_mem->HB.fwCounter !=
-instance->hb_host_mem->HB.driverCounter)) {
-   instance->hb_host_mem->HB.driverCounter 
=
-   
instance->hb_host_mem->HB.fwCounter;
-   dev_warn(>pdev->dev, "SR-IOV:"
-  "Late FW heartbeat update for "
-  "scsi%d.\n",
-  instance->host->host_no);
-   } else {
-   /* In VF mode, first poll for FW ready */
-   for (i = 0;
-i < (MEGASAS_RESET_WAIT_TIME * 1000);
-i += 20) {
-   status_reg =
-   instance->instancet->
-   read_fw_status_reg(
-   instance->reg_set);
-   abs_state = status_reg &
-   MFI_STATE_MASK;
-   if (abs_state == MFI_STATE_READY) {
-   dev_warn(>pdev->dev,
-  "SR-IOV: FW was found"
-  "to be in ready state "
-  "for scsi%d.\n",
-  instance->host->host_no);
-   break;
-   }
-   msleep(20);
-   }
-   if (abs_state != MFI_STATE_READY) {
-   dev_warn(>pdev->dev, "SR-IOV: 
"
-  "FW not in ready state after %d"
-  " seconds for scsi%d, status_reg 
= "
-  "0x%x.\n",
-  MEGASAS_RESET_WAIT_TIME,
-  instance->host->host_no,
-  status_reg);
-   megaraid_sas_kill_hba(instance);
-   instance->skip_heartbeat_timer_del = 1;
-   atomic_set(>adprecovery, 
MEGASAS_HW_CRITICAL_ERROR);
-   retval = FAILED;
-   goto out;
-   }
-   }
+   goto transition_to_ready;
}
 
/* Now try to reset the chip */
@@ -3516,25 +3471,28 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int 
reason)
if (instance->instancet->adp_reset
(instance, instance->reg_set))
continue;
-
+transition_to_ready:
/* Wait for FW to become ready */
if (megasas_transition_to_ready(instance, 1)) {
-   dev_warn(>pdev->dev, "Failed to "
-  

[PATCH v2 11/15] megaraid_sas: Make adprecovery variable atomic

2016-01-28 Thread Sumit Saxena
Make instance->adprecovery variable atomic and removes hba_lock spinlock while 
accessing instance->adprecovery.

Tomas commented on last time sent patch asking to use u8 instead of atomic for 
adprecovery. I agree that atomic_t is not required
here but this is done for not to touch legacy code of MFI adapters and replace 
hba_lock with atomic_t so there are no changes
in this patch on top of last time sent patch.

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|  2 +-
 drivers/scsi/megaraid/megaraid_sas_base.c   | 95 +++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 27 
 3 files changed, 50 insertions(+), 74 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index c8d25a7..3e92f20 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2101,7 +2101,7 @@ struct megasas_instance {
u16 drv_supported_vd_count;
u16 drv_supported_pd_count;
 
-   u8 adprecovery;
+   atomic_t adprecovery;
unsigned long last_time;
u32 mfiStatus;
u32 last_seq_num;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 961c024..1bd5da4 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -483,7 +483,7 @@ static int
 megasas_check_reset_xscale(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
 {
-   if ((instance->adprecovery != MEGASAS_HBA_OPERATIONAL) &&
+   if ((atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL) &&
(le32_to_cpu(*instance->consumer) ==
MEGASAS_ADPRESET_INPROG_SIGN))
return 1;
@@ -619,7 +619,7 @@ static int
 megasas_check_reset_ppc(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
 {
-   if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL)
+   if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL)
return 1;
 
return 0;
@@ -756,7 +756,7 @@ static int
 megasas_check_reset_skinny(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
 {
-   if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL)
+   if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL)
return 1;
 
return 0;
@@ -950,9 +950,8 @@ static int
 megasas_check_reset_gen2(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
 {
-   if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) {
+   if (atomic_read(>adprecovery) != MEGASAS_HBA_OPERATIONAL)
return 1;
-   }
 
return 0;
 }
@@ -998,7 +997,7 @@ megasas_issue_polled(struct megasas_instance *instance, 
struct megasas_cmd *cmd)
frame_hdr->cmd_status = MFI_STAT_INVALID_STATUS;
frame_hdr->flags |= cpu_to_le16(MFI_FRAME_DONT_POST_IN_REPLY_QUEUE);
 
-   if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+   if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) 
||
(instance->instancet->issue_dcmd(instance, cmd))) {
dev_err(>pdev->dev, "Failed from %s %d\n",
__func__, __LINE__);
@@ -1026,7 +1025,7 @@ megasas_issue_blocked_cmd(struct megasas_instance 
*instance,
int ret = 0;
cmd->cmd_status_drv = MFI_STAT_INVALID_STATUS;
 
-   if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+   if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) 
||
(instance->instancet->issue_dcmd(instance, cmd))) {
dev_err(>pdev->dev, "Failed from %s %d\n",
__func__, __LINE__);
@@ -1090,7 +1089,7 @@ megasas_issue_blocked_abort_cmd(struct megasas_instance 
*instance,
cmd->sync_cmd = 1;
cmd->cmd_status_drv = MFI_STAT_INVALID_STATUS;
 
-   if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+   if ((atomic_read(>adprecovery) == MEGASAS_HW_CRITICAL_ERROR) 
||
(instance->instancet->issue_dcmd(instance, cmd))) {
dev_err(>pdev->dev, "Failed from %s %d\n",
__func__, __LINE__);
@@ -1653,7 +1652,6 @@ static int
 megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd)
 {
struct megasas_instance *instance;
-   unsigned long flags;
struct MR_PRIV_DEVICE *mr_device_priv_data;
 
instance = (struct megasas_instance *)
@@ -1668,24 +1666,20 @@ megasas_queue_command(struct Scsi_Host *shost, struct 
scsi_cmnd *scmd)
if (instance->issuepe

[PATCH v2 09/15] megaraid_sas: Dual Queue depth support

2016-01-28 Thread Sumit Saxena
This patch will add support for Dual Queue depth reported by firmware.

Below are key points-

1. For iMR controllers, firmware will report two queue depths- 1. Controller 
wide Queue depth 2. LDIO Queue depth(240).
Ofcourse, Controller wide Queue depth will be greater among two. Using this new 
method, iMR can provide larger Queue depth(QD)
for JBOD and limited QD for Virtual Disk(VD). This feature gives benefit for 
iMR product which will be used for deployment
with large number of JBOD and limited number of VD on setup. 
2. megaraid_sas driver will throttle Read write LDIOs based when RW LDIOs 
reaches "LDIO Queue Depth".
3. This feature of dual queue depth can enabled/disabled via module parameter. 
Default behavior is: Dual Queue depth is enabled.
4. Added sysfs parameter "ldio_outstanding" for user to read LDIO outstanding 
at run time.
5. There are different flavors of firmware using same driver and for specific 
firmware this will be
turned on(by default) where it's really needed. For rest of firmware flavors, 
this will be switched off(not supported).

I have accomodated Tomas' comments provided on last time sent patch- use 
atomic_inc_return instead of using atomic_read() and
atomic_inc() separately inside function- megasas_build_and_issue_cmd_fusion(). 

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
---
 drivers/scsi/megaraid/megaraid_sas.h|  9 +++
 drivers/scsi/megaraid/megaraid_sas_base.c   | 20 ++-
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 88 ++---
 3 files changed, 107 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 3b1ed2d..2a2f491 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1353,6 +1353,12 @@ enum DCMD_TIMEOUT_ACTION {
KILL_ADAPTER = 1,
IGNORE_TIMEOUT = 2,
 };
+
+enum FW_BOOT_CONTEXT {
+   PROBE_CONTEXT = 0,
+   OCR_CONTEXT = 1,
+};
+
 /* Frame Type */
 #define IO_FRAME   0
 #define PTHRU_FRAME1
@@ -2038,6 +2044,8 @@ struct megasas_instance {
u16 max_fw_cmds;
u16 max_mfi_cmds;
u16 max_scsi_cmds;
+   u16 ldio_threshold;
+   u16 cur_can_queue;
u32 max_sectors_per_req;
struct megasas_aen_event *ev;
 
@@ -2068,6 +2076,7 @@ struct megasas_instance {
u32 fw_support_ieee;
 
atomic_t fw_outstanding;
+   atomic_t ldio_outstanding;
atomic_t fw_reset_no_pci_access;
 
struct megasas_instance_template *instancet;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index edf8911..961c024 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -96,6 +96,10 @@ int rdpq_enable = 1;
 module_param(rdpq_enable, int, S_IRUGO);
 MODULE_PARM_DESC(rdpq_enable, " Allocate reply queue in chunks for large queue 
depth enable/disable Default: disable(0)");
 
+unsigned int dual_qdepth_disable;
+module_param(dual_qdepth_disable, int, S_IRUGO);
+MODULE_PARM_DESC(dual_qdepth_disable, "Disable dual queue depth feature. 
Default: 0");
+
 MODULE_LICENSE("GPL");
 MODULE_VERSION(MEGASAS_VERSION);
 MODULE_AUTHOR("megaraidlinux@avagotech.com");
@@ -1976,7 +1980,7 @@ megasas_check_and_restore_queue_depth(struct 
megasas_instance *instance)
spin_lock_irqsave(instance->host->host_lock, flags);
instance->flag &= ~MEGASAS_FW_BUSY;
 
-   instance->host->can_queue = instance->max_scsi_cmds;
+   instance->host->can_queue = instance->cur_can_queue;
spin_unlock_irqrestore(instance->host->host_lock, flags);
}
 }
@@ -2941,6 +2945,16 @@ megasas_page_size_show(struct device *cdev,
return snprintf(buf, PAGE_SIZE, "%ld\n", (unsigned long)PAGE_SIZE - 1);
 }
 
+static ssize_t
+megasas_ldio_outstanding_show(struct device *cdev, struct device_attribute 
*attr,
+   char *buf)
+{
+   struct Scsi_Host *shost = class_to_shost(cdev);
+   struct megasas_instance *instance = (struct megasas_instance 
*)shost->hostdata;
+
+   return snprintf(buf, PAGE_SIZE, "%d\n", 
atomic_read(>ldio_outstanding));
+}
+
 static DEVICE_ATTR(fw_crash_buffer, S_IRUGO | S_IWUSR,
megasas_fw_crash_buffer_show, megasas_fw_crash_buffer_store);
 static DEVICE_ATTR(fw_crash_buffer_size, S_IRUGO,
@@ -2949,12 +2963,15 @@ static DEVICE_ATTR(fw_crash_state, S_IRUGO | S_IWUSR,
megasas_fw_crash_state_show, megasas_fw_crash_state_store);
 static DEVICE_ATTR(page_size, S_IRUGO,
megasas_page_size_show, NULL);
+static DEVICE_ATTR(ldio_outstanding, S_IRUGO,
+   megasas_ldio_outstanding_show, NULL);
 
 struct devi

[PATCH v2 10/15] megaraid_sas: IO throttling support

2016-01-28 Thread Sumit Saxena
This patch will add capability in driver to tell firmware that it can throttle 
IOs in case Controller's Queue depth is downgraded post OFU
(Online firmware upgrade). This feature will ensure firmware can be downgraded 
from higher queue depth to lower queue depth without needing system reboot.
Added throttling code in IO path of driver, in case OS tries to send more IOs 
than post OFU firmware's queue depth.

I have accomodated Tomas' comments provided on last time sent patch- removed 
the un-necessary code of throttling of IOs against can_queue inside
function- megasas_build_and_issue_cmd_fusion() as SCSI mid layer will anyways 
does this.

Signed-off-by: Sumit Saxena <sumit.sax...@avagotech.com>
Signed-off-by: Kashyap Desai <kashyap.de...@avagotech.com>
---
 drivers/scsi/megaraid/megaraid_sas.h| 6 --
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index 2a2f491..c8d25a7 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1537,7 +1537,8 @@ union megasas_sgl_frame {
 typedef union _MFI_CAPABILITIES {
struct {
 #if   defined(__BIG_ENDIAN_BITFIELD)
-   u32 reserved:21;
+   u32 reserved:20;
+   u32 support_qd_throttling:1;
u32 support_fp_rlbypass:1;
u32 support_vfid_in_ioframe:1;
u32 support_ext_io_size:1;
@@ -1561,7 +1562,8 @@ typedef union _MFI_CAPABILITIES {
u32 support_ext_io_size:1;
u32 support_vfid_in_ioframe:1;
u32 support_fp_rlbypass:1;
-   u32 reserved:21;
+   u32 support_qd_throttling:1;
+   u32 reserved:20;
 #endif
} mfi_capabilities;
__le32  reg;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 6b8547c..2c4912f 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -803,6 +803,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance)
if (!dual_qdepth_disable)
drv_ops->mfi_capabilities.support_ext_queue_depth = 1;
 
+   drv_ops->mfi_capabilities.support_qd_throttling = 1;
/* Convert capability to LE32 */
cpu_to_le32s((u32 *)_frame->driver_operations.mfi_capabilities);
 
-- 
1.8.3.1

--
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


  1   2   3   >