[Bug 179341] mpt3sas: LSISAS3008 don't see Intel 540s SSD

2016-10-20 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=179341

--- Comment #2 from Badalyan Vyacheslav  ---
Adapter Selected is a Avago SAS: SAS3008(C0)

Num   CtlrFW VerNVDATAx86-BIOS PCI Addr


0  SAS3008(C0)  13.00.00.000b.02.00.0308.31.00.00 00:0a:00:00
1  SAS3008(C0)  13.00.00.000b.02.00.0308.31.00.00 00:08:00:00

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
--
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

[Bug 179341] mpt3sas: LSISAS3008 don't see Intel 540s SSD

2016-10-20 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=179341

--- Comment #1 from Badalyan Vyacheslav  ---
I was change product and component

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
--
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

Ahoj....

2016-10-20 Thread Ko M. Leung 



Ahoj.

Dobry vecer a jak se mas? Jen rychly jedno, je tu oficialni prilezitosti 
bych chtel diskutovat s vami soukrome.


Ocenil bych vasi rychlou reakci tady na mem osobnim soukromeho e-mailu 
nize pro dalsi komunikaci.


S pratelskym pozdravem,
Paní Ko May Leung
email: kmyln...@gmail.com
Místopredseda, Managing Director
a vykonny reditel Chong Hing Bank Limited

--
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 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-20 Thread Michal Hocko 
On Wed 19-10-16 10:23:55, Dave Hansen wrote:
> On 10/19/2016 10:01 AM, Michal Hocko wrote:
> > The question I had earlier was whether this has to be an explicit FOLL
> > flag used by g-u-p users or we can just use it internally when mm !=
> > current->mm
> 
> The reason I chose not to do that was that deferred work gets run under
> a basically random 'current'.  If we just use 'mm != current->mm', then
> the deferred work will sometimes have pkeys enforced and sometimes not,
> basically randomly.

OK, I see (async_pf_execute and ksm ). It makes more sense to me. Thanks
for the clarification.

-- 
Michal Hocko
SUSE Labs
--
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 1/2] scsi: Handle Unit Attention when issuing SCSI command

2016-10-20 Thread James Bottomley 
On Mon, 2016-10-17 at 14:17 -0200, Gabriel Krisman Bertazi wrote:
> James Bottomley  writes:
> 
> > On Thu, 2016-10-13 at 15:47 -0300, Gabriel Krisman Bertazi wrote:
> > > @@ -210,6 +219,13 @@ int scsi_execute(struct scsi_device *sdev,
> > > const
> > > unsigned char *cmd,
> > >*/
> > >   blk_execute_rq(req->q, NULL, req, 1);
> > >  
> > > + if (scsi_sense_unit_attention(sense) && req->retries >
> > > 0) {
> > > + memset(sense, 0, SCSI_SENSE_BUFFERSIZE);
> > > + retries = req->retries - 1;
> > > + blk_put_request(req);
> > > + goto retry;
> > > + }
> > 
> > OK, so this is more theory, but I think you can actually reuse the
> > same
> > request to go around this loop without doing a get/put.  I've cc'd
> > Jens
> > to confirm, since no other driver I can find does this, but if it's
> > legal, it saves freeing and reallocating the request.  You can then
> > replace the goto with a do { } while (...) which makes the loop
> > obvious
> > to the next person looking at this.
> 
> Hi James,
> 
> I don't think the block layer currently has the machinery to reuse 
> the request.  I think it would be easy to add for the MQ case but I
> don't know about SQ.  If we don't clean up or reinit the request 
> before re-sending, we'll hit the BUG_ON in blk_start_request:
> 
>   BUG_ON(test_bit(REQ_ATOM_COMPLETE, >atomic_flags));
> 
> Do you wanna take a v3 of the patch and fix this on a future patch, 


That works.  I certainly believe, looking at the code, that we can
reuse the request, but in the absence from confirmation from Jens I'm
certainly not going to insist on it.

James

> or should I be looking into patching the block layer interface?  I'll
> be looking into it, but I need to get familiar with the SQ code
> first.



--
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 v3 0/11] Fix race conditions related to stopping block layer queues

2016-10-20 Thread Keith Busch 
On Wed, Oct 19, 2016 at 04:51:18PM -0700, Bart Van Assche wrote:
> 
> I assume that line 498 in blk-mq.c corresponds to BUG_ON(blk_queued_rq(rq))?
> Anyway, it seems to me like this is a bug in the NVMe code and also that
> this bug is completely unrelated to my patch series. In nvme_complete_rq() I
> see that blk_mq_requeue_request() is called. I don't think this is allowed
> from the context of nvme_cancel_request() because blk_mq_requeue_request()
> assumes that a request has already been removed from the request list.
> However, neither blk_mq_tagset_busy_iter() nor nvme_cancel_request() remove
> a request from the request list before nvme_complete_rq() is called. I think
> this is what triggers the BUG_ON() statement in blk_mq_requeue_request().
> Have you noticed that e.g. the scsi-mq code only calls
> blk_mq_requeue_request() after __blk_mq_end_request() has finished? Have you
> considered to follow the same approach in nvme_cancel_request()?

Both nvme and scsi requeue through their mp_ops 'complete' callback, so
nvme is similarly waiting for __blk_mq_end_request before requesting to
requeue. The problem, I think, is nvme's IO cancelling path is observing
active requests that it's requeuing from the queue_rq path.

Patch [11/11] kicks the requeue list unconditionally. This restarts queues
the driver had just quiesced a moment before, restarting those requests,
but the driver isn't ready to handle them. When the driver ultimately
unbinds from the device, it requeues those requests a second time.

Either the requeuing can't kick the requeue work when queisced, or the
shutdown needs to quiesce even when it hasn't restarted the queues.
Either patch below appears to fix the issue.

---
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index ccd9cc5..078530c 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -201,7 +201,7 @@ static struct nvme_ns *nvme_get_ns_from_disk(struct gendisk 
*disk)
 
 void nvme_requeue_req(struct request *req)
 {
-   blk_mq_requeue_request(req, true);
+   blk_mq_requeue_request(req, !blk_mq_queue_stopped(req->q));
 }
 EXPORT_SYMBOL_GPL(nvme_requeue_req);
--

--- 
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 4b30fa2..a05da98 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1681,10 +1681,9 @@ static void nvme_dev_disable(struct nvme_dev *dev, bool 
shutdown)
del_timer_sync(>watchdog_timer);
 
mutex_lock(>shutdown_lock);
-   if (pci_is_enabled(to_pci_dev(dev->dev))) {
-   nvme_stop_queues(>ctrl);
+   nvme_stop_queues(>ctrl);
+   if (pci_is_enabled(to_pci_dev(dev->dev)))
csts = readl(dev->bar + NVME_REG_CSTS);
-   }
 
queues = dev->online_queues - 1;
for (i = dev->queue_count - 1; i > 0; i--)
--
--
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: [RFC 2/6] qed: Add iSCSI out of order packet handling.

2016-10-20 Thread Mintz, Yuval 
> > This patch adds out of order packet handling for hardware offloaded
> > iSCSI. Out of order packet handling requires driver buffer allocation
> > and assistance.
> >
> > Signed-off-by: Arun Easi 
> > Signed-off-by: Yuval Mintz 
> >
> Hmm. The entire out-of-order handling is pretty generic. I really wonder
> if this doesn't apply to iSCSI in general; surely iscsi_tcp suffers from
> the same problem, no?
> If so, wouldn't it be better to move it into generic (iSCSI) code so
> that all implementations would benefit from it?

[disclaimer - I'm far from knowledgeable in iscsi ]

I agree that the problem of out-of-order handling is probably generic,
but our solution is very device oriented.
As the device lacks [a lot of] internal memory, it uses the host memory
for out-of-order buffers and the driver assistance in pushing them when
they are needed.
>From driver perspective, all the data is completely opaque; All it does is
follow the firmware's guidance in storing & re-transmitting buffers when
required.

Now, I guess the logic could be divided between hardware-specifics -
Interaction with 'client' [in our case, device's firmware], to receive
new data, instructions regarding placement and re-transmission,
and a lower generic data structure which supports manipulation of
buffers [push-left, push-right, join, etc.].

But given that the data-structure would completely lacks all
protocol-knowledge [as our implementation doesn't have nor require such],
I think there would be very little gain - we might find out that as much
as 80% of the code is device interaction, and the remaining so-called
'generic' data-structure won't be that useful to other clients as it was
closely tied to our device needs and API.

Either way, placing this under iscsi would probably be insufficient for our
future needs, as our qed-iwarp driver would also require this functionality.

Thanks,
Yuval



--
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 06/10] mpt3sas: Added Device ID's for SAS35 devices and updated MPI header.

2016-10-20 Thread Suganath Prabu S 
Added Device ID's for SAS35 devices (Ventura, Crusader, Harpoon &
Tomcat) and updated mpi header file for the same. Also added
"is_gen35_ioc" to MPT3SAS_ADAPTER structure for identifying SAS35 adapters.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h |  7 +++
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  1 +
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  5 -
 drivers/scsi/mpt3sas/mpt3sas_ctl.h   |  1 +
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 31 +++
 5 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index 95356a8..fa61baf 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -478,6 +478,13 @@ typedef struct _MPI2_CONFIG_REPLY {
 #define MPI26_MFGPAGE_DEVID_SAS3324_3   (0x00C2)
 #define MPI26_MFGPAGE_DEVID_SAS3324_4   (0x00C3)
 
+#define MPI26_MFGPAGE_DEVID_SAS3516 (0x00AA)
+#define MPI26_MFGPAGE_DEVID_SAS3516_1   (0x00AB)
+#define MPI26_MFGPAGE_DEVID_SAS3416 (0x00AC)
+#define MPI26_MFGPAGE_DEVID_SAS3508 (0x00AD)
+#define MPI26_MFGPAGE_DEVID_SAS3508_1   (0x00AE)
+#define MPI26_MFGPAGE_DEVID_SAS3408 (0x00AF)
+
 /*Manufacturing Page 0 */
 
 typedef struct _MPI2_CONFIG_PAGE_MAN_0 {
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 6f03a86..3d75c57 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -1191,6 +1191,7 @@ struct MPT3SAS_ADAPTER {
struct SL_WH_MPI_TRIGGERS_T diag_trigger_mpi;
void*device_remove_in_progress;
u16 device_remove_in_progress_sz;
+   u8  is_gen35_ioc;
 };
 
 typedef u8 (*MPT_CALLBACK)(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index,
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index f204ce1..62be7d4 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -1096,7 +1096,10 @@ _ctl_getiocinfo(struct MPT3SAS_ADAPTER *ioc, void __user 
*arg)
break;
case MPI25_VERSION:
case MPI26_VERSION:
-   karg.adapter_type = MPT3_IOCTL_INTERFACE_SAS3;
+   if (ioc->is_gen35_ioc)
+   karg.adapter_type = MPT3_IOCTL_INTERFACE_SAS35;
+   else
+   karg.adapter_type = MPT3_IOCTL_INTERFACE_SAS3;
strcat(karg.driver_version, MPT3SAS_DRIVER_VERSION);
break;
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.h 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.h
index 8940835..f3e17a8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.h
@@ -143,6 +143,7 @@ struct mpt3_ioctl_pci_info {
 #define MPT2_IOCTL_INTERFACE_SAS2  (0x04)
 #define MPT2_IOCTL_INTERFACE_SAS2_SSS6200  (0x05)
 #define MPT3_IOCTL_INTERFACE_SAS3  (0x06)
+#define MPT3_IOCTL_INTERFACE_SAS35 (0x07)
 #define MPT2_IOCTL_VERSION_LENGTH  (32)
 
 /**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 9584d6b..521849d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -8660,6 +8660,12 @@ _scsih_determine_hba_mpi_version(struct pci_dev *pdev)
case MPI26_MFGPAGE_DEVID_SAS3324_2:
case MPI26_MFGPAGE_DEVID_SAS3324_3:
case MPI26_MFGPAGE_DEVID_SAS3324_4:
+   case MPI26_MFGPAGE_DEVID_SAS3508:
+   case MPI26_MFGPAGE_DEVID_SAS3508_1:
+   case MPI26_MFGPAGE_DEVID_SAS3408:
+   case MPI26_MFGPAGE_DEVID_SAS3516:
+   case MPI26_MFGPAGE_DEVID_SAS3516_1:
+   case MPI26_MFGPAGE_DEVID_SAS3416:
return MPI26_VERSION;
}
return 0;
@@ -8728,6 +8734,18 @@ _scsih_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
ioc->hba_mpi_version_belonged = hba_mpi_version;
ioc->id = mpt3_ids++;
sprintf(ioc->driver_name, "%s", MPT3SAS_DRIVER_NAME);
+   switch (pdev->device) {
+   case MPI26_MFGPAGE_DEVID_SAS3508:
+   case MPI26_MFGPAGE_DEVID_SAS3508_1:
+   case MPI26_MFGPAGE_DEVID_SAS3408:
+   case MPI26_MFGPAGE_DEVID_SAS3516:
+   case MPI26_MFGPAGE_DEVID_SAS3516_1:
+   case MPI26_MFGPAGE_DEVID_SAS3416:
+   ioc->is_gen35_ioc = 1;
+   break;
+   default:
+   ioc->is_gen35_ioc = 0;
+   }
if ((ioc->hba_mpi_version_belonged == MPI25_VERSION &&
pdev->revision >= SAS3_PCI_DEVICE_C0_REVISION) ||

[PATCH 10/10] mpt3sas: Fix for Endianness issue.

2016-10-20 Thread Suganath Prabu S 
Use le16_to_cpu only for accessing two byte data provided by controller.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 6d17f66..981be7b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -5384,10 +5384,10 @@ _scsih_check_device(struct MPT3SAS_ADAPTER *ioc,
sas_device->handle, handle);
sas_target_priv_data->handle = handle;
sas_device->handle = handle;
-   if (sas_device_pg0.Flags &
+   if (le16_to_cpu(sas_device_pg0.Flags) &
 MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
-   le16_to_cpu(sas_device_pg0.EnclosureLevel);
+   sas_device_pg0.EnclosureLevel;
memcpy(sas_device->connector_name,
sas_device_pg0.ConnectorName, 4);
sas_device->connector_name[4] = '\0';
@@ -5516,9 +5516,10 @@ _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16 
handle, u8 phy_num,
sas_device->fast_path = (le16_to_cpu(sas_device_pg0.Flags) &
MPI25_SAS_DEVICE0_FLAGS_FAST_PATH_CAPABLE) ? 1 : 0;
 
-   if (sas_device_pg0.Flags & MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
+   if (le16_to_cpu(sas_device_pg0.Flags)
+   & MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
-   le16_to_cpu(sas_device_pg0.EnclosureLevel);
+   sas_device_pg0.EnclosureLevel;
memcpy(sas_device->connector_name,
sas_device_pg0.ConnectorName, 4);
sas_device->connector_name[4] = '\0';
@@ -7056,7 +7057,7 @@ Mpi2SasDevicePage0_t *sas_device_pg0)
if (sas_device_pg0->Flags &
  MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
-  le16_to_cpu(sas_device_pg0->EnclosureLevel);
+  sas_device_pg0->EnclosureLevel;
memcpy(_device->connector_name[0],
_device_pg0->ConnectorName[0], 4);
} else {
@@ -7118,6 +7119,7 @@ _scsih_search_responding_sas_devices(struct 
MPT3SAS_ADAPTER *ioc)
sas_device_pg0.SASAddress =
le64_to_cpu(sas_device_pg0.SASAddress);
sas_device_pg0.Slot = le16_to_cpu(sas_device_pg0.Slot);
+   sas_device_pg0.Flags = le16_to_cpu(sas_device_pg0.Flags);
_scsih_mark_responding_sas_device(ioc, _device_pg0);
}
 
-- 
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 09/10] mpt3sas: Use the new MPI 2.6 32-bit Atomic Request Descriptors for SAS35 devices.

2016-10-20 Thread Suganath Prabu S 
Support Atomic Request Descriptors for Ventura/SAS35 devices.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 141 +++
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  18 ++--
 drivers/scsi/mpt3sas/mpt3sas_config.c|   2 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  22 ++---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |  24 +++---
 drivers/scsi/mpt3sas/mpt3sas_transport.c |   8 +-
 6 files changed, 161 insertions(+), 54 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 43cdc02..f00ef88 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -849,7 +849,7 @@ _base_async_event(struct MPT3SAS_ADAPTER *ioc, u8 
msix_index, u32 reply)
ack_request->EventContext = mpi_reply->EventContext;
ack_request->VF_ID = 0;  /* TODO */
ack_request->VP_ID = 0;
-   mpt3sas_base_put_smid_default(ioc, smid);
+   ioc->put_smid_default(ioc, smid);
 
  out:
 
@@ -2464,15 +2464,15 @@ _base_writeq(__u64 b, volatile void __iomem *addr, 
spinlock_t *writeq_lock)
 #endif
 
 /**
- * mpt3sas_base_put_smid_scsi_io - send SCSI_IO request to firmware
+ * _base_put_smid_scsi_io - send SCSI_IO request to firmware
  * @ioc: per adapter object
  * @smid: system request message index
  * @handle: device handle
  *
  * Return nothing.
  */
-void
-mpt3sas_base_put_smid_scsi_io(struct MPT3SAS_ADAPTER *ioc, u16 smid, u16 
handle)
+static void
+_base_put_smid_scsi_io(struct MPT3SAS_ADAPTER *ioc, u16 smid, u16 handle)
 {
Mpi2RequestDescriptorUnion_t descriptor;
u64 *request = (u64 *)
@@ -2488,15 +2488,15 @@ mpt3sas_base_put_smid_scsi_io(struct MPT3SAS_ADAPTER 
*ioc, u16 smid, u16 handle)
 }
 
 /**
- * mpt3sas_base_put_smid_fast_path - send fast path request to firmware
+ * _base_put_smid_fast_path - send fast path request to firmware
  * @ioc: per adapter object
  * @smid: system request message index
  * @handle: device handle
  *
  * Return nothing.
  */
-void
-mpt3sas_base_put_smid_fast_path(struct MPT3SAS_ADAPTER *ioc, u16 smid,
+static void
+_base_put_smid_fast_path(struct MPT3SAS_ADAPTER *ioc, u16 smid,
u16 handle)
 {
Mpi2RequestDescriptorUnion_t descriptor;
@@ -2513,14 +2513,14 @@ mpt3sas_base_put_smid_fast_path(struct MPT3SAS_ADAPTER 
*ioc, u16 smid,
 }
 
 /**
- * mpt3sas_base_put_smid_hi_priority - send Task Managment request to firmware
+ * _base_put_smid_hi_priority - send Task Management request to firmware
  * @ioc: per adapter object
  * @smid: system request message index
  * @msix_task: msix_task will be same as msix of IO incase of task abort else 
0.
  * Return nothing.
  */
-void
-mpt3sas_base_put_smid_hi_priority(struct MPT3SAS_ADAPTER *ioc, u16 smid,
+static void
+_base_put_smid_hi_priority(struct MPT3SAS_ADAPTER *ioc, u16 smid,
u16 msix_task)
 {
Mpi2RequestDescriptorUnion_t descriptor;
@@ -2537,14 +2537,14 @@ mpt3sas_base_put_smid_hi_priority(struct 
MPT3SAS_ADAPTER *ioc, u16 smid,
 }
 
 /**
- * mpt3sas_base_put_smid_default - Default, primarily used for config pages
+ * _base_put_smid_default - Default, primarily used for config pages
  * @ioc: per adapter object
  * @smid: system request message index
  *
  * Return nothing.
  */
-void
-mpt3sas_base_put_smid_default(struct MPT3SAS_ADAPTER *ioc, u16 smid)
+static void
+_base_put_smid_default(struct MPT3SAS_ADAPTER *ioc, u16 smid)
 {
Mpi2RequestDescriptorUnion_t descriptor;
u64 *request = (u64 *)
@@ -2559,6 +2559,95 @@ mpt3sas_base_put_smid_default(struct MPT3SAS_ADAPTER 
*ioc, u16 smid)
 }
 
 /**
+* _base_put_smid_scsi_io_atomic - send SCSI_IO request to firmware using
+*   Atomic Request Descriptor
+* @ioc: per adapter object
+* @smid: system request message index
+* @handle: device handle, unused in this function, for function type match
+*
+* Return nothing.
+*/
+static void
+_base_put_smid_scsi_io_atomic(struct MPT3SAS_ADAPTER *ioc, u16 smid,
+   u16 handle)
+{
+   Mpi26AtomicRequestDescriptor_t descriptor;
+   u32 *request = (u32 *)
+
+   descriptor.RequestFlags = MPI2_REQ_DESCRIPT_FLAGS_SCSI_IO;
+   descriptor.MSIxIndex = _base_get_msix_index(ioc);
+   descriptor.SMID = cpu_to_le16(smid);
+
+   writel(cpu_to_le32(*request), >chip->AtomicRequestDescriptorPost);
+}
+
+/**
+ * _base_put_smid_fast_path_atomic - send fast path request to firmware
+ * using Atomic Request Descriptor
+ * @ioc: per adapter object
+ * @smid: system request message index
+ * @handle: device handle, unused in this function, for function type match
+ * Return nothing
+ */
+static void
+_base_put_smid_fast_path_atomic(struct MPT3SAS_ADAPTER *ioc, u16 smid,
+   u16 handle)
+{
+   Mpi26AtomicRequestDescriptor_t descriptor;
+   u32 *request = (u32 *)
+
+

[PATCH 05/10] mpt3sas: Bump driver version as "14.100.00.00"

2016-10-20 Thread Suganath Prabu S 
Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index e923c91..6f03a86 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -73,8 +73,8 @@
 #define MPT3SAS_DRIVER_NAME"mpt3sas"
 #define MPT3SAS_AUTHOR "Avago Technologies "
 #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver"
-#define MPT3SAS_DRIVER_VERSION "13.100.00.00"
-#define MPT3SAS_MAJOR_VERSION  13
+#define MPT3SAS_DRIVER_VERSION "14.100.00.00"
+#define MPT3SAS_MAJOR_VERSION  14
 #define MPT3SAS_MINOR_VERSION  100
 #define MPT3SAS_BUILD_VERSION  0
 #define MPT3SAS_RELEASE_VERSION00
-- 
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 07/10] mpt3sas: Increased/Additional MSIX support for SAS35 devices.

2016-10-20 Thread Suganath Prabu S 
For SAS35 devices MSIX vectors are inceased to 128 from 96. To support this
Reply post host index register count is increased to 16. Also variable
msix96_vector is replaced with combined_reply_queue and variable
combined_reply_index_count is added to set different values for SAS3 and
SAS35 devices.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 14 +++---
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  8 +---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 11 +--
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 9ad7f7c..43cdc02 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1078,7 +1078,7 @@ _base_interrupt(int irq, void *bus_id)
 * new reply host index value in ReplyPostIndex Field and msix_index
 * value in MSIxIndex field.
 */
-   if (ioc->msix96_vector)
+   if (ioc->combined_reply_queue)
writel(reply_q->reply_post_host_index | ((msix_index  & 7) <<
MPI2_RPHI_MSIX_INDEX_SHIFT),
ioc->replyPostRegisterIndex[msix_index/8]);
@@ -2052,7 +2052,7 @@ mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc)
_base_free_irq(ioc);
_base_disable_msix(ioc);
 
-   if (ioc->msix96_vector) {
+   if (ioc->combined_reply_queue) {
kfree(ioc->replyPostRegisterIndex);
ioc->replyPostRegisterIndex = NULL;
}
@@ -2162,7 +2162,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
/* Use the Combined reply queue feature only for SAS3 C0 & higher
 * revision HBAs and also only when reply queue count is greater than 8
 */
-   if (ioc->msix96_vector && ioc->reply_queue_count > 8) {
+   if (ioc->combined_reply_queue && ioc->reply_queue_count > 8) {
/* Determine the Supplemental Reply Post Host Index Registers
 * Addresse. Supplemental Reply Post Host Index Registers
 * starts at offset MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET and
@@ -2170,7 +2170,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
 * MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET from previous one.
 */
ioc->replyPostRegisterIndex = kcalloc(
-MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT,
+ioc->combined_reply_index_count,
 sizeof(resource_size_t *), GFP_KERNEL);
if (!ioc->replyPostRegisterIndex) {
dfailprintk(ioc, printk(MPT3SAS_FMT
@@ -2180,14 +2180,14 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
goto out_fail;
}
 
-   for (i = 0; i < MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT; i++) {
+   for (i = 0; i < ioc->combined_reply_index_count; i++) {
ioc->replyPostRegisterIndex[i] = (resource_size_t *)
 ((u8 *)>chip->Doorbell +
 MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
 (i * MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET));
}
} else
-   ioc->msix96_vector = 0;
+   ioc->combined_reply_queue = 0;
 
if (ioc->is_warpdrive) {
ioc->reply_post_host_index[0] = (resource_size_t __iomem *)
@@ -5140,7 +5140,7 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER *ioc)
 
/* initialize reply post host index */
list_for_each_entry(reply_q, >reply_queue_list, list) {
-   if (ioc->msix96_vector)
+   if (ioc->combined_reply_queue)
writel((reply_q->msix_index & 7)<<
   MPI2_RPHI_MSIX_INDEX_SHIFT,
   ioc->replyPostRegisterIndex[reply_q->msix_index/8]);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 3d75c57..acb4106 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -300,8 +300,9 @@
  * There are twelve Supplemental Reply Post Host Index Registers
  * and each register is at offset 0x10 bytes from the previous one.
  */
-#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT 12
-#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET (0x10)
+#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT_G312
+#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT_G35   16
+#define MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET  (0x10)
 
 /* OEM Identifiers */
 #define MFG10_OEM_ID_INVALID   (0x)
@@ -1158,7 +1159,8 @@ struct MPT3SAS_ADAPTER {
u8  reply_queue_count;
struct list_head reply_queue_list;
 
-   u8

[PATCH 08/10] mpt3sas: set EEDP-escape-flags for SAS35 devices.

2016-10-20 Thread Suganath Prabu S 
An UNMAP command on a PI formatted device will leave the Logical Block
Application Tag and Logical Block Reference Tag as all F's (for those LBAs
that are unmapped). To avoid IO errors if those LBAs are subsequently read
before they are written with valid tag fields, the MPI SCSI IO requests
need to set the EEDPFlags element EEDP Escape Mode field, Bits [7:6]
appropriately. A value of 2 should be set to disable all PI checks if the
Logical Block Application Tag is 0x for PI types 1 and 2.  A value
of 3 should be set to disable all PI checks if the Logical Block
Application Tag is 0x and the Logical Block Reference Tag is
0x for PI type 3.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index a1c541d..c58f326 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3989,6 +3989,9 @@ _scsih_setup_eedp(struct MPT3SAS_ADAPTER *ioc, struct 
scsi_cmnd *scmd,
 
mpi_request_3v->EEDPBlockSize =
cpu_to_le16(scmd->device->sector_size);
+
+   if (ioc->is_gen35_ioc)
+   eedp_flags |= MPI25_SCSIIO_EEDPFLAGS_APPTAG_DISABLE_MODE;
mpi_request->EEDPFlags = cpu_to_le16(eedp_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 01/10] mpt3sas: Fix for improper info displayed in var log, while blocking or unblocking the device.

2016-10-20 Thread Suganath Prabu S 
Return value and Device_handle Arguments passed in correct order
 to match with its format string.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 209a969..282ca40 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2837,7 +2837,7 @@ _scsih_internal_device_block(struct scsi_device *sdev,
if (r == -EINVAL)
sdev_printk(KERN_WARNING, sdev,
"device_block failed with return(%d) for handle(0x%04x)\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);
 }
 
 /**
@@ -2867,20 +2867,20 @@ _scsih_internal_device_unblock(struct scsi_device *sdev,
sdev_printk(KERN_WARNING, sdev,
"device_unblock failed with return(%d) for handle(0x%04x) "
"performing a block followed by an unblock\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);
sas_device_priv_data->block = 1;
r = scsi_internal_device_block(sdev);
if (r)
sdev_printk(KERN_WARNING, sdev, "retried device_block "
"failed with return(%d) for handle(0x%04x)\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);
 
sas_device_priv_data->block = 0;
r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
if (r)
sdev_printk(KERN_WARNING, sdev, "retried device_unblock"
" failed with return(%d) for handle(0x%04x)\n",
-   sas_device_priv_data->sas_target->handle, r);
+   r, sas_device_priv_data->sas_target->handle);
}
 }
 
-- 
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 02/10] mpt3sas: Fix for incorrect numbers for MSIX vectors enabled when non RDPQ card is enumerated first.

2016-10-20 Thread Suganath Prabu S 
No. of MSIX vectors supported = min (Total no. of CPU cores,
MSIX vectors supported by card)

when RDPQ is disabled "max_msix_vectors" module parameter which was
declared as global was set to '8' and hence if there are more than one card
in system among which if RDPQ disabled card is enumerated first then only 8
MSIX vectors was getting enabled for all the cards(including RDPQ enabled
card,which can support more than 8 MSIX vectors).

Used local variable instead of global variable ,if RDPQ is disabled this
local variable is set to '8' else it is set to "max_msix_vectors" (by
default this is set to -1, whose value can be set by user during driver
load time).So now regardless of whether RDPQ disabled card is enumerated
first or RDPQ enabled card is enumerated first , MSIX vectors enabled
depends on the cards capability.

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index a1a5ceb..4ea81e1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1959,7 +1959,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
 {
struct msix_entry *entries, *a;
int r;
-   int i;
+   int i, local_max_msix_vectors;
u8 try_msix = 0;
 
if (msix_disable == -1 || msix_disable == 0)
@@ -1979,13 +1979,15 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
  ioc->cpu_count, max_msix_vectors);
 
if (!ioc->rdpq_array_enable && max_msix_vectors == -1)
-   max_msix_vectors = 8;
+   local_max_msix_vectors = 8;
+   else
+   local_max_msix_vectors = max_msix_vectors;
 
-   if (max_msix_vectors > 0) {
-   ioc->reply_queue_count = min_t(int, max_msix_vectors,
+   if (local_max_msix_vectors > 0) {
+   ioc->reply_queue_count = min_t(int, local_max_msix_vectors,
ioc->reply_queue_count);
ioc->msix_vector_count = ioc->reply_queue_count;
-   } else if (max_msix_vectors == 0)
+   } else if (local_max_msix_vectors == 0)
goto try_ioapic;
 
if (ioc->msix_vector_count < ioc->cpu_count)
-- 
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 04/10] mpt3sas: Removing unused macro "MPT_DEVICE_TLR_ON"

2016-10-20 Thread Suganath Prabu S 
Removing macro "MPT_DEVICE_TLR_ON" defined in header file as its unused

Signed-off-by: Chaitra P B 
Signed-off-by: Sathya Prakash 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 4221a4d..e923c91 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -375,7 +375,6 @@ struct MPT3SAS_TARGET {
  * per device private data
  */
 #define MPT_DEVICE_FLAGS_INIT  0x01
-#define MPT_DEVICE_TLR_ON  0x02
 
 #define MFG_PAGE10_HIDE_SSDS_MASK  (0x0003)
 #define MFG_PAGE10_HIDE_ALL_DISKS  (0x00)
-- 
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 00/10] mpt3sas driver Enhancements and

2016-10-20 Thread Suganath Prabu S 
Here is the change list:
Posting 10 patches for mpt3sas driver enhancements and few fixes.
  * Added Device ID's for SAS35 devices and updated MPI Header.
  * Support "EEDP Escape flag" for SAS35 devices.
  * fixed improper printk statement.
  * Regardless of whether RDPQ disabled card is enumerated
first or RDPQ enabled card is enumerated first, MSIX vectors
depends on the cards capability.
  * device_remove_in_progress bit check has been added in IOCTL path. If
bit is set, then IOCTL will be failed printing failure message.
  * Started using the Atomic Request Descriptors for
SAS35 devices.
  * For SAS35 devices MSIX vectors are inceased to 128 from 96.
  * Fixing Endianness issue.
  * Updated driver version to 14.100.00.00

Suganath Prabu S (10):
  mpt3sas: Fix for improper info displayed in var log,  while
blocking or  unblocking the device.
  mpt3sas: Fix for incorrect numbers for MSIX vectors  enabled when 
non RDPQ card is enumerated first.
  mpt3sas: Implement device_remove_in_progress check in  IOCTL path
  mpt3sas: Removing unused macro "MPT_DEVICE_TLR_ON"
  mpt3sas: Bump driver version as "14.100.00.00"
  mpt3sas: Added Device ID's for SAS35 devices and  updated MPI
header.
  mpt3sas: Increased/Additional MSIX support for SAS35  devices.
  mpt3sas: set EEDP-escape-flags for SAS35 devices.
  mpt3sas: Use the new MPI 2.6 32-bit Atomic Request  Descriptors
for SAS35 devices.
  mpt3sas: Fix for Endianness issue.

 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h |   7 ++
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 186 ++-
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  37 +++---
 drivers/scsi/mpt3sas/mpt3sas_config.c|   2 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  69 +---
 drivers/scsi/mpt3sas/mpt3sas_ctl.h   |   1 +
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 113 +++
 drivers/scsi/mpt3sas/mpt3sas_transport.c |   8 +-
 8 files changed, 333 insertions(+), 90 deletions(-)

Thanks,
Suganath prabu S 
-- 
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 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 James Bottomley 
On Thu, 2016-10-20 at 11:15 +0200, Greg KH wrote:
> On Thu, Oct 20, 2016 at 02:05:04AM -0700, Sumit Saxena wrote:
> > CC: sta...@vger.kernel.org
> > Signed-off-by: Sumit Saxena 
> > Reviewed-by: Hannes Reinecke 
> > Reviewed-by: Tomas Henzl 
> > ---
> >  drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> I know I reject patches without any changelog text in them, hopefully
> the scsi maintainers also do...

It depends: for complex patches needing detailed explanations, yes. 
 However, this is a four line change for which the subject seems
adequately descriptive, so this particular one seems fine.

James


--
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] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1

2016-10-20 Thread Rameshwar Prasad Sahu 
This patch enables NCQ support for APM X-Gene SATA controller
hardware v1.1 that was broken with hardware v1.0.

Signed-off-by: Rameshwar Prasad Sahu 
---
 drivers/ata/ahci_xgene.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 73b19b2..8b88be9 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -87,6 +87,7 @@

 enum xgene_ahci_version {
XGENE_AHCI_V1 = 1,
+   XGENE_AHCI_V1_1,
XGENE_AHCI_V2,
 };

@@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
 #ifdef CONFIG_ACPI
 static const struct acpi_device_id xgene_ahci_acpi_match[] = {
{ "APMC0D0D", XGENE_AHCI_V1},
+   { "APMC0D67", XGENE_AHCI_V1_1},
{ "APMC0D32", XGENE_AHCI_V2},
{},
 };
@@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);

 static const struct of_device_id xgene_ahci_of_match[] = {
{.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
+   {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
{.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
{},
 };
@@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
struct resource *res;
const struct of_device_id *of_devid;
enum xgene_ahci_version version = XGENE_AHCI_V1;
-   const struct ata_port_info *ppi[] = { _ahci_v1_port_info,
- _ahci_v2_port_info };
+   const struct ata_port_info *ppi;
int rc;

hpriv = ahci_platform_get_resources(pdev);
@@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(>dev, "%s: Error reading device 
info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
-   } else if (info->valid & ACPI_VALID_CID) {
-   version = XGENE_AHCI_V2;
}
}
}
@@ -858,18 +858,20 @@ skip_clk_phy:

switch (version) {
case XGENE_AHCI_V1:
+   ppi = _ahci_v1_port_info;
hpriv->flags = AHCI_HFLAG_NO_NCQ;
break;
case XGENE_AHCI_V2:
+   ppi = _ahci_v2_port_info;
hpriv->flags |= AHCI_HFLAG_YES_FBS;
hpriv->irq_handler = xgene_ahci_irq_intr;
break;
default:
+   ppi = _ahci_v1_port_info;
break;
}

-   rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
-_platform_sht);
+   rc = ahci_platform_init_host(pdev, hpriv, ppi, _platform_sht);
if (rc)
goto disable_resources;

--
1.7.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: `rmmod mpt3sas` leads to backtraces 'fs/sysfs/group.c:237 sysfs_remove_group+0xa0/0xb0'

2016-10-20 Thread ojab // 
Hi,

ses module was not built/loaded in my tests (ENCLOSURE_SERVICES was
not set in the kernel config), so it's not the case.
Also Oracle bug is private, so I can't tell if it's really related.

//wbr ojab


On Thu, Oct 20, 2016 at 10:08 AM, Chaitra Basappa
 wrote:
> Hi Ojab,
>
> I would like to clarify that issue is not because of the below mentioned
> patch/ mpt3sas driver, its due to some SES module patch which we have seen
> earlier without merged/combined (mpt2sas & mpt3sas) driver too.
>
>
>
> So before unloading driver try unloading ses module(`rmmod ses`) and then
> unload driver, driver unloads successfully.
>
>
>
> This confirms issue is not because of driver , so ses module patches needs
> to be checked to identify the patch causing this issue.
>
>
>
> Also we have reported below Bug with oracle , which we observed on
> OEL6.8_UEK(4.1.12-37.4.1_x86_64)
>
> https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=15521
>
>
>
> Thanks,
>
> Chaitra
>
>
>
>
>
> From: mpt-fusionlinux@broadcom.com
> [mailto:mpt-fusionlinux@broadcom.com] On Behalf Of Laurence Oberman
> Sent: Tuesday, October 18, 2016 4:42 AM
> To: ojab; Johannes Thumshirn
> Cc: mpt-fusionlinux@broadcom.com; linux-scsi@vger.kernel.org
> Subject: RE: `rmmod mpt3sas` leads to backtraces 'fs/sysfs/group.c:237
> sysfs_remove_group+0xa0/0xb0'
>
>
>
>
>
>
>
>
>
>
>
> Sent on the new Sprint Network from my Samsung Galaxy S®4
>
>
>
>  Original message 
> From: ojab 
> Date: 10/17/2016 17:11 (GMT-05:00)
> To: Johannes Thumshirn 
> Cc: mpt-fusionlinux@broadcom.com, linux-scsi@vger.kernel.org
> Subject: Re: `rmmod mpt3sas` leads to backtraces 'fs/sysfs/group.c:237
> sysfs_remove_group+0xa0/0xb0'
>
> On 2016/10/17 14:42, Johannes Thumshirn wrote:
>> On Sun, Oct 16, 2016 at 02:33:28PM +, ojab wrote:
>>
>> Hi Ojab,
>>
>> Do you have a known good kernel? If yes can you do a git bisect to see
>> which
>> commit introduces this?
>>
>> Thanks,
>> Johannes
>>
>
> The issue is reproducible from the start, i. e. from commit
>
> c84b06a48c4d8ac8270624453132f3fa1a4a0f9d mpt3sas: Single driver module
> which supports both SAS 2.0 & SAS 3.0 HBAs
>
> in which support for my HBA was added.
> Before that the same issue can be reproduced using mpt2sas module in
> kernels >= 4.1.
>
> Unfortunately earlier kernels fail to boot on my HW, so I can't
> investigate further.
>
> //wbr ojab
>
> I have one of these in my lab. I will investigate and try reproduce and
> track it down as soon as I get a chance.
>
>
>
> Thanks
>
>
--
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

Device or HBA level QD throttling creates randomness in sequetial workload

2016-10-20 Thread Kashyap Desai 
[ Apologize, if you find more than one instance of my email.
Web based email client has some issue, so now trying git send mail.]

Hi,

I am doing some performance tuning in MR driver to understand how sdev queue 
depth and hba queue depth play role in IO submission from above layer.
I have 24 JBOD connected to MR 12GB controller and I can see performance for 4K 
Sequential work load as below.

HBA QD for MR controller is 4065 and Per device QD is set to 32

queue depth from  256 reports 300K IOPS 
queue depth from  128 reports 330K IOPS
queue depth from  64 reports 360K IOPS 
queue depth from  32 reports 510K IOPS

In MR driver I added debug print and confirm that more IO come to driver as 
random IO whenever I have  queue depth more than 32.

I have debug using scsi logging level and blktrace as well. Below is snippet of 
logs using scsi logging level.  In summary, if SML do flow control of IO due to 
Device QD or HBA QD, IO coming to LLD is more random pattern.

I see IO coming to driver is not sequential.

[79546.912041] sd 18:2:21:0: [sdy] tag#854 CDB: Write(10) 2a 00 00 03 c0 3b 00 
00 01 00
[79546.912049] sd 18:2:21:0: [sdy] tag#855 CDB: Write(10) 2a 00 00 03 c0 3c 00 
00 01 00
[79546.912053] sd 18:2:21:0: [sdy] tag#886 CDB: Write(10) 2a 00 00 03 c0 5b 00 
00 01 00 

 After LBA "00 03 c0 3c" next command is with LBA "00 03 c0 5b". 
Two Sequence are overlapped due to sdev QD throttling.

[79546.912056] sd 18:2:21:0: [sdy] tag#887 CDB: Write(10) 2a 00 00 03 c0 5c 00 
00 01 00
[79546.912250] sd 18:2:21:0: [sdy] tag#856 CDB: Write(10) 2a 00 00 03 c0 3d 00 
00 01 00
[79546.912257] sd 18:2:21:0: [sdy] tag#888 CDB: Write(10) 2a 00 00 03 c0 5d 00 
00 01 00
[79546.912259] sd 18:2:21:0: [sdy] tag#857 CDB: Write(10) 2a 00 00 03 c0 3e 00 
00 01 00
[79546.912268] sd 18:2:21:0: [sdy] tag#858 CDB: Write(10) 2a 00 00 03 c0 3f 00 
00 01 00

 If scsi_request_fn() breaks due to unavailability of device queue (due to 
below check), will there be any side defect as I observe ?
if (!scsi_dev_queue_ready(q, sdev))
 break;

If I reduce HBA QD and make sure IO from above layer is throttled due to HBA 
QD, there is a same impact.
MR driver use host wide shared tag map.

Can someone help me if this can be tunable in LLD providing additional settings 
or it is expected behavior ? Problem I am facing is, I am not able to figure 
out optimal device queue depth for different configuration and work load.

Thanks, Kashyap

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

Device or HBA level QD throttling creates randomness in sequetial workload

2016-10-20 Thread Kashyap Desai 
[ Apologize, if you find more than one instance of my email.
Web based email client has some issue, so now trying git send mail.]

Hi,

I am doing some performance tuning in MR driver to understand how sdev queue 
depth and hba queue depth play role in IO submission from above layer.
I have 24 JBOD connected to MR 12GB controller and I can see performance for 4K 
Sequential work load as below.

HBA QD for MR controller is 4065 and Per device QD is set to 32

queue depth from  256 reports 300K IOPS 
queue depth from  128 reports 330K IOPS
queue depth from  64 reports 360K IOPS 
queue depth from  32 reports 510K IOPS

In MR driver I added debug print and confirm that more IO come to driver as 
random IO whenever I have  queue depth more than 32.

I have debug using scsi logging level and blktrace as well. Below is snippet of 
logs using scsi logging level.  In summary, if SML do flow control of IO due to 
Device QD or HBA QD, IO coming to LLD is more random pattern.

I see IO coming to driver is not sequential.

[79546.912041] sd 18:2:21:0: [sdy] tag#854 CDB: Write(10) 2a 00 00 03 c0 3b 00 
00 01 00
[79546.912049] sd 18:2:21:0: [sdy] tag#855 CDB: Write(10) 2a 00 00 03 c0 3c 00 
00 01 00
[79546.912053] sd 18:2:21:0: [sdy] tag#886 CDB: Write(10) 2a 00 00 03 c0 5b 00 
00 01 00 

 After LBA "00 03 c0 3c" next command is with LBA "00 03 c0 5b". 
Two Sequence are overlapped due to sdev QD throttling.

[79546.912056] sd 18:2:21:0: [sdy] tag#887 CDB: Write(10) 2a 00 00 03 c0 5c 00 
00 01 00
[79546.912250] sd 18:2:21:0: [sdy] tag#856 CDB: Write(10) 2a 00 00 03 c0 3d 00 
00 01 00
[79546.912257] sd 18:2:21:0: [sdy] tag#888 CDB: Write(10) 2a 00 00 03 c0 5d 00 
00 01 00
[79546.912259] sd 18:2:21:0: [sdy] tag#857 CDB: Write(10) 2a 00 00 03 c0 3e 00 
00 01 00
[79546.912268] sd 18:2:21:0: [sdy] tag#858 CDB: Write(10) 2a 00 00 03 c0 3f 00 
00 01 00

 If scsi_request_fn() breaks due to unavailability of device queue (due to 
below check), will there be any side defect as I observe ?
if (!scsi_dev_queue_ready(q, sdev))
 break;

If I reduce HBA QD and make sure IO from above layer is throttled due to HBA 
QD, there is a same impact.
MR driver use host wide shared tag map.

Can someone help me if this can be tunable in LLD providing additional settings 
or it is expected behavior ? Problem I am facing is, I am not able to figure 
out optimal device queue depth for different configuration and work load.

Thanks, Kashyap

--
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: [RFC 6/6] qedi: Add support for data path.

2016-10-20 Thread Rangankar, Manish 


On 19/10/16 3:54 PM, "Hannes Reinecke"  wrote:

>On 10/19/2016 07:01 AM, manish.rangan...@cavium.com wrote:
>> From: Manish Rangankar 
>> 
>> This patch adds support for data path and TMF handling.
>> 
>> Signed-off-by: Nilesh Javali 
>> Signed-off-by: Adheer Chandravanshi 
>> Signed-off-by: Chad Dupuis 
>> Signed-off-by: Saurav Kashyap 
>> Signed-off-by: Arun Easi 
>> Signed-off-by: Manish Rangankar 
>> ---
>>  drivers/scsi/qedi/qedi_fw.c| 1282
>>
>>  drivers/scsi/qedi/qedi_gbl.h   |6 +
>>  drivers/scsi/qedi/qedi_iscsi.c |6 +
>>  drivers/scsi/qedi/qedi_main.c  |4 +
>>  4 files changed, 1298 insertions(+)
>> 
>> diff --git a/drivers/scsi/qedi/qedi_fw.c b/drivers/scsi/qedi/qedi_fw.c
>> index a820785..af1e14d 100644
>> --- a/drivers/scsi/qedi/qedi_fw.c
>> +++ b/drivers/scsi/qedi/qedi_fw.c
>> @@ -147,6 +147,114 @@ static void qedi_process_text_resp(struct
>>qedi_ctx *qedi,
>>  spin_unlock(>back_lock);
>>  }

--snipped--
>> +void qedi_trace_io(struct qedi_ctx *qedi, struct iscsi_task *task,
>> +   u16 tid, int8_t direction)
>> +{
>> +struct qedi_io_log *io_log;
>> +struct iscsi_conn *conn = task->conn;
>> +struct qedi_conn *qedi_conn = conn->dd_data;
>> +struct scsi_cmnd *sc_cmd = task->sc;
>> +unsigned long flags;
>> +u8 op;
>> +
>> +spin_lock_irqsave(>io_trace_lock, flags);
>> +
>> +io_log = >io_trace_buf[qedi->io_trace_idx];
>> +io_log->direction = direction;
>> +io_log->task_id = tid;
>> +io_log->cid = qedi_conn->iscsi_conn_id;
>> +io_log->lun = sc_cmd->device->lun;
>> +io_log->op = sc_cmd->cmnd[0];
>> +op = sc_cmd->cmnd[0];
>> +
>> +if (op == READ_10 || op == WRITE_10) {
>> +io_log->lba[0] = sc_cmd->cmnd[2];
>> +io_log->lba[1] = sc_cmd->cmnd[3];
>> +io_log->lba[2] = sc_cmd->cmnd[4];
>> +io_log->lba[3] = sc_cmd->cmnd[5];
>> +} else {
>> +io_log->lba[0] = 0;
>> +io_log->lba[1] = 0;
>> +io_log->lba[2] = 0;
>> +io_log->lba[3] = 0;
>> +}
>Only for READ_10 and WRITE_10? What about the other read or write
>commands?

We will add support for other scsi commands in the next revision.

>
>> +io_log->bufflen = scsi_bufflen(sc_cmd);
>> +io_log->sg_count = scsi_sg_count(sc_cmd);
>> +io_log->fast_sgs = qedi->fast_sgls;
>> +io_log->cached_sgs = qedi->cached_sgls;
>> +io_log->slow_sgs = qedi->slow_sgls;
>> +io_log->cached_sge = qedi->use_cached_sge;
>> +io_log->slow_sge = qedi->use_slow_sge;
>> +io_log->fast_sge = qedi->use_fast_sge;
>> +io_log->result = sc_cmd->result;
>> +io_log->jiffies = jiffies;
>> +io_log->blk_req_cpu = smp_processor_id();
>> +
>> +if (direction == QEDI_IO_TRACE_REQ) {
>> +/* For requests we only care about the submission CPU */
>> +io_log->req_cpu = smp_processor_id() % qedi->num_queues;
>> +io_log->intr_cpu = 0;
>> +io_log->blk_rsp_cpu = 0;
>> +} else if (direction == QEDI_IO_TRACE_RSP) {
>> +io_log->req_cpu = smp_processor_id() % qedi->num_queues;
>> +io_log->intr_cpu = qedi->intr_cpu;
>> +io_log->blk_rsp_cpu = smp_processor_id();
>> +}
>> +
>> +qedi->io_trace_idx++;
>> +if (qedi->io_trace_idx == QEDI_IO_TRACE_SIZE)
>> +qedi->io_trace_idx = 0;
>> +
>> +qedi->use_cached_sge = false;
>> +qedi->use_slow_sge = false;
>> +qedi->use_fast_sge = false;
>> +
>> +spin_unlock_irqrestore(>io_trace_lock, flags);
>> +}
>> +
>> +int qedi_iscsi_send_ioreq(struct iscsi_task *task)
>> +{
>> +struct iscsi_conn *conn = task->conn;
>> +struct iscsi_session *session = conn->session;
>> +struct Scsi_Host *shost =
>>iscsi_session_to_shost(session->cls_session);
>> +struct qedi_ctx *qedi = iscsi_host_priv(shost);
>> +struct qedi_conn *qedi_conn = conn->dd_data;
>> +struct qedi_cmd *cmd = task->dd_data;
>> +struct scsi_cmnd *sc = task->sc;
>> +struct iscsi_task_context *fw_task_ctx;
>> +struct iscsi_cached_sge_ctx *cached_sge;
>> +struct iscsi_phys_sgl_ctx *phys_sgl;
>> +struct iscsi_virt_sgl_ctx *virt_sgl;
>> +struct ystorm_iscsi_task_st_ctx *yst_cxt;
>> +struct mstorm_iscsi_task_st_ctx *mst_cxt;
>> +struct iscsi_sgl *sgl_struct;
>> +struct iscsi_sge *single_sge;
>> +struct iscsi_scsi_req *hdr = (struct iscsi_scsi_req *)task->hdr;
>> +struct iscsi_sge *bd = cmd->io_tbl.sge_tbl;
>> +enum iscsi_task_type task_type;
>> +struct iscsi_cmd_hdr *fw_cmd;
>> +u32 scsi_lun[2];
>> +u16 cq_idx = smp_processor_id() % qedi->num_queues;
>> +s16 ptu_invalidate = 0;
>> +s16 tid = 0;
>> +u8 num_fast_sgs;
>> +
>> +tid =

Re: [RFC 5/6] qedi: Add support for iSCSI session management.

2016-10-20 Thread Rangankar, Manish 


On 19/10/16 1:33 PM, "Hannes Reinecke"  wrote:

>On 10/19/2016 07:01 AM, manish.rangan...@cavium.com wrote:
>> From: Manish Rangankar 
>> 
>> This patch adds support for iscsi_transport LLD Login,
>> Logout, NOP-IN/NOP-OUT, Async, Reject PDU processing
>> and Firmware async event handling support.
>> 
>> Signed-off-by: Nilesh Javali 
>> Signed-off-by: Adheer Chandravanshi 
>> Signed-off-by: Chad Dupuis 
>> Signed-off-by: Saurav Kashyap 
>> Signed-off-by: Arun Easi 
>> Signed-off-by: Manish Rangankar 
>> ---
>>  drivers/scsi/qedi/qedi_fw.c| 1123 
>>  drivers/scsi/qedi/qedi_gbl.h   |   67 ++
>>  drivers/scsi/qedi/qedi_iscsi.c | 1604
>>
>>  drivers/scsi/qedi/qedi_iscsi.h |  228 ++
>>  drivers/scsi/qedi/qedi_main.c  |  164 
>>  5 files changed, 3186 insertions(+)
>>  create mode 100644 drivers/scsi/qedi/qedi_fw.c
>>  create mode 100644 drivers/scsi/qedi/qedi_gbl.h
>>  create mode 100644 drivers/scsi/qedi/qedi_iscsi.c
>>  create mode 100644 drivers/scsi/qedi/qedi_iscsi.h
>> 

--snipped--
>>
>> +static void qedi_process_async_mesg(struct qedi_ctx *qedi,
>> +union iscsi_cqe *cqe,
>> +struct iscsi_task *task,
>> +struct qedi_conn *qedi_conn,
>> +u16 que_idx)
>> +{
>> +struct iscsi_conn *conn = qedi_conn->cls_conn->dd_data;
>> +struct iscsi_session *session = conn->session;
>> +struct iscsi_async_msg_hdr *cqe_async_msg;
>> +struct iscsi_async *resp_hdr;
>> +u32 scsi_lun[2];
>> +u32 pdu_len, num_bdqs;
>> +char bdq_data[QEDI_BDQ_BUF_SIZE];
>> +unsigned long flags;
>> +
>> +spin_lock_bh(>back_lock);
>> +
>> +cqe_async_msg = >cqe_common.iscsi_hdr.async_msg;
>> +pdu_len = cqe_async_msg->hdr_second_dword &
>> +ISCSI_ASYNC_MSG_HDR_DATA_SEG_LEN_MASK;
>> +num_bdqs = pdu_len / QEDI_BDQ_BUF_SIZE;
>> +
>> +if (cqe->cqe_common.cqe_type == ISCSI_CQE_TYPE_UNSOLICITED) {
>> +spin_lock_irqsave(>hba_lock, flags);
>> +qedi_unsol_pdu_adjust_bdq(qedi, >cqe_unsolicited,
>> +  pdu_len, num_bdqs, bdq_data);
>> +spin_unlock_irqrestore(>hba_lock, flags);
>> +}
>> +
>> +resp_hdr = (struct iscsi_async *)_conn->gen_pdu.resp_hdr;
>> +memset(resp_hdr, 0, sizeof(struct iscsi_hdr));
>> +resp_hdr->opcode = cqe_async_msg->opcode;
>> +resp_hdr->flags = 0x80;
>> +
>> +scsi_lun[0] = cpu_to_be32(cqe_async_msg->lun.lo);
>> +scsi_lun[1] = cpu_to_be32(cqe_async_msg->lun.hi);
>I _think_ we have a SCSI LUN structure ...

Will do.

--snipped--
>> +void qedi_process_iscsi_error(struct qedi_endpoint *ep, struct
>>async_data *data)
>> +{
>> +struct qedi_conn *qedi_conn;
>> +struct qedi_ctx *qedi;
>> +char warn_notice[] = "iscsi_warning";
>> +char error_notice[] = "iscsi_error";
>> +char *message;
>> +int need_recovery = 0;
>> +u32 err_mask = 0;
>> +char msg[64];
>> +
>> +if (!ep)
>> +return;
>> +
>> +qedi_conn = ep->conn;
>> +if (!qedi_conn)
>> +return;
>> +
>> +qedi = ep->qedi;
>> +
>> +QEDI_ERR(>dbg_ctx, "async event iscsi error:0x%x\n",
>> + data->error_code);
>> +
>> +if (err_mask) {
>> +need_recovery = 0;
>> +message = warn_notice;
>> +} else {
>> +need_recovery = 1;
>> +message = error_notice;
>> +}
>> +
>> +switch (data->error_code) {
>> +case ISCSI_STATUS_NONE:
>> +strcpy(msg, "tcp_error none");
>> +break;
>> +case ISCSI_CONN_ERROR_TASK_CID_MISMATCH:
>> +strcpy(msg, "task cid mismatch");
>> +break;
>> +case ISCSI_CONN_ERROR_TASK_NOT_VALID:
>> +strcpy(msg, "invalid task");
>> +break;
>> +case ISCSI_CONN_ERROR_RQ_RING_IS_FULL:
>> +strcpy(msg, "rq ring full");
>> +break;
>> +case ISCSI_CONN_ERROR_CMDQ_RING_IS_FULL:
>> +strcpy(msg, "cmdq ring full");
>> +break;
>> +case ISCSI_CONN_ERROR_HQE_CACHING_FAILED:
>> +strcpy(msg, "sge caching failed");
>> +break;
>> +case ISCSI_CONN_ERROR_HEADER_DIGEST_ERROR:
>> +strcpy(msg, "hdr digest error");
>> +break;
>> +case ISCSI_CONN_ERROR_LOCAL_COMPLETION_ERROR:
>> +strcpy(msg, "local cmpl error");
>> +break;
>> +case ISCSI_CONN_ERROR_DATA_OVERRUN:
>> +strcpy(msg, "invalid task");
>> +break;
>> +case ISCSI_CONN_ERROR_OUT_OF_SGES_ERROR:
>> +strcpy(msg, "out of sge error");
>> +break;
>> +case

Re: [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 Greg KH 
On Thu, Oct 20, 2016 at 02:05:04AM -0700, Sumit Saxena wrote:
> CC: sta...@vger.kernel.org
> Signed-off-by: Sumit Saxena 
> Reviewed-by: Hannes Reinecke 
> Reviewed-by: Tomas Henzl 
> ---
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

I know I reject patches without any changelog text in them, hopefully
the scsi maintainers also do...
--
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: [RFC 5/6] qedi: Add support for iSCSI session management.

2016-10-20 Thread Rangankar, Manish 


On 19/10/16 6:58 PM, "Johannes Thumshirn"  wrote:

>On Wed, Oct 19, 2016 at 01:01:12AM -0400, manish.rangan...@cavium.com
>wrote:
>> From: Manish Rangankar 
>> 
>> This patch adds support for iscsi_transport LLD Login,
>> Logout, NOP-IN/NOP-OUT, Async, Reject PDU processing
>> and Firmware async event handling support.
>> 
>> Signed-off-by: Nilesh Javali 
>> Signed-off-by: Adheer Chandravanshi 
>> Signed-off-by: Chad Dupuis 
>> Signed-off-by: Saurav Kashyap 
>> Signed-off-by: Arun Easi 
>> Signed-off-by: Manish Rangankar 
>> ---
>
>[...]
>
>> +void qedi_iscsi_unmap_sg_list(struct qedi_cmd *cmd)
>> +{
>> +struct scsi_cmnd *sc = cmd->scsi_cmd;
>> +
>> +if (cmd->io_tbl.sge_valid && sc) {
>> +scsi_dma_unmap(sc);
>> +cmd->io_tbl.sge_valid = 0;
>> +}
>> +}
>
>Maybe set sge_valid to 0 and then call scsi_dma_unmap(). I don't know if
>it's
>really racy but it looks like it is.
>
>[...]
>
>> +static void qedi_process_text_resp(struct qedi_ctx *qedi,
>> +   union iscsi_cqe *cqe,
>> +   struct iscsi_task *task,
>> +   struct qedi_conn *qedi_conn)
>> +{
>> +struct iscsi_conn *conn = qedi_conn->cls_conn->dd_data;
>> +struct iscsi_session *session = conn->session;
>> +struct iscsi_task_context *task_ctx;
>> +struct iscsi_text_rsp *resp_hdr_ptr;
>> +struct iscsi_text_response_hdr *cqe_text_response;
>> +struct qedi_cmd *cmd;
>> +int pld_len;
>> +u32 *tmp;
>> +
>> +cmd = (struct qedi_cmd *)task->dd_data;
>> +task_ctx = (struct iscsi_task_context
>>*)qedi_get_task_mem(>tasks,
>> +  cmd->task_id);
>
>No need to cast here, qedi_get_task_mem() returns void *.
>
>[...]
>
>> +cqe_login_response = >cqe_common.iscsi_hdr.login_response;
>> +task_ctx = (struct iscsi_task_context
>>*)qedi_get_task_mem(>tasks,
>> +  cmd->task_id);
>
>Same here.
>
>[...]
>
>> +}
>> +
>> +pbl = (struct scsi_bd *)qedi->bdq_pbl;
>> +pbl += (qedi->bdq_prod_idx % qedi->rq_num_entries);
>> +pbl->address.hi =
>> +  cpu_to_le32((u32)(((u64)(qedi->bdq[idx].buf_dma)) >> 32));
>> +pbl->address.lo =
>> +cpu_to_le32(((u32)(((u64)(qedi->bdq[idx].buf_dma)) &
>> +0x)));
>
>Is this LISP or C?
>
>> +QEDI_INFO(>dbg_ctx, QEDI_LOG_CONN,
>> +  "pbl [0x%p] pbl->address hi [0x%llx] lo [0x%llx] idx [%d]\n",
>> +  pbl, pbl->address.hi, pbl->address.lo, idx);
>> +pbl->opaque.hi = cpu_to_le32((u32)(((u64)0) >> 32));
>
>Isn't this plain pbl->opaque.hi = 0; ?
>
>> +pbl->opaque.lo = cpu_to_le32(((u32)(((u64)idx) & 0x)));
>> +
>
>[...]
>
>> +switch (comp_type) {
>> +case ISCSI_CQE_TYPE_SOLICITED:
>> +case ISCSI_CQE_TYPE_SOLICITED_WITH_SENSE:
>> +fw_task_ctx =
>> +  (struct iscsi_task_context *)qedi_get_task_mem(>tasks,
>> +  cqe->cqe_solicited.itid);
>
>Again, no cast needed.
>
>[...]
>
>> +writel(*(u32 *), qedi_conn->ep->p_doorbell);
>> +/* Make sure fw idx is coherent */
>> +wmb();
>> +mmiowb();
>
>Isn't either wmb() or mmiowb() enough?
>
>[..]
>
>> +
>> +fw_task_ctx =
>> + (struct iscsi_task_context *)qedi_get_task_mem(>tasks,
>>tid);
>
>Cast again.
>
>[...]
>
>> +fw_task_ctx =
>> + (struct iscsi_task_context *)qedi_get_task_mem(>tasks,
>>tid);
>
>^^
>
>[...]
>
>> +fw_task_ctx =
>> +(struct iscsi_task_context *)qedi_get_task_mem(>tasks, tid);
>
>
>[...]
>
>> +fw_task_ctx =
>> +  (struct iscsi_task_context *)qedi_get_task_mem(>tasks,
>>tid);
>> +
>
>[...]
>
>> +
>> +qedi = (struct qedi_ctx *)iscsi_host_priv(shost);
>
>Same goes for iscsi_host_priv();
>
>[...]
>
>> +ret = wait_event_interruptible_timeout(qedi_ep->ofld_wait,
>> +   ((qedi_ep->state ==
>> +EP_STATE_OFLDCONN_FAILED) ||
>> +(qedi_ep->state ==
>> +EP_STATE_OFLDCONN_COMPL)),
>> +msecs_to_jiffies(timeout_ms));
>
>Maybe:
>#define QEDI_OLDCON_STATE(q) ((q)->state == EP_STATE_OFLDCONN_FAILED || \
>   (q)->state == EP_STATE_OFLDCONN_COMPL)
>
>ret = wait_event_interruptible_timeout(qedi_ep->ofld_wait,
>   QEDI_OLDCON_STATE(qedi_ep),
>   msec_to_jiffies(timeout_ms));
>
>But that could be just me hating linewraps.
>
>[...]

We will address

Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-20 Thread Arnd Bergmann 
On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
> -   sema_init(_info->sync_request_sem,
> -   PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS);
> +   mutex_init(_info->sync_request_mutex);
> 

Looking at this again, I see that PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS
is '3', so this is in fact a counting semaphore rather than a mutex,
and the conversion is changing the behavior.

The patch can't go in unless you either show that it should be
a normal mutex rather than a counting semaphore, or you find a way
to keep the behavior the same.

Arnd
--
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/2] scsi: smartpqi: Replace semaphore lun_reset_sem with mutex

2016-10-20 Thread Arnd Bergmann 
On Thursday, October 20, 2016 2:24:02 PM CEST Binoy Jayan wrote:
> Semaphores are going away in the future, so replace the semaphore
> lun_reset_sem with the a mutex lock.
> 
> Signed-off-by: Binoy Jayan 
> 

Reviewed-by: Arnd Bergmann 
--
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/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-20 Thread Arnd Bergmann 
On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
> Semaphores are going away in the future, so replace the semaphore
> sync_request_sem with the a mutex lock. timeout_msecs is not used
> for the lock sync_request_sem, so remove the timed locking too.
> 
> Signed-off-by: Binoy Jayan 

The patch looks correct to me, but I think if you remove the support
for handling timeouts, you should update the prototype of
pqi_submit_raid_request_synchronous to no longer pass the timeout
argument in the first place.

Arnd
--
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 
Signed-off-by: Sumit Saxena 
---
 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_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index

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

2016-10-20 Thread Sumit Saxena 
Signed-off-by: Sumit Saxena 
---
 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 
Signed-off-by: Sumit Saxena 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Tomas Henzl 
---
 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 
Signed-off-by: Sumit Saxena 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Tomas Henzl 
---
 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 
Signed-off-by: Shivasharan Srikanteshwara 

---
 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 
Reviewed-by: Hannes Reinecke 
---
 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 
-M: Sumit Saxena 
-M: Uday Lingala 
-L: megaraidlinux@avagotech.com
+M: Kashyap Desai 
+M: Sumit Saxena 
+M: Shivasharan S 
+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 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Tomas Henzl 
---
 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: [RFC 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

2016-10-20 Thread Rangankar, Manish 
Thanks Hannes for the review, please see my comments below,

On 19/10/16 1:15 PM, "Hannes Reinecke"  wrote:

>On 10/19/2016 07:01 AM, manish.rangan...@cavium.com wrote:
>> From: Manish Rangankar 
>> 
>> The QLogic FastLinQ Driver for iSCSI (qedi) is the iSCSI specific module
>> for 41000 Series Converged Network Adapters by QLogic.
>> 
>> This patch consists of following changes:
>>   - MAINTAINERS Makefile and Kconfig changes for qedi,
>>   - PCI driver registration,
>>   - iSCSI host level initialization,
>>   - Debugfs and log level infrastructure.
>> 
>> Signed-off-by: Nilesh Javali 
>> Signed-off-by: Adheer Chandravanshi 
>> Signed-off-by: Chad Dupuis 
>> Signed-off-by: Saurav Kashyap 
>> Signed-off-by: Arun Easi 
>> Signed-off-by: Manish Rangankar 
>> ---
>>  MAINTAINERS |6 +
>>  drivers/net/ethernet/qlogic/Kconfig |   12 -
>>  drivers/scsi/Kconfig|1 +
>>  drivers/scsi/Makefile   |1 +
>>  drivers/scsi/qedi/Kconfig   |   10 +
>>  drivers/scsi/qedi/Makefile  |5 +
>>  drivers/scsi/qedi/qedi.h|  286 +++
>>  drivers/scsi/qedi/qedi_dbg.c|  143 
>>  drivers/scsi/qedi/qedi_dbg.h|  144 
>>  drivers/scsi/qedi/qedi_debugfs.c|  244 ++
>>  drivers/scsi/qedi/qedi_hsi.h|   52 ++
>>  drivers/scsi/qedi/qedi_main.c   | 1550
>>+++
>>  drivers/scsi/qedi/qedi_sysfs.c  |   52 ++
>>  drivers/scsi/qedi/qedi_version.h|   14 +
>>  14 files changed, 2508 insertions(+), 12 deletions(-)
>>  create mode 100644 drivers/scsi/qedi/Kconfig
>>  create mode 100644 drivers/scsi/qedi/Makefile
>>  create mode 100644 drivers/scsi/qedi/qedi.h
>>  create mode 100644 drivers/scsi/qedi/qedi_dbg.c
>>  create mode 100644 drivers/scsi/qedi/qedi_dbg.h
>>  create mode 100644 drivers/scsi/qedi/qedi_debugfs.c
>>  create mode 100644 drivers/scsi/qedi/qedi_hsi.h
>>  create mode 100644 drivers/scsi/qedi/qedi_main.c
>>  create mode 100644 drivers/scsi/qedi/qedi_sysfs.c
>>  create mode 100644 drivers/scsi/qedi/qedi_version.h
>> 
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5e925a2..906d05f 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9909,6 +9909,12 @@ F:drivers/net/ethernet/qlogic/qed/
>>  F:  include/linux/qed/
>>  F:  drivers/net/ethernet/qlogic/qede/
>>  
>> +QLOGIC QL41xxx ISCSI DRIVER
>> +M:  qlogic-storage-upstr...@cavium.com
>> +L:  linux-scsi@vger.kernel.org
>> +S:  Supported
>> +F:  drivers/scsi/qedi/
>> +
>>  QNX4 FILESYSTEM
>>  M:  Anders Larsen 
>>  W:  http://www.alarsen.net/linux/qnx4fs/
>> diff --git a/drivers/net/ethernet/qlogic/Kconfig
>>b/drivers/net/ethernet/qlogic/Kconfig
>> index bad4fae..28b4366 100644
>> --- a/drivers/net/ethernet/qlogic/Kconfig
>> +++ b/drivers/net/ethernet/qlogic/Kconfig
>> @@ -121,16 +121,4 @@ config INFINIBAND_QEDR
>>  config QED_ISCSI
>>  bool
>>  
>> -config QEDI
>> -tristate "QLogic QED 25/40/100Gb iSCSI driver"
>> -depends on QED
>> -select QED_LL2
>> -select QED_ISCSI
>> -default n
>> ----help---
>> -  This provides a temporary node that allows the compilation
>> -  and logical testing of the hardware offload iSCSI support
>> -  for QLogic QED. This would be replaced by the 'real' option
>> -  once the QEDI driver is added [+relocated].
>> -
>>  endif # NET_VENDOR_QLOGIC
>Huh? You just introduce this one in patch 1/6.
>Please fold them together so that this can be omitted.

Yes, we will remove this in the next revision.

-- snipped --


>> @@ -0,0 +1,52 @@
>> +/*
>> + * QLogic iSCSI Offload Driver
>> + * Copyright (c) 2016 Cavium Inc.
>> + *
>> + * This software is available under the terms of the GNU General
>>Public License
>> + * (GPL) Version 2, available from the file COPYING in the main
>>directory of
>> + * this source tree.
>> + */
>> +#ifndef __QEDI_HSI__
>> +#define __QEDI_HSI__
>> +//
>> +/* Add include to common target */
>> +//
>> +#include 
>> +
>Please use kernel-doc style for comments

Will do.

--snipped--
>> +static void qedi_int_fp(struct qedi_ctx *qedi)
>> +{
>> +struct qedi_fastpath *fp;
>> +int id;
>> +
>> +memset((void *)qedi->fp_array, 0, MIN_NUM_CPUS_MSIX(qedi) *
>> +   sizeof(*qedi->fp_array));
>> +memset((void *)qedi->sb_array, 0, MIN_NUM_CPUS_MSIX(qedi) *
>> +   sizeof(*qedi->sb_array));
>> +
>> +for (id = 0; id < MIN_NUM_CPUS_MSIX(qedi); id++) {
>> +fp = >fp_array[id];
>> +fp->sb_info = >sb_array[id];
>> +fp->sb_id = id;
>> +fp->qedi = qedi;
>> +snprintf(fp->name, sizeof(fp->name), "%s-fp-%d",
>> + "qedi", id);
>> +
>> +/*

Re: [RFC 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

2016-10-20 Thread Rangankar, Manish 
Thanks Johannes for the review, please see comments below,


On 19/10/16 3:32 PM, "Johannes Thumshirn"  wrote:

>On Wed, Oct 19, 2016 at 01:01:10AM -0400, manish.rangan...@cavium.com
>wrote:
>> From: Manish Rangankar 
>> 
>> The QLogic FastLinQ Driver for iSCSI (qedi) is the iSCSI specific module
>> for 41000 Series Converged Network Adapters by QLogic.
>> 
>> This patch consists of following changes:
>>   - MAINTAINERS Makefile and Kconfig changes for qedi,
>>   - PCI driver registration,
>>   - iSCSI host level initialization,
>>   - Debugfs and log level infrastructure.
>> 
>> Signed-off-by: Nilesh Javali 
>> Signed-off-by: Adheer Chandravanshi 
>> Signed-off-by: Chad Dupuis 
>> Signed-off-by: Saurav Kashyap 
>> Signed-off-by: Arun Easi 
>> Signed-off-by: Manish Rangankar 
>> ---
>
>[...]
>
>> +static inline void *qedi_get_task_mem(struct qed_iscsi_tid *info, u32
>>tid)
>> +{
>> +return (void *)(info->blocks[tid / info->num_tids_per_block] +
>> +(tid % info->num_tids_per_block) * info->size);
>> +}
>
>Unnecessary cast here.

Noted

>
>
>[...]
>
>> +void
>> +qedi_dbg_err(struct qedi_dbg_ctx *qedi, const char *func, u32 line,
>> + const char *fmt, ...)
>> +{
>> +va_list va;
>> +struct va_format vaf;
>> +char nfunc[32];
>> +
>> +memset(nfunc, 0, sizeof(nfunc));
>> +memcpy(nfunc, func, sizeof(nfunc) - 1);
>> +
>> +va_start(va, fmt);
>> +
>> +vaf.fmt = fmt;
>> +vaf.va = 
>> +
>> +if (likely(qedi) && likely(qedi->pdev))
>> +pr_crit("[%s]:[%s:%d]:%d: %pV", dev_name(>pdev->dev),
>> +nfunc, line, qedi->host_no, );
>> +else
>> +pr_crit("[:00:00.0]:[%s:%d]: %pV", nfunc, line, );
>
>pr_crit, seriously?

We will change it to pr_err.

>
>[...]
>
>> +static void qedi_int_fp(struct qedi_ctx *qedi)
>> +{
>> +struct qedi_fastpath *fp;
>> +int id;
>> +
>> +memset((void *)qedi->fp_array, 0, MIN_NUM_CPUS_MSIX(qedi) *
>> +   sizeof(*qedi->fp_array));
>> +memset((void *)qedi->sb_array, 0, MIN_NUM_CPUS_MSIX(qedi) *
>> +   sizeof(*qedi->sb_array));
>
>I don't think the cast is necessary here.

Noted


>
>[...]
>
>> +static int qedi_setup_cid_que(struct qedi_ctx *qedi)
>> +{
>> +int i;
>> +
>> +qedi->cid_que.cid_que_base = kmalloc((qedi->max_active_conns *
>> +  sizeof(u32)), GFP_KERNEL);
>> +if (!qedi->cid_que.cid_que_base)
>> +return -ENOMEM;
>> +
>> +qedi->cid_que.conn_cid_tbl = kmalloc((qedi->max_active_conns *
>> +  sizeof(struct qedi_conn *)),
>> + GFP_KERNEL);
>
>Please use kmalloc_array() here.

Will do.

>
>[...]
>
>> +/* MSI-X fastpath handler code */
>> +static irqreturn_t qedi_msix_handler(int irq, void *dev_id)
>> +{
>> +struct qedi_fastpath *fp = dev_id;
>> +struct qedi_ctx *qedi = fp->qedi;
>> +bool wake_io_thread = true;
>> +
>> +qed_sb_ack(fp->sb_info, IGU_INT_DISABLE, 0);
>> +
>> +process_again:
>> +wake_io_thread = qedi_process_completions(fp);
>> +if (wake_io_thread) {
>> +QEDI_INFO(>dbg_ctx, QEDI_LOG_DISC,
>> +  "process already running\n");
>> +}
>> +
>> +if (qedi_fp_has_work(fp) == 0)
>> +qed_sb_update_sb_idx(fp->sb_info);
>> +
>> +/* Check for more work */
>> +rmb();
>> +
>> +if (qedi_fp_has_work(fp) == 0)
>> +qed_sb_ack(fp->sb_info, IGU_INT_ENABLE, 1);
>> +else
>> +goto process_again;
>> +
>> +return IRQ_HANDLED;
>> +}
>
>You might want to consider workqueues here.

We will revisit this code.

>
>[...]
>
>> +static int qedi_alloc_itt(struct qedi_ctx *qedi)
>> +{
>> +qedi->itt_map = kzalloc((sizeof(struct qedi_itt_map) *
>> +MAX_ISCSI_TASK_ENTRIES), GFP_KERNEL);
>
>that screams for kcalloc()
>
>> +if (!qedi->itt_map) {
>> +QEDI_ERR(>dbg_ctx,
>> + "Unable to allocate itt map array memory\n");
>> +return -ENOMEM;
>> +}
>> +return 0;
>> +}
>> +
>> +static void qedi_free_itt(struct qedi_ctx *qedi)
>> +{
>> +kfree(qedi->itt_map);
>> +}
>> +
>> +static struct qed_ll2_cb_ops qedi_ll2_cb_ops = {
>> +.rx_cb = qedi_ll2_rx,
>> +.tx_cb = NULL,
>> +};
>> +
>> +static int qedi_percpu_io_thread(void *arg)
>> +{
>> +struct qedi_percpu_s *p = arg;
>> +struct qedi_work *work, *tmp;
>> +unsigned long flags;
>> +LIST_HEAD(work_list);
>> +
>> +set_user_nice(current, -20);
>> +
>> +while (!kthread_should_stop()) {
>> +spin_lock_irqsave(>p_work_lock, flags);
>> +while (!list_empty(>work_list)) {
>> +list_splice_init(>work_list, _list);
>> +

[PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-20 Thread Binoy Jayan 
Semaphores are going away in the future, so replace the semaphore
sync_request_sem with the a mutex lock. timeout_msecs is not used
for the lock sync_request_sem, so remove the timed locking too.

Signed-off-by: Binoy Jayan 
---
 drivers/scsi/smartpqi/smartpqi.h  |  4 +++-
 drivers/scsi/smartpqi/smartpqi_init.c | 31 ++-
 2 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/drivers/scsi/smartpqi/smartpqi.h b/drivers/scsi/smartpqi/smartpqi.h
index 07b6444..b4559b1 100644
--- a/drivers/scsi/smartpqi/smartpqi.h
+++ b/drivers/scsi/smartpqi/smartpqi.h
@@ -19,6 +19,8 @@
 #if !defined(_SMARTPQI_H)
 #define _SMARTPQI_H
 
+#include 
+
 #pragma pack(1)
 
 #define PQI_DEVICE_SIGNATURE   "PQI DREG"
@@ -961,7 +963,7 @@ struct pqi_ctrl_info {
unsigned intnum_heartbeats_requested;
struct timer_list heartbeat_timer;
 
-   struct semaphore sync_request_sem;
+   struct mutex sync_request_mutex;
struct semaphore lun_reset_sem;
 };
 
diff --git a/drivers/scsi/smartpqi/smartpqi_init.c 
b/drivers/scsi/smartpqi/smartpqi_init.c
index a535b26..4974f7e 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -3444,29 +3444,11 @@ static int pqi_submit_raid_request_synchronous(struct 
pqi_ctrl_info *ctrl_info,
unsigned long msecs_blocked;
size_t iu_length;
 
-   /*
-* Note that specifying PQI_SYNC_FLAGS_INTERRUPTABLE and a timeout value
-* are mutually exclusive.
-*/
-
-   if (flags & PQI_SYNC_FLAGS_INTERRUPTABLE) {
-   if (down_interruptible(_info->sync_request_sem))
+   if (flags & PQI_SYNC_FLAGS_INTERRUPTABLE)
+   if (mutex_lock_interruptible(_info->sync_request_mutex))
return -ERESTARTSYS;
-   } else {
-   if (timeout_msecs == NO_TIMEOUT) {
-   down(_info->sync_request_sem);
-   } else {
-   start_jiffies = jiffies;
-   if (down_timeout(_info->sync_request_sem,
-   msecs_to_jiffies(timeout_msecs)))
-   return -ETIMEDOUT;
-   msecs_blocked =
-   jiffies_to_msecs(jiffies - start_jiffies);
-   if (msecs_blocked >= timeout_msecs)
-   return -ETIMEDOUT;
-   timeout_msecs -= msecs_blocked;
-   }
-   }
+   else
+   mutex_lock(_info->sync_request_mutex);
 
io_request = pqi_alloc_io_request(ctrl_info);
 
@@ -3508,7 +3490,7 @@ static int pqi_submit_raid_request_synchronous(struct 
pqi_ctrl_info *ctrl_info,
 
pqi_free_io_request(io_request);
 
-   up(_info->sync_request_sem);
+   mutex_unlock(_info->sync_request_mutex);
 
return rc;
 }
@@ -5540,8 +5522,7 @@ static struct pqi_ctrl_info *pqi_alloc_ctrl_info(int 
numa_node)
INIT_DELAYED_WORK(_info->rescan_work, pqi_rescan_worker);
INIT_DELAYED_WORK(_info->update_time_work, pqi_update_time_worker);
 
-   sema_init(_info->sync_request_sem,
-   PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS);
+   mutex_init(_info->sync_request_mutex);
sema_init(_info->lun_reset_sem, PQI_RESERVED_IO_SLOTS_LUN_RESET);
 
ctrl_info->ctrl_id = atomic_inc_return(_controller_count) - 1;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/2] scsi: smartpqi: Replace semaphore lun_reset_sem with mutex

2016-10-20 Thread Binoy Jayan 
Semaphores are going away in the future, so replace the semaphore
lun_reset_sem with the a mutex lock.

Signed-off-by: Binoy Jayan 
---
 drivers/scsi/smartpqi/smartpqi.h  | 2 +-
 drivers/scsi/smartpqi/smartpqi_init.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/smartpqi/smartpqi.h b/drivers/scsi/smartpqi/smartpqi.h
index b4559b1..3ecec27 100644
--- a/drivers/scsi/smartpqi/smartpqi.h
+++ b/drivers/scsi/smartpqi/smartpqi.h
@@ -964,7 +964,7 @@ struct pqi_ctrl_info {
struct timer_list heartbeat_timer;
 
struct mutex sync_request_mutex;
-   struct semaphore lun_reset_sem;
+   struct mutex lun_reset_mutex;
 };
 
 enum pqi_ctrl_mode {
diff --git a/drivers/scsi/smartpqi/smartpqi_init.c 
b/drivers/scsi/smartpqi/smartpqi_init.c
index 4974f7e..1e5df85 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -4601,7 +4601,7 @@ static int pqi_lun_reset(struct pqi_ctrl_info *ctrl_info,
DECLARE_COMPLETION_ONSTACK(wait);
struct pqi_task_management_request *request;
 
-   down(_info->lun_reset_sem);
+   mutex_lock(_info->lun_reset_mutex);
 
io_request = pqi_alloc_io_request(ctrl_info);
io_request->io_complete_callback = pqi_lun_reset_complete;
@@ -4627,7 +4627,7 @@ static int pqi_lun_reset(struct pqi_ctrl_info *ctrl_info,
rc = io_request->status;
 
pqi_free_io_request(io_request);
-   up(_info->lun_reset_sem);
+   mutex_unlock(_info->lun_reset_mutex);
 
return rc;
 }
@@ -5523,7 +5523,7 @@ static struct pqi_ctrl_info *pqi_alloc_ctrl_info(int 
numa_node)
INIT_DELAYED_WORK(_info->update_time_work, pqi_update_time_worker);
 
mutex_init(_info->sync_request_mutex);
-   sema_init(_info->lun_reset_sem, PQI_RESERVED_IO_SLOTS_LUN_RESET);
+   mutex_init(_info->lun_reset_mutex);
 
ctrl_info->ctrl_id = atomic_inc_return(_controller_count) - 1;
ctrl_info->max_msix_vectors = PQI_MAX_MSIX_VECTORS;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/2] smartpqi: Remove semaphores

2016-10-20 Thread Binoy Jayan 
Hi,

The following are a set of patches which removes semaphores from 
scsi/smartpqi. These are part of a bigger effort to eliminate all
semaphores from the linux kernel.

Thanks,
Binoy

Binoy Jayan (2):
  scsi: smartpqi: Replace semaphore sync_request_sem with mutex
  scsi: smartpqi: Replace semaphore lun_reset_sem with mutex

 drivers/scsi/smartpqi/smartpqi.h  |  6 --
 drivers/scsi/smartpqi/smartpqi_init.c | 37 +--
 2 files changed, 13 insertions(+), 30 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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] Fix: scsi: megaraid: reduce the scope of pending-list lock to avoid double lock

2016-10-20 Thread Kashyap Desai 
> -Original Message-
> From: i...@itu.dk [mailto:i...@itu.dk]
> Sent: Monday, October 17, 2016 1:00 PM
> To: Jiri Kosina
> Cc: Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley;
Martin K.
> Petersen; megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org;
Iago
> Abal
> Subject: [PATCH] Fix: scsi: megaraid: reduce the scope of pending-list
lock to
> avoid double lock
>
> From: Iago Abal 
>
> The EBA code analyzer (https://github.com/models-team/eba) reported the
> following double lock:
>
> 1. In function `megaraid_reset_handler' at 2571;
> 2. take `>pend_list_lock' for the first time at 2602:
>
>// FIRST
>spin_lock_irqsave(PENDING_LIST_LOCK(adapter), flags);
>
> 3. enter the `list_for_each_entry_safe' loop at 2603;
> 4. call `megaraid_mbox_mm_done' at 2616;
> 5. call `megaraid_mbox_runpendq' at 3782;
> 6. take `>pend_list_lock' for the second time at 1892:
>
>// SECOND: DOUBLE LOCK !!!
>spin_lock_irqsave(PENDING_LIST_LOCK(adapter), flags);
>
> From my shallow understanding of the code (so please review carefully),
I think
> that it is not necessary to hold `PENDING_LIST_LOCK(adapter)' while
executing
> the body of the `list_for_each_entry_safe' loop. I assume this because
both
> `megaraid_mbox_mm_done' and `megaraid_dealloc_scb' are called from
> several places where, as far as I can tell, this lock is not hold. In
fact, as reported
> by EBA, at some point `megaraid_mbox_mm_done' will acquire this lock
again.
>
> Fixes: c005fb4fb2d2 ("[SCSI] megaraid_{mm,mbox}: fix a bug in reset
handler")
> Signed-off-by: Iago Abal 
> ---
>  drivers/scsi/megaraid/megaraid_mbox.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/scsi/megaraid/megaraid_mbox.c
> b/drivers/scsi/megaraid/megaraid_mbox.c
> index f0987f2..7f11898 100644
> --- a/drivers/scsi/megaraid/megaraid_mbox.c
> +++ b/drivers/scsi/megaraid/megaraid_mbox.c
> @@ -2603,6 +2603,7 @@ static DEF_SCSI_QCMD(megaraid_queue_command)
>   list_for_each_entry_safe(scb, tmp, >pend_list, list) {
>   list_del_init(>list);  // from pending list
>
> + spin_unlock_irqrestore(PENDING_LIST_LOCK(adapter), flags);
>   if (scb->sno >= MBOX_MAX_SCSI_CMDS) {
>   con_log(CL_ANN, (KERN_WARNING
>   "megaraid: IOCTL packet with %d[%d:%d] being
> reset\n", @@ -2630,6 +2631,7 @@ static
> DEF_SCSI_QCMD(megaraid_queue_command)
>
>   megaraid_dealloc_scb(adapter, scb);
>   }
> + spin_lock_irqsave(PENDING_LIST_LOCK(adapter), flags);
>   }
>   spin_unlock_irqrestore(PENDING_LIST_LOCK(adapter), flags);

Looks correct, but please note that MEGARAID_MAILBOX and MEGARAID_MM is
not supported by LSI/ Broadcom.   We will revert back to you shortly if we
can safely remove those two modules.

.

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

Device or HBA QD throttling creates holes in Sequential work load

2016-10-20 Thread Kashyap Desai 
[ Apologize, if this thread is reached to you multiple time ]

Hi,

I am doing some performance tuning in MR driver to understand how sdev
queue depth and hba queue depth play role in IO submission from above
layer. I have 24 JBOD connected to MR 12GB controller and I can see
performance for 4K Sequential work load as below.

HBA QD for MR controller is 4065 and Per device QD is set to 32

queue depth from  256 reports 300K IOPS
queue depth from  128 reports 330K IOPS
queue depth from  64 reports 360K IOPS
queue depth from  32 reports 510K IOPS

In MR driver I added debug print and confirm that more IO come to
driver as random IO whenever I have  queue depth more than 32.

I have debug using scsi logging level and blktrace as well. Below is
snippet of logs using scsi logging level.  In summary, if SML do flow
control of IO due to Device QD or HBA QD,  IO coming to LLD is more
random pattern.

I see IO coming to driver is not sequential.


[79546.912041] sd 18:2:21:0: [sdy] tag#854 CDB: Write(10) 2a 00 00 03
c0 3b 00 00 01 00
[79546.912049] sd 18:2:21:0: [sdy] tag#855 CDB: Write(10) 2a 00 00 03
c0 3c 00 00 01 00
 [79546.912053] sd 18:2:21:0: [sdy] tag#886 CDB: Write(10) 2a 00 00 03
c0 5b 00 00 01 00 <- After 3c it jumps to 5b. Sequence are overlapped.
Due to sdev QD throttling.
[79546.912056] sd 18:2:21:0: [sdy] tag#887 CDB: Write(10) 2a 00 00 03
c0 5c 00 00 01 00
[79546.912250] sd 18:2:21:0: [sdy] tag#856 CDB: Write(10) 2a 00 00 03
c0 3d 00 00 01 00
[79546.912257] sd 18:2:21:0: [sdy] tag#888 CDB: Write(10) 2a 00 00 03
c0 5d 00 00 01 00
[79546.912259] sd 18:2:21:0: [sdy] tag#857 CDB: Write(10) 2a 00 00 03
c0 3e 00 00 01 00
[79546.912268] sd 18:2:21:0: [sdy] tag#858 CDB: Write(10) 2a 00 00 03
c0 3f 00 00 01 00

 If scsi_request_fn() breaks due to unavailability of device queue
(due to below check), will there be any side defect as I observe ?

if (!scsi_dev_queue_ready(q, sdev))

 break;

If I reduce HBA QD and make sure IO from above layer is throttled due
to HBA QD, there is a same impact.  MR driver use host wide shared tag
map.

Can someone help me if this can be tunable in LLD providing additional
settings or it is expected behavior ? Problem I am facing is, I am not
able to figure out optimal device queue depth for different
configuration and work load.

Thanks, Kashyap
--
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: [RFC 1/6] qed: Add support for hardware offloaded iSCSI.

2016-10-20 Thread Johannes Thumshirn 
Hi Arun,

On Wed, Oct 19, 2016 at 05:14:59PM -0700, Arun Easi wrote:
> Thanks Johannes for the review, please see my response below.
> 

[...]

> > 
> > Why not introduce a small helper like:
> > static inline bool qed_is_iscsi_personality()
> > {
> > return IS_ENABLED(CONFIG_QEDI) && p_hwfn->hw_info.personality ==
> > QED_PCI_ISCSI;
> > }
> 
> I think I can remove the IS_ENABLED() check in places like this
> and have the check contained in header file. qed_iscsi_free()
> already is taken care, if I do the same fore qed_ooo*, I think
> the check would just be "p_hwfn->hw_info.personality ==
> QED_PCI_ISCSI", which would keep it consistent with the other
> areas where similar check is done for other protocols.

Sounds good.

> 

[...]

> > 
> > Is there any chance you could factor out above blocks into own functions so
> > you have
> > 
> > 
> > if (!GET_FIELD(p_ramrod->iscsi.flags,
> >ISCSI_CONN_OFFLOAD_PARAMS_TCP_ON_CHIP_1B)) {
> > qedi_do_stuff_off_chip();
> > else 
> > qedi_do_stuff_on_chip();
> > 
> 
> This function mostly fills data needed for the firmware interface.
> By having all data necessary for the command
> ISCSI_RAMROD_CMD_ID_OFFLOAD_CONN in this function it is easier to
> refer what is being fed to firmware. If you do not have strong
> objections, I would like to keep it this way.

No strong objections, I just don't think these lengthy blocks are readable,
but I don't want to do too much bikeshedding about it.

Thanks,
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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: Device or HBA QD throttling creates holes in Sequential work load

2016-10-20 Thread Kashyap Desai 
Reply to see if email reached to linux-scsi@vger.kernel.org.


On Thu, Oct 20, 2016 at 12:07 PM, Kashyap Desai
 wrote:
> Hi,
>
> I am doing some performance tuning in MR driver to understand how sdev queue
> depth and hba queue depth play role in IO submission from above layer.
>
>  I have 24 JBOD connected to MR 12GB controller and I can see performance
> for 4K Sequential work load as below.
>
>  HBA QD for MR controller is 4065 and Per device QD is set to 32
>
>
>
> queue depth from  256 reports 300K IOPS
>
> queue depth from  128 reports 330K IOPS
>
> queue depth from  64 reports 360K IOPS
>
> queue depth from  32 reports 510K IOPS
>
>
>
> In MR driver I added debug print and confirm that more IO come to driver as
> random IO whenever I have  queue depth more than 32.
>
> I have debug using scsi logging level and blktrace as well. Below is snippet
> of logs using scsi logging level.  In summary, if SML do flow control of IO
> due to Device QD or HBA QD,  IO coming to LLD is more random pattern.
>
>
>
> I see IO coming to driver is not sequential.
>
>
>
> [79546.912041] sd 18:2:21:0: [sdy] tag#854 CDB: Write(10) 2a 00 00 03 c0 3b
> 00 00 01 00 [79546.912049] sd 18:2:21:0: [sdy] tag#855 CDB: Write(10) 2a 00
> 00 03 c0 3c 00 00 01 00 [79546.912053] sd 18:2:21:0: [sdy] tag#886 CDB:
> Write(10) 2a 00 00 03 c0 5b 00 00 01 00 <- After 3c it jumps to 5b. Sequence
> are overlapped. Due to sdev QD throttling.
>
> [79546.912056] sd 18:2:21:0: [sdy] tag#887 CDB: Write(10) 2a 00 00 03 c0 5c
> 00 00 01 00 [79546.912250] sd 18:2:21:0: [sdy] tag#856 CDB: Write(10) 2a 00
> 00 03 c0 3d 00 00 01 00 [79546.912257] sd 18:2:21:0: [sdy] tag#888 CDB:
> Write(10) 2a 00 00 03 c0 5d 00 00 01 00 [79546.912259] sd 18:2:21:0: [sdy]
> tag#857 CDB: Write(10) 2a 00 00 03 c0 3e 00 00 01 00 [79546.912268] sd
> 18:2:21:0: [sdy] tag#858 CDB: Write(10) 2a 00 00 03 c0 3f 00 00 01 00
>
>
>
> If scsi_request_fn() breaks due to unavailability of device queue (due to
> below check), will there be any side defect as I observe ?
>
> if (!scsi_dev_queue_ready(q, sdev))
>
>  break;
>
>  If I reduce HBA QD and make sure IO from above layer is throttled due to
> HBA QD, there is a same impact.  MR driver use host wide shared tag map.
>
>  Can someone help me if this can be tunable in LLD providing additional
> settings or it is expected behavior ? Problem I am facing is, I am not able
> to figure out optimal device queue depth for different configuration and
> work load.
>
>  ` Kashyap
>
>
>
>
>
>
--
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