Re: [PATCHv2] mpt3sas: switch to pci_alloc_irq_vectors

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

[Christoph Hellwig]

On Tue, Dec 20, 2016 at 12:02:27AM -0200, Mauricio Faria de Oliveira wrote:
> When a SCSI command (e.g., read operation) is partially completed
> with good status and residual bytes (i.e., not all the bytes from
> the specified transfer length were transferred) the SCSI midlayer
> will update the request/bios with the completed bytes and requeue
> the request in order to complete the remainder/pending bytes.
> 
> However, when the device sector size is greater than the 512-byte
> default/kernel sector size, alignment restrictions and validation
> apply (both to the starting logical block address, and the number
> of logical blocks to transfer) -- values must be multiples of the
> device sector size, otherwise the kernel fails the request in the
> preparation stage (e.g., sd_setup_read_write_cmnd() at sd.c file):

How do you even get an unaligned residual count?  Except for SES
processor devices (which will only issue BLOCK_PC commands) this is
not allowed by SPC:

"The residual count shall be reported in bytes if the peripheral device
 type in the destination target descriptor is 03h (i.e., processor device),
 and in destination device blocks for all other device type codes."
--
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 -next] scsi: qedi: fix build, depends on UIO

[Christoph Hellwig]

On Tue, Dec 20, 2016 at 08:43:30AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix build of SCSI qedi driver. It uses uio interfaces so it
> should depend on UIO.
> 
> ERROR: "uio_unregister_device" [drivers/scsi/qedi/qedi.ko] undefined!
> ERROR: "uio_event_notify" [drivers/scsi/qedi/qedi.ko] undefined!
> ERROR: "__uio_register_device" [drivers/scsi/qedi/qedi.ko] undefined!

Why is it hiding an uio driver in an iscsi offload driver?
--
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 -next] scsi: qedi: fix build, depends on UIO

[Martin K. Petersen]

> "Randy" == Randy Dunlap  writes:

Randy> From: Randy Dunlap  Fix build of SCSI qedi
Randy> driver. It uses uio interfaces so it should depend on UIO.

Applied to 4.10/scsi-fixes.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] scsi: dpt_i2o: double free if adpt_i2o_online_hba() fails

[Martin K. Petersen]

> "Dan" == Dan Carpenter  writes:

Dan> There are two places where adpt_i2o_online_hba() is called.  Both
Dan> callers call adpt_i2o_delete_hba(pHba) if adpt_i2o_online_hba()
Dan> fails and since we also free it here that causes a double free bug.

Applied to 4.11/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] storvsc: Miscellaneous fixes and enhancements

[Martin K. Petersen]

> "kys" == kys   writes:

kys> From: K. Y. Srinivasan  Miscellaneous fixes and
kys> enhancements.

Applied to 4.11/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/11] lpfc: Update driver to version 11.2.0.4

[Martin K. Petersen]

> "James" == James Smart  writes:

James> This patch set updates the lpfc driver to revision 11.2.0.4

Applied to 4.11/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cciss: use designated initializers

[Martin K. Petersen]

> "Kees" == Kees Cook  writes:

Kees> Prepare to mark sensitive kernel structures for randomization by
Kees> making sure they're using designated initializers. These were
Kees> identified during allyesconfig builds of x86, arm, and arm64, with
Kees> most initializer fixes extracted from grsecurity.

Applied to 4.11/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hpsa: use designated initializers

[Martin K. Petersen]

> "Kees" == Kees Cook  writes:

Kees> Prepare to mark sensitive kernel structures for randomization by
Kees> making sure they're using designated initializers. These were
Kees> identified during allyesconfig builds of x86, arm, and arm64, with
Kees> most initializer fixes extracted from grsecurity.

Applied to 4.11/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] SRP transport, scsi-mq: Wait for .queue_rq() if necessary

[Martin K. Petersen]

> "Bart" == Bart Van Assche  writes:

Bart> It seems like patch 1/2 of this series is already present in
Bart> Linus' tree but patch 2/2 not yet? Can you queue this patch for
Bart> the next pull request that will be sent to Linus?

Applied to 4.10/scsi-fixes.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/11] lpfc: Correct oops on vport port resets

[Hannes Reinecke]

On 12/20/2016 05:51 PM, James Smart wrote:



On 12/20/2016 5:47 AM, Hannes Reinecke wrote:


Now that is what I call a dodgy interface.
Casting a 128-bit structure to a 64-bit structure, only to call a memset
on the 128-bit structure in lpfc_sli4_iocb2wqe() is positively evil.
Can't you clear up this mess by generally passing in a wqe128?

Cheers,

Hannes


Completely agree. Wanted to get this in now to avoid the issue, and the
better clean up done afterward as its a bit more involved.


If you promise to...

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

[Subhash Jadavani]

On 2016-12-19 10:38, Rob Herring wrote:

On Tue, Dec 13, 2016 at 2:16 PM, Subhash Jadavani
 wrote:

On 2016-12-13 12:04, Rob Herring wrote:


On Mon, Dec 12, 2016 at 04:54:20PM -0800, Subhash Jadavani wrote:


UFS device and link can be put in multiple different low power modes
hence
UFS driver supports multiple different low power modes. By default 
UFS
driver selects the default (optimal) low power mode (which gives 
moderate

power savings and have relatively less enter and exit latencies) but
we might have to tune this default power mode for different chipset
platforms to meet the low power requirements/goals. Hence this patch
adds option to change default UFS low power mode (level).

Reviewed-by: Yaniv Gardi 
Signed-off-by: Subhash Jadavani 
---
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  | 10 ++
 drivers/scsi/ufs/ufshcd-pltfrm.c   | 14 
 drivers/scsi/ufs/ufshcd.c  | 39
++
 drivers/scsi/ufs/ufshcd.h  |  4 +--
 4 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index a99ed55..c3836c5 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -41,6 +41,14 @@ Optional properties:
 -lanes-per-direction   : number of lanes available per direction -
either 1 or 2.
  Note that it is assume same number of 
lanes is

used both
  directions at once. If not specified, 
default

is 2 lanes per direction.
+- rpm-level: UFS Runtime power management level. 
Following

PM levels are supported:
+ 0 - Both UFS device and Link in active 
state

(Highest power consumption)
+ 1 - UFS device in active state but Link in
Hibern8 state
+ 2 - UFS device in Sleep state but Link in
active state
+ 3 - UFS device in Sleep state and Link in
hibern8 state (default PM level)
+ 4 - UFS device in Power-down state and 
Link in

Hibern8 state
+ 5 - UFS device in Power-down state and 
Link in

OFF state (Lowest power consumption)
+- spm-level: UFS System power management level. Allowed 
PM

levels are same as rpm-level.



This looks like you are putting policy for Linux into DT.

What I would expect to see here is disabling of states that don't 
work

due to some h/w limitation. Otherwise, it is a user decision for what
modes to go into. Also, I think link and device states should be
separate.



Yes, generally default level (3) is good enough (and recommended) for 
all
platforms and most likely user is only expected to change this if they 
see
issues (most H/W) on their platform or they want even more aggressive 
power
state (level-4 or level-5) and ready to take the performance hit 
associated

with resume latencies.


What latencies can be tolerated is going to depend on the application
and could vary while running, so putting in DT doesn't make sense. I
would break down settings like this:

broken h/w -> DT
user tuning/config -> sysfs
sensible defaults -> driver


Make sense.
we already have #2 and #3 in place, will rework this patch so we have a 
way to specify what is broken in h/w.




Also, I think it is better to keep Link and device states tied, one 
reason

is that we can't keep device in sleep/active state when Link is in OFF
state.


The driver can tie the states to together if needed. Just document
what's broken in DT and let the driver make decisions.


Yes, agreed.  will rework this patch so we have a way to specify what is 
broken in h/w and separate the device and link states (something like 
broken-hibern8, broken-sleep etc.)

Thanks for the suggestions.



Rob


--
The Qualcomm Innovation Center, Inc. is a member of 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] set a base index for libsas based ata devices

[James Bottomley]

On Tue, 2016-12-20 at 10:15 -0800, Peter Chang wrote:
> we discovered this when futzing w/ the queue depth parameter for ata
> disks behind the pm8006 controller. setting depth == 1 should disable
> ncq, but the sysfs part silently fails and we continue sending the
> fpdma command variants. no one else probably cares about the 
> disabling ncq path, but we do like to test.

I'd actually disagree with this assertion; it's why tagging (what you
mean by ncq) and queue depth are separate.  Queue depth represents the
number of outstanding commands we sent on the wire; however, it often
excludes things like sense probes and error handling commands, so
tagged depth==1 is a different operating environment from untagged. 
 Some transports actually have no untagged variant nowadays, so it's
physically impossible to disable tagging.

James

> anyway, adding both the ide and scsi lists because i'm not quite sure
> there's a separate libsas list and a single commit seems better for
> this.



--
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] set a base index for libsas based ata devices

[Peter Chang]

we discovered this when futzing w/ the queue depth parameter for ata
disks behind the pm8006 controller. setting depth == 1 should disable
ncq, but the sysfs part silently fails and we continue sending the
fpdma command variants. no one else probably cares about the disabling
ncq path, but we do like to test.

anyway, adding both the ide and scsi lists because i'm not quite sure
there's a separate libsas list and a single commit seems better for
this.

\p
From 6bdfcb35a074d9c58c180f8c512706faf7d6c7cb Mon Sep 17 00:00:00 2001
From: peter chang 
Date: Tue, 20 Dec 2016 09:48:45 -0800
Subject: [PATCH] set a base index for libsas based ata devices

libsas hosts allow multiple links, but when the controller
supports SATA devices control is handed to libata. this means
that an attached scsi device will be setup properly, but device
management requests and sysfs futzing don't get routed correctly
because the device lookup fails.

Tested:
- pre-patch:
jkgg70:~# ls -d /sys/block/sd*
/sys/block/sda
jkgg70:~# modprobe pm80xx
jkgg70:~# cat /sys/block/sdb/device/queue_depth
31
jkgg70:~# echo 1 > /sys/block/sdb/device/queue_depth
jkgg70:~# cat /sys/block/sdb/device/queue_depth
31
- post-patch:
jkgg70:~# modprobe pm80xx
jkgg70:~# cat /sys/block/sdb/device/queue_depth
31
jkgg70:~# echo 1 > /sys/block/sdb/device/queue_depth
jkgg70:~# cat /sys/block/sdb/device/queue_depth
1

Signed-off-by: peter chang 
---
 drivers/ata/libata-scsi.c   | 33 -
 drivers/scsi/libsas/sas_scsi_host.c |  4 
 include/linux/libata.h  |  3 +++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 1f863e7..340f144 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1088,7 +1088,7 @@ static void ata_to_sense_error(unsigned id, u8 drv_stat, u8 drv_err, u8 *sk,
  *	passthrough command, so we use the following sense data:
  *	sk = RECOVERED ERROR
  *	asc,ascq = ATA PASS-THROUGH INFORMATION AVAILABLE
- *  
+ *
  *
  *	LOCKING:
  *	None.
@@ -3052,6 +3052,16 @@ static unsigned int atapi_xlat(struct ata_queued_cmd *qc)
 
 static struct ata_device *ata_find_dev(struct ata_port *ap, int devno)
 {
+	/* adjust if this port is behind a libsas host rather than a
+	 * direct libata host. warn and fail if somehow we got out of
+	 * sync and we've a negative device number.
+	 */
+	devno -= ap->link.sas_host_base;
+	if (unlikely(devno < 0)) {
+		WARN_ON(devno < 0);
+		return NULL;
+	}
+
 	if (!sata_pmp_attached(ap)) {
 		if (likely(devno < ata_link_max_devices(&ap->link)))
 			return &ap->link.device[devno];
@@ -4332,6 +4342,27 @@ int ata_scsi_queuecmd(struct Scsi_Host *shost, struct scsi_cmnd *cmd)
 }
 
 /**
+ *	ata_sas_set_link_base - set the libata link's 'base' because
+ *	libsas hosts have more ports / links.
+ *	@ap: ATA port to which the target is attached
+ *	@starget: SCSI target being attached
+ */
+void ata_sas_set_link_base(struct ata_port *ap, struct scsi_target *starget)
+{
+	unsigned int host_base;
+
+	if (!sata_pmp_attached(ap)) {
+		WARN_ON(starget->channel);
+		host_base = starget->id;
+	} else {
+		WARN_ON(starget->id);
+		host_base = starget->channel;
+	}
+	ap->link.sas_host_base = host_base;
+}
+EXPORT_SYMBOL_GPL(ata_sas_set_link_base);
+
+/**
  *	ata_scsi_simulate - simulate SCSI command on ATA device
  *	@dev: the target device
  *	@cmd: SCSI command being sent to device.
diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c
index 519dac4..d8300bc 100644
--- a/drivers/scsi/libsas/sas_scsi_host.c
+++ b/drivers/scsi/libsas/sas_scsi_host.c
@@ -859,6 +859,10 @@ int sas_target_alloc(struct scsi_target *starget)
 
 	kref_get(&found_dev->kref);
 	starget->hostdata = found_dev;
+
+	if (dev_is_sata(found_dev))
+		ata_sas_set_link_base(found_dev->sata_dev.ap, starget);
+
 	return 0;
 }
 
diff --git a/include/linux/libata.h b/include/linux/libata.h
index c170be5..323811f 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -791,6 +791,7 @@ struct ata_acpi_gtm {
 struct ata_link {
 	struct ata_port		*ap;
 	int			pmp;		/* port multiplier port # */
+	int			sas_host_base;	/* host relative id */
 
 	struct device		tdev;
 	unsigned int		active_tag;	/* active tag on this link */
@@ -1130,6 +1131,8 @@ extern int ata_sas_port_start(struct ata_port *ap);
 extern void ata_sas_port_stop(struct ata_port *ap);
 extern int ata_sas_slave_configure(struct scsi_device *, struct ata_port *);
 extern int ata_sas_queuecmd(struct scsi_cmnd *cmd, struct ata_port *ap);
+extern void ata_sas_set_link_base(struct ata_port *ap,
+  struct scsi_target *starget);
 extern int sata_scr_valid(struct ata_link *link);
 extern int sata_scr_read(struct ata_link *link, int reg, u32 *val);
 extern int sata_scr_write(struct ata_link *link, int reg, u32 val);
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH v2 09/11] lpfc: Correct oops on vport port resets

[James Smart]

On 12/20/2016 5:47 AM, Hannes Reinecke wrote:


Now that is what I call a dodgy interface.
Casting a 128-bit structure to a 64-bit structure, only to call a memset
on the 128-bit structure in lpfc_sli4_iocb2wqe() is positively evil.
Can't you clear up this mess by generally passing in a wqe128?

Cheers,

Hannes


Completely agree. Wanted to get this in now to avoid the issue, and the 
better clean up done afterward as its a bit more involved.


-- 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 -next] scsi: qedi: fix build, depends on UIO

[Randy Dunlap]

From: Randy Dunlap 

Fix build of SCSI qedi driver. It uses uio interfaces so it
should depend on UIO.

ERROR: "uio_unregister_device" [drivers/scsi/qedi/qedi.ko] undefined!
ERROR: "uio_event_notify" [drivers/scsi/qedi/qedi.ko] undefined!
ERROR: "__uio_register_device" [drivers/scsi/qedi/qedi.ko] undefined!

Signed-off-by: Randy Dunlap 
Cc: qlogic-storage-upstr...@cavium.com
---
 drivers/scsi/qedi/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20161220.orig/drivers/scsi/qedi/Kconfig
+++ linux-next-20161220/drivers/scsi/qedi/Kconfig
@@ -1,6 +1,6 @@
 config QEDI
tristate "QLogic QEDI 25/40/100Gb iSCSI Initiator Driver Support"
-   depends on PCI && SCSI
+   depends on PCI && SCSI && UIO
depends on QED
select SCSI_ISCSI_ATTRS
select QED_LL2
--
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 V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Thursday, December 15, 2016 10:10 AM
> To: Sasikumar PC; j...@kernel.org; h...@infradead.org
> Cc: linux-scsi@vger.kernel.org; Sathya Prakash Veerichetty;
> linux-ker...@vger.kernel.org; Christopher Owens; Kiran Kumar Kasturi
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
> based on the PCI Threshold Bandwidth
>
> On 14.12.2016 22:54, Sasikumar PC wrote:
>> Hi Tomas,
>>
>> Please see my response inline
>>
>> Thanks
>> sasi
>>
>> -Original Message-
>> From: Tomas Henzl [mailto:the...@redhat.com]
>> Sent: Friday, December 09, 2016 8:59 AM
>> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
>> Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
>> linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
>> kiran-kumar.kast...@broadcom.com
>> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast
>> path based on the PCI Threshold Bandwidth
>>
>> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>>> Large SEQ IO workload should sent as non fast path commands
>>>
>>> This patch is depending on patch 7
>>>
>>> Signed-off-by: Sasikumar Chandrasekaran 
>>> ---
>>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
>> +
>>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>> index 3e087ab..eb5be2b 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>>  #define MFI_1068_FW_HANDSHAKE_OFFSET   0x64
>>>  #define MFI_1068_FW_READY  0x
>>>
>>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>>> +
>>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>> atomic_t ldio_outstanding;
>>> atomic_t fw_reset_no_pci_access;
>>>
>>> +   atomic64_t bytes_wrote; /* used for raid1 fast path enable or
>> disable */
>>> +   atomic_t r1_write_fp_capable;
>> Is a an atomic variable needed for a just boolean variable?
>> Sasi - As we need to synchronize timer thread and IO issue threads,
>> With atomic, at any point of time the value will be definitive.
>> With boolean, it depends, the value could be in transit while one
>> thread is reading and other is writing.
> This explanation is I think not good enough, as a write of a char value is
> atomic on all architectures. If you need synchronisation you probably need a
> spinlock.
> Tomash
>
> boolean may not be a char in all architectures/implementations. It could be
> implementation specific isn't it ?

On which arch? 

> Spin_Lock is heavier as the check is in IO path.

Lightest form of atomic variable for isolated write and read is probably a char 
- so why can't
you use that plain basic type to store a boolean value?

> We need it to be consistent
> non-transient value, not an exact synchronization.

Could you be please more specific - what exactly is the transient value other 
than true or false ?

> There could be more values that we may set this variable to, to make
> different decisions and value can be set in more places in future.
> Atomic will help it keep consistent and extensible.

And then you'll rename the variable and use bit operations or may use
different state values and for that a char or int which is atomic per se
are the best option.

You've tested the whole series so you try to not change anything in the series,
I'm trying to understand.
You wrote earlier here that an explicit synchronisation is not needed,
that means, that there is no race condition possible and the
code is just a bit less then ideal. ok, fine, i'll this pass.

>
> sasi
>
>>> +
>>> +
>>> struct megasas_instance_template *instancet;
>>> struct tasklet_struct isr_tasklet;
>>> struct work_struct work_init;
>>> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>>> long reset_flags;
>>> struct mutex reset_mutex;
>>> struct timer_list sriov_heartbeat_timer;
>>> +   struct timer_list r1_fp_hold_timer;
>>> char skip_heartbeat_timer_del;
>>> u8 requestorId;
>>> char PlasmaFW111;
>>> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>>> bool is_ventura;
>>> bool msix_combined;
>>> u16 max_raid_mapsize;
>>> +   u64 pci_threshold_bandwidth; /* used to control the fp writes */
>>>  };
>>>  struct MR_LD_V

RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Sasikumar PC]

-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Tuesday, December 20, 2016 9:20 AM
To: Sasikumar PC; j...@kernel.org; h...@infradead.org
Cc: linux-scsi@vger.kernel.org; Sathya Prakash Veerichetty;
linux-ker...@vger.kernel.org; Christopher Owens; Kiran Kumar Kasturi
Subject: Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
SAS3.5 Generic Megaraid Controllers

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Sasikumar PC [mailto:sasikumar...@broadcom.com]
> Sent: Wednesday, December 14, 2016 4:49 PM
> To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org'
> Cc: 'linux-scsi@vger.kernel.org'; Sathya Prakash Veerichetty;
> 'linux-ker...@vger.kernel.org'; Christopher Owens; Kiran Kumar Kasturi
> Subject: RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 7:55 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap
> to have different
>> sizes for different number of supported VDs.
>>
>> This patch is depending on patch 5
>>
>> Signed-off-by: Sasikumar Chandrasekaran 
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303
> 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240
> ++
>>  5 files changed, 699 insertions(+), 135 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megaraid_sas.h
>> index f4d6a94..3e087ab 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>  #define MR_MAX_MSIX_REG_ARRAY   16
>>  #define MR_RDPQ_MODE_OFFSET 0X0080
>> +
>> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT   16
>> +#define MR_MAX_RAID_MAP_SIZE_MASK   0x1FF
>> +#define MR_MIN_MAP_SIZE 0x1
>> +/* 64k */
>> +
>>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100
>>
>>  /*
>> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>>  bool fw_sync_cache_support;
>>  bool is_ventura;
>>  bool msix_combined;
>> +u16 max_raid_mapsize;
>>  };
>>  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 c52f7be..3f06b57 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance
> *instance)
>>  static void megasas_update_ext_vd_details(struct megasas_instance
> *instance)
>>  {
>>  struct fusion_context *fusion;
>> -u32 old_map_sz;
>> -u32 new_map_sz;
>> +u32 ventura_map_sz = 0;
>>
>>  fusion = instance->ctrl_context;
>>  /* For MFI based controllers return dummy success */
>> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct
> megasas_instance *instance)
>>  instance->supportmax256vd ? "Extended VD(240 VD)firmware"
> :
>>  "Legacy(64 VD) firmware");
>>
>> -old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->fw_supported_vd_count - 1));
>> -new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
>> -fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->drv_supported_vd_count - 1));
>> -
>> -fusion->max_map_sz = max(old_map_sz, new_map_sz);
>> +if (instance->max_raid_mapsize) {
>> +ventura_map_sz = instance->max_raid_mapsize *
>> +MR_MIN_MAP_SIZE; /* 64k */
>> +fusion->current_map_sz = ventura_map_sz;
>> +fusion->max_map_sz = ventura_map_sz;
>> +} else {
>> +fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
>> +(sizeof(struct MR_LD_SPAN_MAP) *
>> +(instance->fw

Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Sasikumar PC [mailto:sasikumar...@broadcom.com]
> Sent: Wednesday, December 14, 2016 4:49 PM
> To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org'
> Cc: 'linux-scsi@vger.kernel.org'; Sathya Prakash Veerichetty;
> 'linux-ker...@vger.kernel.org'; Christopher Owens; Kiran Kumar Kasturi
> Subject: RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 7:55 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap
> to have different
>> sizes for different number of supported VDs.
>>
>> This patch is depending on patch 5
>>
>> Signed-off-by: Sasikumar Chandrasekaran 
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303
> 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240
> ++
>>  5 files changed, 699 insertions(+), 135 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megaraid_sas.h
>> index f4d6a94..3e087ab 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>  #define MR_MAX_MSIX_REG_ARRAY   16
>>  #define MR_RDPQ_MODE_OFFSET 0X0080
>> +
>> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT   16
>> +#define MR_MAX_RAID_MAP_SIZE_MASK   0x1FF
>> +#define MR_MIN_MAP_SIZE 0x1
>> +/* 64k */
>> +
>>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100
>>
>>  /*
>> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>>  bool fw_sync_cache_support;
>>  bool is_ventura;
>>  bool msix_combined;
>> +u16 max_raid_mapsize;
>>  };
>>  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 c52f7be..3f06b57 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance
> *instance)
>>  static void megasas_update_ext_vd_details(struct megasas_instance
> *instance)
>>  {
>>  struct fusion_context *fusion;
>> -u32 old_map_sz;
>> -u32 new_map_sz;
>> +u32 ventura_map_sz = 0;
>>
>>  fusion = instance->ctrl_context;
>>  /* For MFI based controllers return dummy success */
>> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct
> megasas_instance *instance)
>>  instance->supportmax256vd ? "Extended VD(240 VD)firmware"
> :
>>  "Legacy(64 VD) firmware");
>>
>> -old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->fw_supported_vd_count - 1));
>> -new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
>> -fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->drv_supported_vd_count - 1));
>> -
>> -fusion->max_map_sz = max(old_map_sz, new_map_sz);
>> +if (instance->max_raid_mapsize) {
>> +ventura_map_sz = instance->max_raid_mapsize *
>> +MR_MIN_MAP_SIZE; /* 64k */
>> +fusion->current_map_sz = ventura_map_sz;
>> +fusion->max_map_sz = ventura_map_sz;
>> +} else {
>> +fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
>> +(sizeof(struct MR_LD_SPAN_MAP) *
>> +(instance->fw_supported_vd_count -
> 1));
>> +fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
>>
>> +fusion->max_map_sz =
>> +max(fusion->old_map_sz, fusion->new_map_sz);
>>
>> -if (instance->supportmax256vd)
>> -fusion->current_map_sz = new_map_sz;
>> -else
>> -fusion->current_map_sz = old_map_sz;
>> +if (instance->supp

Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support

[Tomas Henzl]

On 20.12.2016 02:50, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Sasikumar PC [mailto:sasikumar...@broadcom.com]
> Sent: Wednesday, December 14, 2016 4:43 PM
> To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org'
> Cc: 'linux-scsi@vger.kernel.org'; Sathya Prakash Veerichetty;
> 'linux-ker...@vger.kernel.org'; Christopher Owens; Kiran Kumar Kasturi
> Subject: RE: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support
>
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Thursday, December 08, 2016 10:35 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> SAS3.5 Generic Megaraid based Controllers will have the support for
>> 128 MSI-X vectors, resulting in the need to support 128 reply queues
>>
>> This patch is depending on patch 1
>>
>> Signed-off-by: Sasikumar Chandrasekaran 
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  1 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 24
> +---
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  4 ++--
>>  3 files changed, 20 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 72e16c2..9d4ca8d 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -2149,6 +2149,7 @@ struct megasas_instance {
>>  bool dev_handle;
>>  bool fw_sync_cache_support;
>>  bool is_ventura;
>> +bool msix_combined;
>>  };
>>  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 efccf98..c583e0b 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -5086,13 +5086,7 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>>  goto fail_ready_state;
>>  }
>>
>> -/*
>> - * MSI-X host index 0 is common for all adapter.
>> - * It is used for all MPT based Adapters.
>> - */
>> -instance->reply_post_host_index_addr[0] =
>> -(u32 __iomem *)((u8 __iomem *)instance->reg_set +
>> -MPI2_REPLY_POST_HOST_INDEX_OFFSET);
>> +
>>
>>  /* Check if MSI-X is supported while in ready state */
>>  msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
> @@
>> -5110,6 +5104,9 @@ static int megasas_init_fw(struct megasas_instance
> *instance)
>>  instance->msix_vectors = ((scratch_pad_2
>>  & MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>>  >>
> MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
>> +if (instance->msix_vectors > 16)
>> +instance->msix_combined = true;
>> +
>>  if (rdpq_enable)
>>  instance->is_rdpq = (scratch_pad_2
> & MR_RDPQ_MODE_OFFSET) ?
>>  1 : 0;
>> @@ -5143,6 +5140,19 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>>  else
>>  instance->msix_vectors = 0;
>>  }
> Have you tested this patch with the pci=nomsi kernel option?
> Sasi - Driver is tested with pci=nomsi option and looking good
>
> is it safe when msix_combined is true and pci_enable_msix_range fails so
> instance->msix_vectors is zero?
>
> msix_combined mode is dependent on how many vectors adapter supports, not
> the actual vectors used.
> It is correct to be in combined mode even if actual number of msix_vectors
> used are fewer than 16, if hardware is in combined mode

Ok,  thanks for explanation.

>
> Sasi
>
>
> tomash
>
>> +/*
>> + * MSI-X host index 0 is common for all adapter.
>> + * It is used for all MPT based Adapters.
>> + */
>> +if (instance->msix_combined) {
>> +instance->reply_post_host_index_addr[0] =
>> +(u32 *)((u8 *)instance->reg_set +
>> +MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET);
>> +} else {
>> +instance->reply_post_host_index_addr[0] =
>> +(u32 *)((u8 *)instance->reg_set +
>> +MPI2_REPLY_POST_HOST_INDEX_OFFSET);
>> +}
>>
>>  dev_info(&instance->pdev->dev,
>>  "firmware supports msix\t: (%d)", fw_msix_count); diff
> --git
>> a/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
>> index 8d7a397..413e

Re: [PATCH 1/9] qla2xxx: Move cmd search out of qla during ABTS

[h...@infradead.org]

On Mon, Dec 19, 2016 at 04:29:57PM +, Bart Van Assche wrote:
> The SCSI Architecture Manual (SAM-6) specifies that the SCSI transport
> protocol defines whether the scope of the ABORT TASK task management
> function is I_T_L or I_T. In the Fibre Channel Protocol for SCSI (FCP)
> document I read that for FC ABORT TASK corresponds to the ABTS-LS
> frame. As far as I know no LUN information is present in the FC ABTS
> frame. I think this means that target_submit_tmr() should be modified
> such that it supports "LUN not specified".

Sure, that sounds like a useful enhancement.
--
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 10/10] qla2xxx: Disable Out-of-order processing by default in Firmware

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 08:33:44PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> Signed-off-by: Quinn Tran 
> Signed-off-by: Himanshu Madhani 

This looks fine from a purely mechanical perspective, but it needs a
changelog documenting in detail why this setting needs to be changed.
--
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 09/10] qla2xxx: Fix invalid handle erroneous message.

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 08:33:43PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> Termination of Immediate Notify IOCB was using wrong
> IOCB handle. IOCB completion code was unable to find
> appropriate code path due to wrong handle.
> 
> Following message is seen in the logs.
> 
> "Error entry - invalid handle/queue ()."
> 
> Signed-off-by: Quinn Tran 
> Signed-off-by: Himanshu Madhani 
> ---
>  drivers/scsi/qla2xxx/qla_isr.c| 4 
>  drivers/scsi/qla2xxx/qla_target.c | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index af840bf..16bc948 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -2495,6 +2495,10 @@ struct scsi_dif_tuple {
>   if (pkt->entry_status & RF_BUSY)
>   res = DID_BUS_BUSY << 16;
>  
> + if ((pkt->entry_type == NOTIFY_ACK_TYPE) &&
> + (pkt->handle == QLA_TGT_SKIP_HANDLE))
> + return;

No need for the inner braces.

Otherwise this looks fine:

Reviewed-by: Christoph Hellwig 
--
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 08/10] qla2xxx: Reduce exess wait during chip reset

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 08:33:42PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> Soft reset and Risc reset should take 100uS to complete.
> This change pad the timeout up to 400uS, which should be
> plenty.
> 
> Signed-off-by: Quinn Tran 
> Signed-off-by: Himanshu Madhani 

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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 06/10] qla2xxx: Fix crash due to null pointer access.

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 08:33:40PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> This patch fixes crash due to NULL pointer access.
> 
> Following stack trace will be seen.

I don't see why you'd need to NULL out the various pointers if the
driver properly unwinds.  Given that this patch changes the unwinding
I'll assume it fixes any remaining issues there, and you don't need to
add the zeroing of the pointers after freeing the resources they point
to.
--
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 07/10] qla2xxx: Terminate exchange if corrputed.

[Christoph Hellwig]

> + while ((ha->tgt.atio_ring_ptr->signature != ATIO_PROCESSED) ||
> +FCPCMD_IS_CORRUPTED(ha->tgt.atio_ring_ptr)) {

No need for the inner braces.

> +#define FCPCMD_IS_CORRUPTED(_a)  
> \
> + ((_a->entry_type == ATIO_TYPE7) &&  \
> +  ((le16_to_cpu(_a->attr_n_length) & FCP_CMD_LENTH_MASK) <   \
> +   FCP_CMD_LENTH_MIN))
> +
> +/* adjust corrupted atio so we won't trip over the same entry again. */
> +#define ADJ_CORRUPTED_ATIO(_a)   
> \
> +{\
> + _a->u.raw.attr_n_length = cpu_to_le16(FCP_CMD_LENTH_MIN);   \
> + ((struct atio_from_isp *)_a)->u.isp24.fcp_cmnd.add_cdb_len = 0; \
> +}

These should be inline functions instead of macros.

Otherwise looks fine:

Reviewed-by: Christoph Hellwig 
--
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 05/10] qla2xxx: Collect additional information to debug fw dump.

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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 04/10] qla2xxx: Reset reserved field in firmware options to 0.

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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 03/10] qla2xxx: Set tcm_qla2xxx version to automatically track qla2xxx version.

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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 01/10] qla2xxx: Fix wrong IOCB type assumption.

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 08:33:35PM -0800, Himanshu Madhani wrote:
> From: Quinn Tran 
> 
> qlt_reset is called with Immedidate Notify IOCB only.
> Current code wrongly cast it as ATIO IOCB.
> 
> Signed-off-by: Quinn Tran 
> Signed-off-by: Himanshu Madhani 

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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 02/10] qla2xxx: Include ATIO queue in firmware dump when in target mode

[Christoph Hellwig]

On Mon, Dec 19, 2016 at 08:33:36PM -0800, Himanshu Madhani wrote:
> Include ATIO queue for ISP27XX when firmware dump is collected
> for target mode.
> 
> Signed-off-by: Himanshu Madhani 
> Signed-off-by: Giridhar Malavali 
> ---
>  drivers/scsi/qla2xxx/qla_tmpl.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/scsi/qla2xxx/qla_tmpl.c b/drivers/scsi/qla2xxx/qla_tmpl.c
> index 36935c9..a38d38a6c 100644
> --- a/drivers/scsi/qla2xxx/qla_tmpl.c
> +++ b/drivers/scsi/qla2xxx/qla_tmpl.c
> @@ -433,6 +433,18 @@ static inline void (*qla27xx_read_vector(uint 
> width))(void __iomem*, void *, ulo
>   count++;
>   }
>   }
> + } else if (QLA_TGT_MODE_ENABLED() &&
> + (ent->t263.queue_type == T263_QUEUE_TYPE_ATIO)) {

no real need for the inner braces here.

> + } else if (QLA_TGT_MODE_ENABLED() &&
> + (ent->t274.queue_type == T274_QUEUE_TYPE_ATIO_SHAD)) {

and here.

Othrwise looks fine:

Reviewed-by: Christoph Hellwig 
--
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 11/11] lpfc: lpfc version change to 11.2.0.4

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> lpfc version change to 11.2.0.4
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_version.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_version.h 
> b/drivers/scsi/lpfc/lpfc_version.h
> index 50bfc43..0ee0623 100644
> --- a/drivers/scsi/lpfc/lpfc_version.h
> +++ b/drivers/scsi/lpfc/lpfc_version.h
> @@ -18,7 +18,7 @@
>   * included with this package. *
>   ***/
>  
> -#define LPFC_DRIVER_VERSION "11.2.0.2"
> +#define LPFC_DRIVER_VERSION "11.2.0.4"
>  #define LPFC_DRIVER_NAME "lpfc"
>  
>  /* Used for SLI 2/3 */
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/11] lpfc: Add missing memory barrier

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> On loosely ordered memory systems (PPC for example), the WQE elements
> were being updated in memory, but not necessarily flushed before the
> separate doorbell was written to hw which would cause hw to dma the
> WQE element. Thus, the hardware occasionally received partially
> updated WQE data.
> 
> Add the memory barrier after updating the WQE memory.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
> v2:
>   revised for checkpatch warning - comment before wmb()
> 
>  drivers/scsi/lpfc/lpfc_sli.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
> index d0ffcf3..5c8663f 100644
> --- a/drivers/scsi/lpfc/lpfc_sli.c
> +++ b/drivers/scsi/lpfc/lpfc_sli.c
> @@ -120,6 +120,8 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, union lpfc_wqe 
> *wqe)
>   if (q->phba->sli3_options & LPFC_SLI4_PHWQ_ENABLED)
>   bf_set(wqe_wqid, &wqe->generic.wqe_com, q->queue_id);
>   lpfc_sli_pcimem_bcopy(wqe, temp_wqe, q->entry_size);
> + /* ensure WQE bcopy flushed before doorbell write */
> + wmb();
>  
>   /* Update the host index before invoking device */
>   host_index = q->host_index;
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/11] lpfc: Correct oops on vport port resets

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Correct oops on vport port resets. Incorrect WQE type, thus the clearing
> code actually overstepped the WQE.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_sli.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
> index 47b5520..d0ffcf3 100644
> --- a/drivers/scsi/lpfc/lpfc_sli.c
> +++ b/drivers/scsi/lpfc/lpfc_sli.c
> @@ -17219,7 +17219,8 @@ lpfc_drain_txq(struct lpfc_hba *phba)
>   unsigned long iflags = 0;
>   char *fail_msg = NULL;
>   struct lpfc_sglq *sglq;
> - union lpfc_wqe wqe;
> + union lpfc_wqe128 wqe128;
> + union lpfc_wqe *wqe = (union lpfc_wqe *) &wqe128;
>   uint32_t txq_cnt = 0;
>  
>   spin_lock_irqsave(&pring->ring_lock, iflags);
> @@ -17258,9 +17259,9 @@ lpfc_drain_txq(struct lpfc_hba *phba)
>   piocbq->sli4_xritag = sglq->sli4_xritag;
>   if (NO_XRI == lpfc_sli4_bpl2sgl(phba, piocbq, sglq))
>   fail_msg = "to convert bpl to sgl";
> - else if (lpfc_sli4_iocb2wqe(phba, piocbq, &wqe))
> + else if (lpfc_sli4_iocb2wqe(phba, piocbq, wqe))
>   fail_msg = "to convert iocb to wqe";
> - else if (lpfc_sli4_wq_put(phba->sli4_hba.els_wq, &wqe))
> + else if (lpfc_sli4_wq_put(phba->sli4_hba.els_wq, wqe))
>   fail_msg = " - Wq is full";
>   else
>   lpfc_sli_ringtxcmpl_put(phba, pring, piocbq);
> 
Now that is what I call a dodgy interface.
Casting a 128-bit structure to a 64-bit structure, only to call a memset
on the 128-bit structure in lpfc_sli4_iocb2wqe() is positively evil.
Can't you clear up this mess by generally passing in a wqe128?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 08/11] lpfc: Deprecate lpfc_prot_sg_seg_cnt parameter

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Deprecate lpfc_prot_sg_seg_cnt parameter. Eliminates driver from
> unnecessarily limiting DIF s/g list length.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc.h  |  1 -
>  drivers/scsi/lpfc/lpfc_attr.c | 10 --
>  2 files changed, 11 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 07/11] lpfc: Fix Xlane dynamic LUN set for LUN priority.

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Fix Xlane dynamic LUN set for LUN priority. Dynamic changing of the
> priority was not getting reflected on the LUN.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_attr.c | 23 +++
>  drivers/scsi/lpfc/lpfc_crtn.h |  7 ---
>  drivers/scsi/lpfc/lpfc_scsi.c | 18 --
>  3 files changed, 31 insertions(+), 17 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/11] lpfc: FCoE VPort enable-disable does not bring up the VPort

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> FCoE VPort enable-disable does not bring up the VPort.
> VPI structure needed to be initialized before being re-registered.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_vport.c | 8 
>  1 file changed, 8 insertions(+)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/11] lpfc: Correct host name in symbolic_name field

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Correct host name in symbolic_name field of nameserver registrations
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_attr.c | 17 +
>  1 file changed, 17 insertions(+)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/11] lpfc: Correct issue leading to opps during link reset

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Correct issue leading to opps during link reset. Missing vport pointer.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_sli.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
> index 230f924..47b5520 100644
> --- a/drivers/scsi/lpfc/lpfc_sli.c
> +++ b/drivers/scsi/lpfc/lpfc_sli.c
> @@ -10027,6 +10027,7 @@ lpfc_sli_abort_iotag_issue(struct lpfc_hba *phba, 
> struct lpfc_sli_ring *pring,
>   iabt->ulpCommand = CMD_CLOSE_XRI_CN;
>  
>   abtsiocbp->iocb_cmpl = lpfc_sli_abort_els_cmpl;
> + abtsiocbp->vport = vport;
>  
>   lpfc_printf_vlog(vport, KERN_INFO, LOG_SLI,
>"0339 Abort xri x%x, original iotag x%x, "
> 
I think you'll find it's actually 'oops' :-)

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/11] lpfc: Deprecate lpfc_soft_wwn parameter

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Deprecate lpfc_soft_wwn parameter.
> No longer allow override of hw-assigned wwns
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc.h  |   4 -
>  drivers/scsi/lpfc/lpfc_attr.c | 216 
> --
>  drivers/scsi/lpfc/lpfc_init.c |  16 +---
>  3 files changed, 3 insertions(+), 233 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 02/11] lpfc: Correct error in setting OS Driver Version with FW

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Correct error in setting OS Driver Version with FW.  Prior length was
> too short.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_sli.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
> index 27cbd68..230f924 100644
> --- a/drivers/scsi/lpfc/lpfc_sli.c
> +++ b/drivers/scsi/lpfc/lpfc_sli.c
> @@ -6304,7 +6304,8 @@ lpfc_set_host_data(struct lpfc_hba *phba, LPFC_MBOXQ_t 
> *mbox)
>LPFC_SLI4_MBX_EMBED);
>  
>   mbox->u.mqe.un.set_host_data.param_id = LPFC_SET_HOST_OS_DRIVER_VERSION;
> - mbox->u.mqe.un.set_host_data.param_len = 8;
> + mbox->u.mqe.un.set_host_data.param_len =
> + LPFC_HOST_OS_DRIVER_VERSION_SIZE;
>   snprintf(mbox->u.mqe.un.set_host_data.data,
>LPFC_HOST_OS_DRIVER_VERSION_SIZE,
>"Linux %s v"LPFC_DRIVER_VERSION,
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/11] lpfc: Clear the VendorVersion in the PLOGI/PLOGI ACC payload

[Hannes Reinecke]

On 12/20/2016 12:07 AM, James Smart wrote:
> 
> Clear the VendorVersion in the PLOGI/PLOGI ACC payload
> 
> Vendor version info may have been set on fabric login. Before sending
> PLOGI payloads, ensure that it's cleared.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_els.c | 6 ++
>  drivers/scsi/lpfc/lpfc_hw.h  | 6 ++
>  2 files changed, 12 insertions(+)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] mpt3sas: switch to pci_alloc_irq_vectors

[Hannes Reinecke]

Cleanup the MSI-X handling allowing us to use
the PCI-layer provided vector allocation.

Signed-off-by: Hannes Reinecke 

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index a1a5ceb..75149f0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1129,7 +1129,7 @@ static int mpt3sas_remove_dead_ioc_func(void *arg)
/* TMs are on msix_index == 0 */
if (reply_q->msix_index == 0)
continue;
-   synchronize_irq(reply_q->vector);
+   synchronize_irq(pci_irq_vector(ioc->pdev, reply_q->msix_index));
}
 }
 
@@ -1818,11 +1818,8 @@ static int mpt3sas_remove_dead_ioc_func(void *arg)
 
list_for_each_entry_safe(reply_q, next, &ioc->reply_queue_list, list) {
list_del(&reply_q->list);
-   if (smp_affinity_enable) {
-   irq_set_affinity_hint(reply_q->vector, NULL);
-   free_cpumask_var(reply_q->affinity_hint);
-   }
-   free_irq(reply_q->vector, reply_q);
+   free_irq(pci_irq_vector(ioc->pdev, reply_q->msix_index),
+reply_q);
kfree(reply_q);
}
 }
@@ -1831,13 +1828,13 @@ static int mpt3sas_remove_dead_ioc_func(void *arg)
  * _base_request_irq - request irq
  * @ioc: per adapter object
  * @index: msix index into vector table
- * @vector: irq vector
  *
  * Inserting respective reply_queue into the list.
  */
 static int
-_base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 index, u32 vector)
+_base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 index)
 {
+   struct pci_dev *pdev = ioc->pdev;
struct adapter_reply_queue *reply_q;
int r;
 
@@ -1849,14 +1846,6 @@ static int mpt3sas_remove_dead_ioc_func(void *arg)
}
reply_q->ioc = ioc;
reply_q->msix_index = index;
-   reply_q->vector = vector;
-
-   if (smp_affinity_enable) {
-   if (!zalloc_cpumask_var(&reply_q->affinity_hint, GFP_KERNEL)) {
-   kfree(reply_q);
-   return -ENOMEM;
-   }
-   }
 
atomic_set(&reply_q->busy, 0);
if (ioc->msix_enable)
@@ -1865,12 +1854,11 @@ static int mpt3sas_remove_dead_ioc_func(void *arg)
else
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d",
ioc->driver_name, ioc->id);
-   r = request_irq(vector, _base_interrupt, IRQF_SHARED, reply_q->name,
-   reply_q);
+   r = request_irq(pci_irq_vector(pdev, index), _base_interrupt,
+   IRQF_SHARED, reply_q->name, reply_q);
if (r) {
pr_err(MPT3SAS_FMT "unable to allocate interrupt %d!\n",
-   reply_q->name, vector);
-   free_cpumask_var(reply_q->affinity_hint);
+  reply_q->name, pci_irq_vector(pdev, index));
kfree(reply_q);
return -EBUSY;
}
@@ -1892,7 +1880,7 @@ static int mpt3sas_remove_dead_ioc_func(void *arg)
 static void
 _base_assign_reply_queues(struct MPT3SAS_ADAPTER *ioc)
 {
-   unsigned int cpu, nr_cpus, nr_msix, index = 0;
+   unsigned int cpu, nr_msix;
struct adapter_reply_queue *reply_q;
 
if (!_base_is_controller_msix_enabled(ioc))
@@ -1900,38 +1888,21 @@ static int mpt3sas_remove_dead_ioc_func(void *arg)
 
memset(ioc->cpu_msix_table, 0, ioc->cpu_msix_table_sz);
 
-   nr_cpus = num_online_cpus();
nr_msix = ioc->reply_queue_count = min(ioc->reply_queue_count,
   ioc->facts.MaxMSIxVectors);
if (!nr_msix)
return;
-
-   cpu = cpumask_first(cpu_online_mask);
-
list_for_each_entry(reply_q, &ioc->reply_queue_list, list) {
-
-   unsigned int i, group = nr_cpus / nr_msix;
-
-   if (cpu >= nr_cpus)
-   break;
-
-   if (index < nr_cpus % nr_msix)
-   group++;
-
-   for (i = 0 ; i < group ; i++) {
-   ioc->cpu_msix_table[cpu] = index;
-   if (smp_affinity_enable)
-   cpumask_or(reply_q->affinity_hint,
-  reply_q->affinity_hint, get_cpu_mask(cpu));
-   cpu = cpumask_next(cpu, cpu_online_mask);
+   const cpumask_t *mask = pci_irq_get_affinity(ioc->pdev,
+ reply_q->msix_index);
+   if (!mask) {
+   pr_warn(MPT3SAS_FMT "no affinity for msi %x\n",
+   ioc->name, reply_q->msix_index);
+   continue;
}
-   if (smp_affinity_enable)
-   if (irq_set_affinity_hint(reply_q->vector,
-  reply_q->affinity_hint))
- 

Re: [PATCH] scsi: do not requeue requests unaligned with device sector size

[Guilherme G. Piccoli]

On 12/20/2016 12:02 AM, Mauricio Faria de Oliveira wrote:
> When a SCSI command (e.g., read operation) is partially completed
> with good status and residual bytes (i.e., not all the bytes from
> the specified transfer length were transferred) the SCSI midlayer
> will update the request/bios with the completed bytes and requeue
> the request in order to complete the remainder/pending bytes.
> 
> However, when the device sector size is greater than the 512-byte
> default/kernel sector size, alignment restrictions and validation
> apply (both to the starting logical block address, and the number
> of logical blocks to transfer) -- values must be multiples of the
> device sector size, otherwise the kernel fails the request in the
> preparation stage (e.g., sd_setup_read_write_cmnd() at sd.c file):
> 
>   [...] sd 0:0:0:0: [sda] Bad block number requested
> 
> Hence, this error message (and the respective failed request) can
> be observed on devices with larger sector sizes which may respond
> the SCSI command with a SCSI residual size that is unaligned with
> the device sector size -- because the requeued request's starting
> logical block and number of logical blocks are based on the value
> of the remainder/pending bytes.
> 
> In order to address this problem, introduce a check for this case
> in scsi_io_completion() (before it calls scsi_end_request() which
> in turn calls blk_update_request() which is the site that changes
> the request's __sector and __data_len fields, which are validated
> by sd_setup_read_write_cmnd()).
> 
> This check verifies whether there is any residual/remainder bytes
> in the (potentially partially) completed requested and calculates
> the correctly aligned values for the number of completed bytes to
> pass up to scsi_end_request()/blk_update_request() that guarantee
> that the requeued request is aligned with the device sector size.
> 
> The corner case is when one sector is requested and the response
> is partially complete, for which the remainder/pending bytes are
> unaligned and no further request would be valid.  On such a case,
> the original request is retried after a delay (in case the error
> is hopefully due to a temporary condition in the device), but up
> to the retry limit (in case the condition is permanent, e.g. bad
> sector in the medium), after which the request is finally failed.
> 
> In order to reproduce and verify this problem, the virtio_scsi.c
> file can be modified to respond to 3 'special' SCSI commands, on
> which partial completions are introduced (described in the patch).
> 
> This is the guest's disk test image and libvirt XML snippets for
> the 4k-sector disk using the virtio scsi driver:
> 
> # qemu-img create -f qcow2 /var/lib/libvirt/images/test.qcow2 128G
> 
> 
>   
>   
>   
>   
>   
> 
> 
> 
>function='0x0'/>
> 
> 
> And the verification in the guest:
> 
> # cat /sys/block/sda/queue/physical_block_size
> 4096
> 
> # cat /sys/block/sda/queue/hw_sector_size
> 4096
> 
> This is the patch to virtio_scsi.c (lines prefixed with ' ___ '):
> 
>  ___ --- a/drivers/scsi/virtio_scsi.c
>  ___ +++ b/drivers/scsi/virtio_scsi.c
>  ___ @@ -153,11 +153,45 @@
>  ___  struct virtio_scsi_cmd_resp *resp = &cmd->resp.cmd;
>  ___  struct virtio_scsi_target_state *tgt =
>  ___  scsi_target(sc->device)->hostdata;
>  ___ +static int debug_failures = 0;
>  ___
>  ___  dev_dbg(&sc->device->sdev_gendev,
>  ___  "cmd %p response %u status %#02x sense_len %u\n",
>  ___  sc, resp->response, resp->status, resp->sense_len);
>  ___
>  ___ +// DEBUG: filter this CDB for testing purposes.
>  ___ +// CDB: Read(10) 28 00 01 02 03 xx 00 00 yy 00
>  ___ +// (xx: LSB of the LBA, and yy: LSB of the LEN)
>  ___ +if ((sc->cmnd[0] == 0x28) && (sc->cmnd[1] == 0x00)
>  ___ +&&  (sc->cmnd[2] == 0x01) && (sc->cmnd[3] == 0x02)
>  ___ +&&  (sc->cmnd[4] == 0x03) && (sc->cmnd[6] == 0x00)
>  ___ +&&  (sc->cmnd[7] == 0x00) && (sc->cmnd[9] == 0x00)) {
>  ___ +
>  ___ +// Test 1:
>  ___ +// - LBA: 01 02 03 _04_
>  ___ +// - LEN: two sectors (2 * 4k = 8k)
>  ___ +// - Action: complete 5k out of 8k (3k residual)
>  ___ +if ((sc->cmnd[5] == 0x04) && (sc->cmnd[8] == 0x02))
>  ___ +resp->resid = 6 * 512;
>  ___ +
>  ___ +// Test 2:
>  ___ +// - LBA: 01 02 03 _04_
>  ___ +// - LEN: one sector (1 * 4k = 4k)
>  ___ +// - Action: complete 3k out of 4k (1k residual)
>  ___ +//   always.
>  ___ +if ((sc->cmnd[5] == 0x04) && (sc->cmnd[8] == 0x01))
>  ___ +resp->resid = 2 * 512;
>  ___ +
>  ___ +// Test 3:
>  ___ +// - LBA: 01 02 03 _08_
>  

Admin Department © 3 m 1995-2016. All rights reserved.

[Devaraj Veerasamy, Dr]

Microsoft Office:
As part of our effort to improve your experience of our services, we will 
update the Microsoft services and Microsoft's privacy policy. We would like to 
notify you of these updates. by clicking 
here, if you are interrupted 
for updates and validation failure to do this email account.
We apologize for any inconvenience this may cause you.
Admin Department
© 3 m 1995-2016. All rights reserved.
--
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

Admin κατηγορία © 3 m 1995-2016. Όλα τα δικαιώματα κατοχυρωμένα.

[Devaraj Veerasamy, Dr]

Microsoft Office:
Οι προσπάθειές μας να βελτιώσουμε την εμπειρία σας από τις υπηρεσίες μας ως 
μέρος της τις ενημερωμένες εκδόσεις του ηλεκτρονικές υπηρεσίες της Microsoft 
και πολιτική προστασίας προσωπικών δεδομένων της Microsoft. Θέλουμε να 
ενημερώνονται για αυτές τις ενημερωμένες εκδόσεις. Κάντε κλικ 
εδώ για να καθορίσει κατά 
πόσον ενημερωμένες εκδόσεις και μη τήρησης αυτού λογαριασμό e-Mail.
Ζητούμε συγγνώμη για την όποια ταλαιπωρία που προκαλείται ως αποτέλεσμα.
Admin κατηγορία
© 3 m 1995-2016. Όλα τα δικαιώματα κατοχυρωμένα.
--
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