[PATCH v5 2/2] add support for DWC UFS Host Controller

2016-02-10 Thread Joao Pinto
This patch has the goal to add support for DesignWare UFS Controller
specific operations and to add specific platform and pci drivers.

Signed-off-by: Joao Pinto 
---
Changes v4->v5 (Akinobu Mita):
- All functions used only locally in ufshcd-dwc are now declared as static
- ufshcd_dwc_configuration() was removed in ufshcd-dwc and a notify
 function (ufshcd_dwc_link_startup_notify) was created to deal with the
 DWC specific init routines
- 20-bit RMMI option was removed from Kconfig. Now if MPHY TC is selected
 and 40-bit is not then it assumes a 20-bit config
Changes v3->v4 (Arnd Bergmann and Mark Rutland):
- SCSI_UFS_DWC_HOOKS is now silent and selected by the SCSI_UFS_DWC_PLAT
 or SCSI_UFS_DWC_PCI
- Compatibility string has the ufs core version for info purposes since
 the driver is capable of getting the controller version from its 
 registers
- Created ufs-dwc-pci glue driver with specific DWC data
- MPHY configuration remains in the ufshcd-dwc since it is unipro
 attribute writting only not following the a linux phy framework logic
Changes v2->v3 (Julian Calaby):
- Implement a common DWC code to be used by the platform and pci glue
 drivers
- Synopsys ID & Class added to the existing pci driver and specific DWC
 was also added to the pci driver
Changes v1->v2 (Akinobu Mita):
- Implement a platform driver that uses the existing UFS core driver
- Add DWC specific code to the existing UFS core driver

 Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
 MAINTAINERS   |   6 +
 drivers/scsi/ufs/Kconfig  |  41 ++
 drivers/scsi/ufs/Makefile |   3 +
 drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++
 drivers/scsi/ufs/ufs-dwc.c| 102 +++
 drivers/scsi/ufs/ufshcd-dwc.c | 736 ++
 drivers/scsi/ufs/ufshcd-dwc.h |  18 +
 drivers/scsi/ufs/ufshcd.c |  50 +-
 drivers/scsi/ufs/ufshcd.h |  13 +
 drivers/scsi/ufs/ufshci-dwc.h |  42 ++
 drivers/scsi/ufs/ufshci.h |   1 +
 drivers/scsi/ufs/unipro.h |  39 ++
 13 files changed, 1231 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt
 create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c
 create mode 100644 drivers/scsi/ufs/ufs-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h
 create mode 100644 drivers/scsi/ufs/ufshci-dwc.h

diff --git a/Documentation/devicetree/bindings/ufs/ufs-dwc.txt 
b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
new file mode 100644
index 000..f38a3f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
@@ -0,0 +1,17 @@
+* Universal Flash Storage (UFS) DesignWare Host Controller
+
+DWC_UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible: compatible string ("snps,ufshcd-1.0", "snps,ufshcd-1.1"
+  or "snps,ufshcd-2.0")
+- reg   : 
+- interrupts: 
+
+Example:
+   dwc_ufshcd@0xD000 {
+   compatible = "snps,ufshcd-2.0";
+   reg = < 0xD000 0x1 >;
+   interrupts = < 24 >;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index d2f94e2..3db3c4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11006,6 +11006,12 @@ S: Supported
 F: Documentation/scsi/ufs.txt
 F: drivers/scsi/ufs/
 
+UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS
+M: Joao Pinto 
+L: linux-scsi@vger.kernel.org
+S: Supported
+F: drivers/scsi/ufs/*dwc*
+
 UNSORTED BLOCK IMAGES (UBI)
 M: Artem Bityutskiy 
 M: Richard Weinberger 
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5f45307..b4c353c 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,44 @@ config SCSI_UFS_QCOM
 
  Select this if you have UFS controller on QCOM chipset.
  If unsure, say N.
+
+config SCSI_UFS_DWC_HOOKS
+   bool
+
+config SCSI_UFS_DWC_PLAT
+   tristate "DesignWare UFS controller platform glue driver"
+   depends on SCSI_UFSHCD_PLATFORM
+   select SCSI_UFS_DWC_HOOKS
+   help
+ This selects the DesignWare UFS host controller platform glue driver.
+
+ Select this if you have a DesignWare UFS controller on Platform bus.
+ If unsure, say N.
+
+config SCSI_UFS_DWC_PCI
+   tristate "DesignWare UFS controller pci glue driver"
+   depends on SCSI_UFSHCD_PCI
+   select SCSI_UFS_DWC_HOOKS
+   help
+ This selects the DesignWare UFS host controller pci glue driver.
+
+ Select this if you have a DesignWare UFS controller on pci bus.
+ If unsure, say N.
+

[PATCH v5 0/2] add support for DWC UFS Controller

2016-02-10 Thread Joao Pinto
The work consisted of:
- Fixed typo in ufshcd-pltfrm.c
- Tweak ufshcd.c for UFS 2.0 support
- Implement ufshcd-dwc which contains all DWC HW specific code
- Unipro attributes were added and new registers were added to the driver
- Implement a ufs-dwc glue platform driver
- Implement a ufs-dwc-pci glue pci driver

Joao Pinto (2):
  fixed typo in ufshcd-pltfrm
  add support for DWC UFS Host Controller

 Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
 MAINTAINERS   |   6 +
 drivers/scsi/ufs/Kconfig  |  41 ++
 drivers/scsi/ufs/Makefile |   3 +
 drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++
 drivers/scsi/ufs/ufs-dwc.c| 102 +++
 drivers/scsi/ufs/ufshcd-dwc.c | 736 ++
 drivers/scsi/ufs/ufshcd-dwc.h |  18 +
 drivers/scsi/ufs/ufshcd-pltfrm.c  |   2 +-
 drivers/scsi/ufs/ufshcd.c |  50 +-
 drivers/scsi/ufs/ufshcd.h |  13 +
 drivers/scsi/ufs/ufshci-dwc.h |  42 ++
 drivers/scsi/ufs/ufshci.h |   1 +
 drivers/scsi/ufs/unipro.h |  39 ++
 14 files changed, 1232 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt
 create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c
 create mode 100644 drivers/scsi/ufs/ufs-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h
 create mode 100644 drivers/scsi/ufs/ufshci-dwc.h

-- 
1.8.1.5

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


[PATCH v5 1/2] fixed typo in ufshcd-pltfrm

2016-02-10 Thread Joao Pinto
Fixed typo in ufshcd-pltfrm.

Signed-off-by: Joao Pinto 
---
Changes v0->v5:
- Nothing changed (just to keep up with patch set version).

 drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index d2a7b12..0522891 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -353,6 +353,6 @@ EXPORT_SYMBOL_GPL(ufshcd_pltfrm_init);
 
 MODULE_AUTHOR("Santosh Yaragnavi ");
 MODULE_AUTHOR("Vinayak Holikatti ");
-MODULE_DESCRIPTION("UFS host controller Pltform bus based glue driver");
+MODULE_DESCRIPTION("UFS host controller Platform bus based glue driver");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(UFSHCD_DRIVER_VERSION);
-- 
1.8.1.5

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


Re: [PATCH] Separate target visibility from reaped state information

2016-02-10 Thread James Bottomley
On Wed, 2016-02-10 at 15:05 +0100, Johannes Thumshirn wrote:
> On Wed, Feb 03, 2016 at 11:38:16PM +0100, Sebastian Herbszt wrote:
> > James Bottomley wrote:
> > > On Mon, 2016-02-01 at 19:43 -0800, Bart Van Assche wrote:
> > > > On 01/19/16 17:03, James Bottomley wrote:
> > > > > On Tue, 2016-01-19 at 19:30 -0500, Martin K. Petersen wrote:
> > > > > > > > > > > "Bart" == Bart Van Assche <
> > > > > > > > > > > bart.vanass...@sandisk.com>
> > > > > > > > > > > writes:
> > > > > > 
> > > > > > Bart> Instead of representing the states "visible in sysfs"
> > > > > > and
> > > > > > "has
> > > > > > Bart> been removed from the target list" by a single state
> > > > > > variable,
> > > > > > use
> > > > > > Bart> two variables to represent this information.
> > > > > > 
> > > > > > James: Are you happy with the latest iteration of this?
> > > > > > Should I
> > > > > > queue
> > > > > > it?
> > > > > 
> > > > > Well, I'm OK with the patch: it's a simple transformation of
> > > > > the
> > > > > enumerated state to a two bit state.  What I can't see is how
> > > > > it
> > > > > fixes
> > > > > any soft lockup.
> > > > > 
> > > > > The only change from the current workflow is that the DEL
> > > > > transition
> > > > > (now the reaped flag) is done before the spin lock is dropped
> > > > > which
> > > > > would fix a tiny window for two threads both trying to remove
> > > > > the
> > > > > same
> > > > > target, but there's nothing that could possibly fix an
> > > > > iterative
> > > > > soft
> > > > > lockup caused by restarting the loop, which is what the
> > > > > changelog
> > > > > says.
> > > > 
> > > > Hello James,
> > > > 
> > > > scsi_remove_target() doesn't lock the scan_mutex which means
> > > > that 
> > > > concurrent SCSI scanning activity is not prohibited. Such
> > > > scanning 
> > > > activity can postpone the transition of the state of a SCSI
> > > > target 
> > > > into STARGET_DEL. I think if the scheduler decides to run the
> > > > thread 
> > > > that executes scsi_remove_target() on the same CPU as the
> > > > scanning 
> > > > code after the scanning code has obtained a reap ref and before
> > > > the 
> > > > scanning code has released the reap ref again that the soft
> > > > lockup 
> > > > can be triggered that has been reported by Sebastian Herbszt.
> > > 
> > > OK, I finally understand the scenario;  I'm not sure I understand
> > > how
> > > we're getting concurrent scanning and removal from a simple rmmod
> > > ... I
> > > take it this is insmod rmmod in a tight loop?
> > 
> > I am able to trigger the soft lockup with this test case run once:
> > 
> > modprobe lpfc
> > run fio for 10 seconds
> > rmmod lpfc
> > 
> > My test setup involves running qla2xxx in target mode (SCST) and
> > lpfc as initiator on the same system with one exported volume.
> > 
> > Dick, how did you trigger the lockup?
> > 
> > Sebastian
> 
> Hi James, Bart, Martin
> 
> Have you already decided, which of the two patches you favour and 
> when it'llbe included?
> 
> I have several customer reports that hit this lockup and I don't want 
> to include one of the patches from the list just to find out the 
> other one's is used in mainline.

Well, unless the target allocation bug gets fixed in Bart's, it will
have to be the last_scan one.  It's more a hack than a fix, but I
suppose it will do as a bandaid in the meantime.

If you have diagnosed this at customers, I'd still like to know what's
holding the devices on removal.

Thanks,

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


Re: [PATCH] Separate target visibility from reaped state information

2016-02-10 Thread Johannes Thumshirn
On Wed, Feb 03, 2016 at 11:38:16PM +0100, Sebastian Herbszt wrote:
> James Bottomley wrote:
> > On Mon, 2016-02-01 at 19:43 -0800, Bart Van Assche wrote:
> > > On 01/19/16 17:03, James Bottomley wrote:
> > > > On Tue, 2016-01-19 at 19:30 -0500, Martin K. Petersen wrote:
> > > > > > > > > > "Bart" == Bart Van Assche 
> > > > > > > > > > writes:
> > > > > 
> > > > > Bart> Instead of representing the states "visible in sysfs" and
> > > > > "has
> > > > > Bart> been removed from the target list" by a single state
> > > > > variable,
> > > > > use
> > > > > Bart> two variables to represent this information.
> > > > > 
> > > > > James: Are you happy with the latest iteration of this? Should I
> > > > > queue
> > > > > it?
> > > > 
> > > > Well, I'm OK with the patch: it's a simple transformation of the
> > > > enumerated state to a two bit state.  What I can't see is how it
> > > > fixes
> > > > any soft lockup.
> > > > 
> > > > The only change from the current workflow is that the DEL
> > > > transition
> > > > (now the reaped flag) is done before the spin lock is dropped which
> > > > would fix a tiny window for two threads both trying to remove the
> > > > same
> > > > target, but there's nothing that could possibly fix an iterative
> > > > soft
> > > > lockup caused by restarting the loop, which is what the changelog
> > > > says.
> > > 
> > > Hello James,
> > > 
> > > scsi_remove_target() doesn't lock the scan_mutex which means that 
> > > concurrent SCSI scanning activity is not prohibited. Such scanning 
> > > activity can postpone the transition of the state of a SCSI target 
> > > into STARGET_DEL. I think if the scheduler decides to run the thread 
> > > that executes scsi_remove_target() on the same CPU as the scanning 
> > > code after the scanning code has obtained a reap ref and before the 
> > > scanning code has released the reap ref again that the soft lockup 
> > > can be triggered that has been reported by Sebastian Herbszt.
> > 
> > OK, I finally understand the scenario;  I'm not sure I understand how
> > we're getting concurrent scanning and removal from a simple rmmod ... I
> > take it this is insmod rmmod in a tight loop?
> 
> I am able to trigger the soft lockup with this test case run once:
> 
> modprobe lpfc
> run fio for 10 seconds
> rmmod lpfc
> 
> My test setup involves running qla2xxx in target mode (SCST) and
> lpfc as initiator on the same system with one exported volume.
> 
> Dick, how did you trigger the lockup?
> 
> Sebastian

Hi James, Bart, Martin

Have you already decided, which of the two patches you favour and when it'll
be included?

I have several customer reports that hit this lockup and I don't want to include
one of the patches from the list just to find out the other one's is used in
mainline.

Thanks in advance,
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


[PATCH] scsi: fix soft lockup in scsi_remove_target() on module removal

2016-02-10 Thread James Bottomley
This softlockup is currently happening:

[  444.088002] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[kworker/1:1:29]
[  444.088002] Modules linked in: lpfc(-) qla2x00tgt(O) qla2xxx_scst(O) 
scst_vdisk(O) scsi_transport_fc libcrc32c scst(O) dlm configfs nfsd lockd grace 
nfs_acl auth_rpcgss sunrpc ed
d snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device dm_mod iTCO_wdt 
snd_hda_codec_realtek snd_hda_codec_generic gpio_ich iTCO_vendor_support ppdev 
snd_hda_intel snd_hda_codec snd_hda
_core snd_hwdep tg3 snd_pcm snd_timer libphy lpc_ich parport_pc ptp 
acpi_cpufreq snd pps_core fjes parport i2c_i801 ehci_pci tpm_tis tpm sr_mod 
cdrom soundcore floppy hwmon sg 8250_
fintek pcspkr i915 drm_kms_helper uhci_hcd ehci_hcd drm fb_sys_fops sysimgblt 
sysfillrect syscopyarea i2c_algo_bit usbcore button video usb_common fan 
ata_generic ata_piix libata th
ermal
[  444.088002] CPU: 1 PID: 29 Comm: kworker/1:1 Tainted: G   O
4.4.0-rc5-2.g1e923a3-default #1
[  444.088002] Hardware name: FUJITSU SIEMENS ESPRIMO E   /D2164-A1, 
BIOS 5.00 R1.10.2164.A1   05/08/2006
[  444.088002] Workqueue: fc_wq_4 fc_rport_final_delete [scsi_transport_fc]
[  444.088002] task: f6266ec0 ti: f6268000 task.ti: f6268000
[  444.088002] EIP: 0060:[] EFLAGS: 0286 CPU: 1
[  444.088002] EIP is at _raw_spin_unlock_irqrestore+0x14/0x20
[  444.088002] EAX: 0286 EBX: f20d3800 ECX: 0002 EDX: 0286
[  444.088002] ESI: f50ba800 EDI: f2146848 EBP: f6269ec8 ESP: f6269ec8
[  444.088002]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  444.088002] CR0: 8005003b CR2: 08f96600 CR3: 363ae000 CR4: 06d0
[  444.088002] Stack:
[  444.088002]  f6269eec c066b0f7 0286 f2146848 f50ba808 f50ba800 f50ba800 
f2146a90
[  444.088002]  f2146848 f6269f08 f8f0a4ed f3141000 f2146800 f2146a90 f619fa00 
0040
[  444.088002]  f6269f40 c026cb25 0001 166c6392 0061 f6757140 f6136340 
0004
[  444.088002] Call Trace:
[  444.088002]  [] scsi_remove_target+0x167/0x1c0
[  444.088002]  [] fc_rport_final_delete+0x9d/0x1e0 
[scsi_transport_fc]
[  444.088002]  [] process_one_work+0x155/0x3e0
[  444.088002]  [] worker_thread+0x37/0x490
[  444.088002]  [] kthread+0x9b/0xb0
[  444.088002]  [] ret_from_kernel_thread+0x21/0x40

What appears to be happening is that something has pinned the target
so it can't go into STARGET_DEL via final release and the loop in
scsi_remove_target spins endlessly until that happens.

The fix for this soft lockup is to not keep looping over a device that
we've called remove on but which hasn't gone into DEL state.  This
patch will retain a simplistic memory of the last target and not keep
looping over it.

Reported-by: Sebastian Herbszt 
Tested-by: Sebastian Herbszt 
Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
Cc: sta...@vger.kernel.org
Signed-off-by: James Bottomley 

---

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 4f18a85..00bc721 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1272,16 +1272,18 @@ static void __scsi_remove_target(struct scsi_target 
*starget)
 void scsi_remove_target(struct device *dev)
 {
struct Scsi_Host *shost = dev_to_shost(dev->parent);
-   struct scsi_target *starget;
+   struct scsi_target *starget, *last_target = NULL;
unsigned long flags;
 
 restart:
spin_lock_irqsave(shost->host_lock, flags);
list_for_each_entry(starget, >__targets, siblings) {
-   if (starget->state == STARGET_DEL)
+   if (starget->state == STARGET_DEL ||
+   starget == last_target)
continue;
if (starget->dev.parent == dev || >dev == dev) {
kref_get(>reap_ref);
+   last_target = starget;
spin_unlock_irqrestore(shost->host_lock, flags);
__scsi_remove_target(starget);
scsi_target_reap(starget);
--
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] be2iscsi: Fix memory leak in beiscsi_alloc_mem()

2016-02-10 Thread Martin K. Petersen
> "Maurizio" == Maurizio Lombardi  writes:

Jitendra,

Please review.

> In case of error, the memory allocated for phwi_ctrlr was not freed.
> 
> Signed-off-by: Maurizio Lombardi 
> ---
>  drivers/scsi/be2iscsi/be_main.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
> index 7a6dbfb..360aa88 100644
> --- a/drivers/scsi/be2iscsi/be_main.c
> +++ b/drivers/scsi/be2iscsi/be_main.c
> @@ -2706,8 +2706,10 @@ static int beiscsi_alloc_mem(struct beiscsi_hba *phba)
>   phwi_ctrlr->wrb_context = kzalloc(sizeof(struct hwi_wrb_context) *
> phba->params.cxns_per_ctrl,
> GFP_KERNEL);
> - if (!phwi_ctrlr->wrb_context)
> + if (!phwi_ctrlr->wrb_context) {
> + kfree(phba->phwi_ctrlr);
>   return -ENOMEM;
> + }
>  
>   phba->init_mem = kcalloc(SE_MEM_MAX, sizeof(*mem_descr),
>GFP_KERNEL);
> 

-- 
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] megaraid_sas: add an i/o barrier

2016-02-10 Thread Martin K. Petersen
> "Tomas" == Tomas Henzl  writes:

Tomas> A barrier should be added to ensure proper ordering of memory
Tomas> mapped writes.

Tomas> V2: - added the barrier also to megasas_fire_cmd_skinny, as
Tomas> suggested by Kashyap Desai

Sumit, Kashyap: Please review this patch.

-- 
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] lpfc: Remove redundant code block in lpfc_scsi_cmd_iocb_cmpl

2016-02-10 Thread Martin K. Petersen
> "Johannes" == Johannes Thumshirn  writes:

Johannes> This removes a redundant code block that will either be
Johannes> executed if the ENABLE_FCP_RING_POLLING flag is set in
Johannes> phba->cfg_poll or not. The code is just duplicated in both
Johannes> cases, hence we unify it again.

James and Dick: Ping!

https://patchwork.kernel.org/patch/8072451/

-- 
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] Separate target visibility from reaped state information

2016-02-10 Thread Johannes Thumshirn
On Wed, Feb 10, 2016 at 07:34:51AM -0800, James Bottomley wrote:
> On Wed, 2016-02-10 at 15:05 +0100, Johannes Thumshirn wrote:
> > On Wed, Feb 03, 2016 at 11:38:16PM +0100, Sebastian Herbszt wrote:
> > > James Bottomley wrote:
> > > > On Mon, 2016-02-01 at 19:43 -0800, Bart Van Assche wrote:
> > > > > On 01/19/16 17:03, James Bottomley wrote:
> > > > > > On Tue, 2016-01-19 at 19:30 -0500, Martin K. Petersen wrote:
> > > > > > > > > > > > "Bart" == Bart Van Assche <
> > > > > > > > > > > > bart.vanass...@sandisk.com>
[..]
> > > 
> > > Sebastian
> > 
> > Hi James, Bart, Martin
> > 
> > Have you already decided, which of the two patches you favour and 
> > when it'llbe included?
> > 
> > I have several customer reports that hit this lockup and I don't want 
> > to include one of the patches from the list just to find out the 
> > other one's is used in mainline.
> 
> Well, unless the target allocation bug gets fixed in Bart's, it will
> have to be the last_scan one.  It's more a hack than a fix, but I
> suppose it will do as a bandaid in the meantime.
> 
> If you have diagnosed this at customers, I'd still like to know what's
> holding the devices on removal.
> 
> Thanks,
> 
> James

I'll setup a test environment tomorrow and try to get some crash dumps with
the current HEAD.

-- 
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: [mpt3sas driver patches 00/10] mpt3sas driver enhancements and

2016-02-10 Thread Martin K. Petersen
> "Suganath" == Suganath prabu Subaramani 
>  writes:

Applied to 4.6/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


[PATCH v6 0/2] add support for DWC UFS Controller

2016-02-10 Thread Joao Pinto
The work consisted of:
- Fixed typo in ufshcd-pltfrm.c
- Tweak ufshcd.c for UFS 2.0 support
- Implement ufshcd-dwc which contains all DWC HW specific code
- Unipro attributes were added and new registers were added to the driver
- Implement a ufs-dwc glue platform driver
- Implement a ufs-dwc-pci glue pci driver

Joao Pinto (2):
  fixed typo in ufshcd-pltfrm
  add support for DWC UFS Host Controller

 Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
 MAINTAINERS   |   6 +
 drivers/scsi/ufs/Kconfig  |  41 ++
 drivers/scsi/ufs/Makefile |   3 +
 drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++
 drivers/scsi/ufs/ufs-dwc.c| 102 +++
 drivers/scsi/ufs/ufshcd-dwc.c | 736 ++
 drivers/scsi/ufs/ufshcd-dwc.h |  18 +
 drivers/scsi/ufs/ufshcd-pltfrm.c  |   2 +-
 drivers/scsi/ufs/ufshcd.c |  50 +-
 drivers/scsi/ufs/ufshcd.h |  13 +
 drivers/scsi/ufs/ufshci-dwc.h |  42 ++
 drivers/scsi/ufs/ufshci.h |   1 +
 drivers/scsi/ufs/unipro.h |  39 ++
 14 files changed, 1232 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt
 create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c
 create mode 100644 drivers/scsi/ufs/ufs-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h
 create mode 100644 drivers/scsi/ufs/ufshci-dwc.h

-- 
1.8.1.5

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


Re: [PATCH RESEND] bfa: deinline __bfa_trc() and __bfa_trc32()

2016-02-10 Thread Martin K. Petersen
> "Denys" == Denys Vlasenko  writes:

Denys> __bfa_trc32() is very similar, so it is uninlined too.  However,
Denys> it appears to be unused, therefore this patch ifdefs it out.

Why don't we just drop it?

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


[PATCH v6 2/2] add support for DWC UFS Host Controller

2016-02-10 Thread Joao Pinto
This patch has the goal to add support for DesignWare UFS Controller
specific operations and to add specific platform and pci drivers.

Signed-off-by: Joao Pinto 
---
Changes v5->v6:
- Patch bad format fixed
Changes v4->v5 (Akinobu Mita):
- All functions used only locally in ufshcd-dwc are now declared as static
- ufshcd_dwc_configuration() was removed in ufshcd-dwc and a notify
 function (ufshcd_dwc_link_startup_notify) was created to deal with the
 DWC specific init routines
- 20-bit RMMI option was removed from Kconfig. Now if MPHY TC is selected
 and 40-bit is not then it assumes a 20-bit config
Changes v3->v4 (Arnd Bergmann and Mark Rutland):
- SCSI_UFS_DWC_HOOKS is now silent and selected by the SCSI_UFS_DWC_PLAT
 or SCSI_UFS_DWC_PCI
- Compatibility string has the ufs core version for info purposes since
 the driver is capable of getting the controller version from its 
 registers
- Created ufs-dwc-pci glue driver with specific DWC data
- MPHY configuration remains in the ufshcd-dwc since it is unipro
 attribute writting only not following the a linux phy framework logic
Changes v2->v3 (Julian Calaby):
- Implement a common DWC code to be used by the platform and pci glue
 drivers
- Synopsys ID & Class added to the existing pci driver and specific DWC
 was also added to the pci driver
Changes v1->v2 (Akinobu Mita):
- Implement a platform driver that uses the existing UFS core driver
- Add DWC specific code to the existing UFS core driver

 Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
 MAINTAINERS   |   6 +
 drivers/scsi/ufs/Kconfig  |  41 ++
 drivers/scsi/ufs/Makefile |   3 +
 drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++
 drivers/scsi/ufs/ufs-dwc.c| 102 +++
 drivers/scsi/ufs/ufshcd-dwc.c | 736 ++
 drivers/scsi/ufs/ufshcd-dwc.h |  18 +
 drivers/scsi/ufs/ufshcd.c |  50 +-
 drivers/scsi/ufs/ufshcd.h |  13 +
 drivers/scsi/ufs/ufshci-dwc.h |  42 ++
 drivers/scsi/ufs/ufshci.h |   1 +
 drivers/scsi/ufs/unipro.h |  39 ++
 13 files changed, 1231 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-dwc.txt
 create mode 100644 drivers/scsi/ufs/ufs-dwc-pci.c
 create mode 100644 drivers/scsi/ufs/ufs-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.c
 create mode 100644 drivers/scsi/ufs/ufshcd-dwc.h
 create mode 100644 drivers/scsi/ufs/ufshci-dwc.h

diff --git a/Documentation/devicetree/bindings/ufs/ufs-dwc.txt 
b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
new file mode 100644
index 000..f38a3f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
@@ -0,0 +1,17 @@
+* Universal Flash Storage (UFS) DesignWare Host Controller
+
+DWC_UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible: compatible string ("snps,ufshcd-1.0", "snps,ufshcd-1.1"
+  or "snps,ufshcd-2.0")
+- reg   : 
+- interrupts: 
+
+Example:
+   dwc_ufshcd@0xD000 {
+   compatible = "snps,ufshcd-2.0";
+   reg = < 0xD000 0x1 >;
+   interrupts = < 24 >;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index d2f94e2..3db3c4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11006,6 +11006,12 @@ S: Supported
 F: Documentation/scsi/ufs.txt
 F: drivers/scsi/ufs/
 
+UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS
+M: Joao Pinto 
+L: linux-scsi@vger.kernel.org
+S: Supported
+F: drivers/scsi/ufs/*dwc*
+
 UNSORTED BLOCK IMAGES (UBI)
 M: Artem Bityutskiy 
 M: Richard Weinberger 
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5f45307..b4c353c 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,44 @@ config SCSI_UFS_QCOM
 
  Select this if you have UFS controller on QCOM chipset.
  If unsure, say N.
+
+config SCSI_UFS_DWC_HOOKS
+   bool
+
+config SCSI_UFS_DWC_PLAT
+   tristate "DesignWare UFS controller platform glue driver"
+   depends on SCSI_UFSHCD_PLATFORM
+   select SCSI_UFS_DWC_HOOKS
+   help
+ This selects the DesignWare UFS host controller platform glue driver.
+
+ Select this if you have a DesignWare UFS controller on Platform bus.
+ If unsure, say N.
+
+config SCSI_UFS_DWC_PCI
+   tristate "DesignWare UFS controller pci glue driver"
+   depends on SCSI_UFSHCD_PCI
+   select SCSI_UFS_DWC_HOOKS
+   help
+ This selects the DesignWare UFS host controller pci glue driver.
+
+ Select this if you have a DesignWare UFS controller on 

[PATCH v6 1/2] fixed typo in ufshcd-pltfrm

2016-02-10 Thread Joao Pinto
Fixed typo in ufshcd-pltfrm.

Signed-off-by: Joao Pinto 
---
Changes v0->v6:
- Nothing changed (just to keep up with patch set version).

 drivers/scsi/ufs/ufshcd-pltfrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index d2a7b12..0522891 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -353,6 +353,6 @@ EXPORT_SYMBOL_GPL(ufshcd_pltfrm_init);
 
 MODULE_AUTHOR("Santosh Yaragnavi ");
 MODULE_AUTHOR("Vinayak Holikatti ");
-MODULE_DESCRIPTION("UFS host controller Pltform bus based glue driver");
+MODULE_DESCRIPTION("UFS host controller Platform bus based glue driver");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(UFSHCD_DRIVER_VERSION);
-- 
1.8.1.5

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


Re: [RFC PATCH v2] blk-mq: Introduce per sw queue time-slice

2016-02-10 Thread Markus Trippelsdorf
On 2016.02.10 at 20:34 +0100, Andreas Herrmann wrote:
> On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> > > Recently Johannes sent a patch to enable scsi-mq per driver, see
> > > http://marc.info/?l=linux-scsi=145347009631192=2
> > > 
> > > Probably that is a good solution (at least in the short term) to allow
> > > users to switch to blk-mq for some host adapters (with fast storage
> > > attached) but to stick to legacy stuff on other host adapters with
> > > rotary devices.
> > 
> > I don't think that Johannes' patch is a good solution.
> 
> Why? Because it's not per device?

Yes. Like Christoph said in his reply to the patch: »The host is simply
the wrong place to decide these things.«

> > The best solution for the user would be if blk-mq could be toggled
> > per drive (or even automatically enabled if queue/rotational == 0).
> 
> Yes, I aggree, but ...
> 
> > Is there a fundamental reason why this is not feasible?
> 
> ... it's not possible (*) with the current implementation.
> 
> Tag handling/command allocation differs. Respective functions are set
> per host.
> 
> (*) Or maybe it's possible but just hard to achieve and I didn't look
> long enough into relevant code to get an idea how to do it.
> 
> > Your solution is better than nothing, but it requires that the user
> > finds out the drive <=> host mapping by hand and then runs something
> > like: 
> > echo "250" > 
> > /sys/devices/pci:00/:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb/mq/0/time_slice_us
> > during boot for spinning rust drives...
> 
> Or it could automatically be set in case of rotational device.
> (Once we know for sure that it doesn't cause performance degradation.)

Yes, this sound like a good idea.

But, if I understand things correctly, your patch is only an interim
solution until proper I/O scheduler support gets implemented for blk-mq, no?

-- 
Markus
--
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 PATCH v2] blk-mq: Introduce per sw queue time-slice

2016-02-10 Thread Andreas Herrmann
On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> On 2016.02.09 at 18:12 +0100, Andreas Herrmann wrote:
> > [CC-ing linux-block and linux-scsi and adding some comments]
> > 
> > On Mon, Feb 01, 2016 at 11:43:40PM +0100, Andreas Herrmann wrote:
> > > This introduces a new blk_mq hw attribute time_slice_us which allows
> > > to specify a time slice in usecs.
> > > 
> > > Fio test results are sent in a separate mail to this.
> > 
> > See http://marc.info/?l=linux-kernel=145436682607949=2
> > 
> > In short it shows significant performance gains in some tests,
> > e.g. sequential read iops up by >40% with 8 jobs. But it's never on
> > par with CFQ when more than 1 job was used during the test.
> > 
> > > Results for fio improved to some extent with this patch. But in
> > > reality the picture is quite mixed. Performance is highly dependend on
> > > task scheduling. There is no guarantee that the requests originated
> > > from one CPU belong to the same process.
> > > 
> > > I think for rotary devices CFQ is by far the best choice. A simple
> > > illustration is:
> > > 
> > >   Copying two files (750MB in this case) in parallel on a rotary
> > >   device. The elapsed wall clock time (seconds) for this is
> > >meanstdev
> > >cfq, slice_idle=8   16.18   4.95
> > >cfq, slice_idle=0   23.74   2.82
> > >blk-mq, time_slice_usec=0   24.37   2.05
> > >blk-mq, time_slice_usec=250 25.58   3.16
> > 
> > This illustrates that although their was performance gain with fio
> > tests, the patch can cause higher variance and lower performance in
> > comparison to unmodified blk-mq with other tests. And it underscores
> > superiority of CFQ for rotary disks.
> > 
> > Meanwhile my opinion is that it's not really worth to look further
> > into introduction of I/O scheduling support in blk-mq. I don't see the
> > need for scheduling support (deadline or something else) for fast
> > storage devices. And rotary devices should really avoid usage of blk-mq
> > and stick to CFQ.
> > 
> > Thus I think that introducing some coexistence of blk-mq and the
> > legacy block with CFQ is the best option.
> > 
> > Recently Johannes sent a patch to enable scsi-mq per driver, see
> > http://marc.info/?l=linux-scsi=145347009631192=2
> > 
> > Probably that is a good solution (at least in the short term) to allow
> > users to switch to blk-mq for some host adapters (with fast storage
> > attached) but to stick to legacy stuff on other host adapters with
> > rotary devices.
> 
> I don't think that Johannes' patch is a good solution.

Why? Because it's not per device?

> The best solution for the user would be if blk-mq could be toggled
> per drive (or even automatically enabled if queue/rotational == 0).

Yes, I aggree, but ...

> Is there a fundamental reason why this is not feasible?

... it's not possible (*) with the current implementation.

Tag handling/command allocation differs. Respective functions are set
per host.

(*) Or maybe it's possible but just hard to achieve and I didn't look
long enough into relevant code to get an idea how to do it.

> Your solution is better than nothing, but it requires that the user
> finds out the drive <=> host mapping by hand and then runs something
> like: 
> echo "250" > 
> /sys/devices/pci:00/:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb/mq/0/time_slice_us
> during boot for spinning rust drives...

Or it could automatically be set in case of rotational device.
(Once we know for sure that it doesn't cause performance degradation.)

> -- 
> Markus

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


RE: [PATCH v2] megaraid_sas: add an i/o barrier

2016-02-10 Thread Kashyap Desai
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Wednesday, February 10, 2016 10:55 PM
> To: Tomas Henzl
> Cc: 'linux-scsi@vger.kernel.org'; sumit.sax...@avagotech.com; Desai,
> Kashyap; Uday Lingala; sta...@vger.kernel.org
> Subject: Re: [PATCH v2] megaraid_sas: add an i/o barrier
>
> > "Tomas" == Tomas Henzl  writes:
>
> Tomas> A barrier should be added to ensure proper ordering of memory
> Tomas> mapped writes.
>
> Tomas> V2: - added the barrier also to megasas_fire_cmd_skinny, as
> Tomas> suggested by Kashyap Desai

Reviewed-by: Kashyap Desai 
Acked-by: Kashyap Desai 

>
> Sumit, Kashyap: Please review this patch.
>
> --
> Martin K. PetersenOracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 2/2] add support for DWC UFS Host Controller

2016-02-10 Thread Arnd Bergmann
On Wednesday 10 February 2016 16:06:13 Joao Pinto wrote:
> This patch has the goal to add support for DesignWare UFS Controller
> specific operations and to add specific platform and pci drivers.
> 
> Signed-off-by: Joao Pinto 
>  Documentation/devicetree/bindings/ufs/ufs-dwc.txt |  17 +
>  MAINTAINERS   |   6 +
>  drivers/scsi/ufs/Kconfig  |  41 ++
>  drivers/scsi/ufs/Makefile |   3 +
>  drivers/scsi/ufs/ufs-dwc-pci.c| 180 ++
>  drivers/scsi/ufs/ufs-dwc.c| 102 +++
>  drivers/scsi/ufs/ufshcd-dwc.c | 736 
> ++
>  drivers/scsi/ufs/ufshcd-dwc.h |  18 +
>  drivers/scsi/ufs/ufshcd.c |  50 +-
>  drivers/scsi/ufs/ufshcd.h |  13 +
>  drivers/scsi/ufs/ufshci-dwc.h |  42 ++
>  drivers/scsi/ufs/ufshci.h |   1 +
>  drivers/scsi/ufs/unipro.h |  39 ++

Can you split this into separate patches for changes to the common code,
the addition of the PCI driver and the addition of the platform driver?

> diff --git a/Documentation/devicetree/bindings/ufs/ufs-dwc.txt 
> b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
> new file mode 100644
> index 000..f38a3f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-dwc.txt
> @@ -0,0 +1,17 @@
> +* Universal Flash Storage (UFS) DesignWare Host Controller
> +
> +DWC_UFSHC nodes are defined to describe on-chip UFS host controllers.
> +Each UFS controller instance should have its own node.
> +
> +Required properties:
> +- compatible: compatible string ("snps,ufshcd-1.0", "snps,ufshcd-1.1"
> +  or "snps,ufshcd-2.0")
> +- reg   : 
> +- interrupts: 
> +
> +Example:
> + dwc_ufshcd@0xD000 {

Please fix the node name and address in the example. I think you want 
"ufs@d000".

> +config SCSI_UFS_DWC_MPHY_TC
> + bool "Support for the Synopsys MPHY Test Chip"
> + depends on SCSI_UFS_DWC_HOOKS && (SCSI_UFSHCD_PCI || SCSI_UFS_DWC_PLAT)
> + ---help---
> +   This selects the support for the Synopsys MPHY Test Chip.
> +
> +   Select this if you have a Synopsys MPHY Test Chip.
> +   If unsure, say N.
> +
> +config SCSI_UFS_DWC_40BIT_RMMI
> + bool "40-bit RMMI MPHY"
> + depends on SCSI_UFS_DWC_MPHY_TC
> + ---help---
> +   This specifies that the Synopsys MPHY supports 40-bit RMMI operations.
> +
> +   Select this if you are using a 40-bit RMMI Synopsys MPHY.

I don't think I understood you explanation why this has to be here,
rather than using a proper PHY driver. Please try again.

> +
> +#ifdef CONFIG_PM
> +/**
> + * ufs_dw_pci_suspend - suspend power management function
> + * @pdev: pointer to PCI device handle
> + * @state: power state
> + *
> + * Returns 0 if successful
> + * Returns non-zero otherwise
> + */
> +static int ufs_dw_pci_suspend(struct device *dev)
> +{
> + return ufshcd_system_suspend(dev_get_drvdata(dev));
> +}

Please remove the #ifdef here.

> +
> +static const struct dev_pm_ops ufs_dw_pci_pm_ops = {
> + .suspend= ufs_dw_pci_suspend,
> + .resume = ufs_dw_pci_resume,
> + .runtime_suspend = ufs_dw_pci_runtime_suspend,
> + .runtime_resume  = ufs_dw_pci_runtime_resume,
> + .runtime_idle= ufs_dw_pci_runtime_idle,
> +};

Instead, use the macros from include/linux/pm.h

> +#ifdef CONFIG_SCSI_UFS_DWC_40BIT_RMMI
> +/**
> + * ufshcd_dwc_setup_40bit_rmmi()
> + * This function configures Synopsys MPHY specific atributes (40-bit RMMI)
> + * @hba: Pointer to drivers structure
> + *
> + * Returns 0 on success or non-zero value on failure
> + */
> +static int ufshcd_dwc_setup_40bit_rmmi(struct ufs_hba *hba)
> +{
> + int ret = 0;

This looks like it should go into the external driver

> +
> +#ifdef CONFIG_SCSI_UFS_DWC_40BIT_RMMI
> + dev_info(hba->dev, "Configuring MPHY 40-bit RMMI");
> + ret = ufshcd_dwc_setup_40bit_rmmi(hba);
> + if (ret) {
> + dev_err(hba->dev, "40-bit RMMI configuration failed");
> + goto out;
> + }
> +#else
> + dev_info(hba->dev, "Configuring MPHY 20-bit RMMI");
> + ret = ufshcd_dwc_setup_20bit_rmmi(hba);
> + if (ret) {
> + dev_err(hba->dev, "20-bit RMMI configuration failed");
> + goto out;
> + }
> +#endif

In particular, the part above cannot possibly work: When a distro ships a kernel
with CONFIG_SCSI_UFS_DWC_40BIT_RMMI set, it won't ever call the 
ufshcd_dwc_setup_20bit_rmmi() function, regardless of what the hardware is.

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: [RFC PATCH v2] blk-mq: Introduce per sw queue time-slice

2016-02-10 Thread Andreas Herrmann
On Wed, Feb 10, 2016 at 08:47:15PM +0100, Markus Trippelsdorf wrote:
> On 2016.02.10 at 20:34 +0100, Andreas Herrmann wrote:
> > On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> > > > Recently Johannes sent a patch to enable scsi-mq per driver, see
> > > > http://marc.info/?l=linux-scsi=145347009631192=2
> > > > 
> > > > Probably that is a good solution (at least in the short term) to allow
> > > > users to switch to blk-mq for some host adapters (with fast storage
> > > > attached) but to stick to legacy stuff on other host adapters with
> > > > rotary devices.
> > > 
> > > I don't think that Johannes' patch is a good solution.
> > 
> > Why? Because it's not per device?
> 
> Yes. Like Christoph said in his reply to the patch: »The host is simply
> the wrong place to decide these things.«
> 
> > > The best solution for the user would be if blk-mq could be toggled
> > > per drive (or even automatically enabled if queue/rotational == 0).
> > 
> > Yes, I aggree, but ...
> > 
> > > Is there a fundamental reason why this is not feasible?
> > 
> > ... it's not possible (*) with the current implementation.
> > 
> > Tag handling/command allocation differs. Respective functions are set
> > per host.
> > 
> > (*) Or maybe it's possible but just hard to achieve and I didn't look
> > long enough into relevant code to get an idea how to do it.
> > 
> > > Your solution is better than nothing, but it requires that the user
> > > finds out the drive <=> host mapping by hand and then runs something
> > > like: 
> > > echo "250" > 
> > > /sys/devices/pci:00/:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb/mq/0/time_slice_us
> > > during boot for spinning rust drives...
> > 
> > Or it could automatically be set in case of rotational device.
> > (Once we know for sure that it doesn't cause performance degradation.)
> 
> Yes, this sound like a good idea.
> 
> But, if I understand things correctly, your patch is only an interim
> solution until proper I/O scheduler support gets implemented for blk-mq, no?

That's to be discussed. (Hence the RFC)

My (potentially wrong) claims are

- I don't think that fast storage (e.g. SSDs) requires I/O scheduler
  support with blk-mq. blk-mq is very good at pushing a large number
  of requests from per CPU sw queues to hw queue(s). Why then
  introduce any overhead for I/O scheduler support?

- Slow storage (e.g. spinning drives) is fine with the old code which
  provides scheduler support and I doubt that there is any benefit for
  those devices when switching to blk-mq.

- The big hammer (scsi_mod.use_blk_mq) for the entire scsi stack to
  decide what to use is suboptimal. You can't have optimal performance
  when you have both slow and fast storage devices in your system.

I doubt that it is possible to add I/O scheduling support to blk-mq
which can be on par with what CFQ is able to achieve for slow devices
at the moment.

Requests are scattered among per-CPU software queues (and almost
instantly passed to hardware queue(s)). Due to CPU scheduling,
requests initiated from one process might come down via different
software queues. What is an efficient way to sort/merge requests from
all the software queues in such a way that the result is comparable to
what CFQ does (assuming that CFQ provides optimal performance)? So far
I didn't find a solution to this problem. (I just have this patch
which adds not too much overhead and improves the situation a little
bit.)

Maybe the solution is to avoid per-CPU queues for slow storage and
fall back to a set of queues comparable to what CFQ uses.

One way to do this is by falling back to non-blk-mq code and direct
use of CFQ.

Code that allows to select blk-mq per host would help to some
extent. But when you have both device types connected to the same host
adapter it doesn't help either.


Andreas
--
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] qla2xxx: use TARGET_SCF_USE_CPUID flag to indiate CPU Affinity

2016-02-10 Thread Himanshu Madhani
From: Quinn Tran 

Signed-off-by: Quinn Tran 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Bart Van Assche 
Fixes: fb3269b ("qla2xxx: Add selective command queuing")
Signed-off-by: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_target.c  |4 ++--
 drivers/scsi/qla2xxx/tcm_qla2xxx.c |3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index 49a421a..9852319 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -4013,7 +4013,8 @@ static int qlt_handle_cmd_for_atio(struct scsi_qla_host 
*vha,
 
cmd->cmd_in_wq = 1;
cmd->cmd_flags |= BIT_0;
-   cmd->se_cmd.cpuid = -1;
+   cmd->se_cmd.cpuid = ha->msix_count ?
+   ha->tgt.rspq_vector_cpuid : WORK_CPU_UNBOUND;
 
spin_lock(>cmd_list_lock);
list_add_tail(>cmd_list, >qla_cmd_list);
@@ -4021,7 +4022,6 @@ static int qlt_handle_cmd_for_atio(struct scsi_qla_host 
*vha,
 
INIT_WORK(>work, qlt_do_work);
if (ha->msix_count) {
-   cmd->se_cmd.cpuid = ha->tgt.rspq_vector_cpuid;
if (cmd->atio.u.isp24.fcp_cmnd.rddata)
queue_work_on(smp_processor_id(), qla_tgt_wq,
>work);
diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c 
b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
index 7c8e255..c1461d2 100644
--- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
+++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
@@ -462,6 +462,9 @@ static int tcm_qla2xxx_handle_cmd(scsi_qla_host_t *vha, 
struct qla_tgt_cmd *cmd,
if (bidi)
flags |= TARGET_SCF_BIDI_OP;
 
+   if (se_cmd->cpuid != WORK_CPU_UNBOUND)
+   flags |= TARGET_SCF_USE_CPUID;
+
sess = cmd->sess;
if (!sess) {
pr_err("Unable to locate struct qla_tgt_sess from 
qla_tgt_cmd\n");
-- 
1.7.7

--
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] qla2xxx: Fixes for target-pending

2016-02-10 Thread Himanshu Madhani
Hi Nic, 

Here are the patches that addresses review comments from Bart
and Christoph. See email threads

 http://www.spinics.net/lists/target-devel/msg11418.html
 http://www.spinics.net/lists/target-devel/msg11419.html

Please apply these patches to target-pending.

Thanks,
Himanshu

Quinn Tran (2):
  target/transport: add flag to indicate CPU Affinity is observed
  qla2xxx: use TARGET_SCF_USE_CPUID flag to indiate CPU Affinity

 drivers/scsi/qla2xxx/qla_target.c  |4 ++--
 drivers/scsi/qla2xxx/tcm_qla2xxx.c |3 +++
 drivers/target/target_core_transport.c |   12 +---
 include/target/target_core_base.h  |2 ++
 4 files changed, 16 insertions(+), 5 deletions(-)

-- 
1.7.7

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


[PATCH 1/2] target/transport: add flag to indicate CPU Affinity is observed

2016-02-10 Thread Himanshu Madhani
From: Quinn Tran 

Signed-off-by: Quinn Tran 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Bart Van Assche 
Fixes: fb3269b ("qla2xxx: Add selective command queuing")
Signed-off-by: Himanshu Madhani 
---
 drivers/target/target_core_transport.c |   12 +---
 include/target/target_core_base.h  |2 ++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/target/target_core_transport.c 
b/drivers/target/target_core_transport.c
index 3e6a98b..6348ae0 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -776,10 +776,10 @@ void target_complete_cmd(struct se_cmd *cmd, u8 
scsi_status)
cmd->transport_state |= (CMD_T_COMPLETE | CMD_T_ACTIVE);
spin_unlock_irqrestore(>t_state_lock, flags);
 
-   if (cmd->cpuid == -1)
-   queue_work(target_completion_wq, >work);
-   else
+   if (cmd->se_cmd_flags & SCF_USE_CPUID)
queue_work_on(cmd->cpuid, target_completion_wq, >work);
+   else
+   queue_work(target_completion_wq, >work);
 }
 EXPORT_SYMBOL(target_complete_cmd);
 
@@ -1491,6 +1491,12 @@ int target_submit_cmd_map_sgls(struct se_cmd *se_cmd, 
struct se_session *se_sess
 */
transport_init_se_cmd(se_cmd, se_tpg->se_tpg_tfo, se_sess,
data_length, data_dir, task_attr, sense);
+
+   if (flags & TARGET_SCF_USE_CPUID)
+   se_cmd->se_cmd_flags |= SCF_USE_CPUID;
+   else
+   se_cmd->cpuid = WORK_CPU_UNBOUND;
+
if (flags & TARGET_SCF_UNKNOWN_SIZE)
se_cmd->unknown_data_length = 1;
/*
diff --git a/include/target/target_core_base.h 
b/include/target/target_core_base.h
index d71a3ea..e8c8c08 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -141,6 +141,7 @@ enum se_cmd_flags_table {
SCF_COMPARE_AND_WRITE_POST  = 0x0010,
SCF_PASSTHROUGH_PROT_SG_TO_MEM_NOALLOC = 0x0020,
SCF_ACK_KREF= 0x0040,
+   SCF_USE_CPUID   = 0x0080,
 };
 
 /* struct se_dev_entry->lun_flags and struct se_lun->lun_access */
@@ -188,6 +189,7 @@ enum target_sc_flags_table {
TARGET_SCF_BIDI_OP  = 0x01,
TARGET_SCF_ACK_KREF = 0x02,
TARGET_SCF_UNKNOWN_SIZE = 0x04,
+   TARGET_SCF_USE_CPUID= 0x08,
 };
 
 /* fabric independent task management function values */
-- 
1.7.7

--
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/2] qla2xxx: Fixes for target-pending

2016-02-10 Thread Nicholas A. Bellinger
On Wed, 2016-02-10 at 18:59 -0500, Himanshu Madhani wrote:
> Hi Nic, 
> 
> Here are the patches that addresses review comments from Bart
> and Christoph. See email threads
> 
>  http://www.spinics.net/lists/target-devel/msg11418.html
>  http://www.spinics.net/lists/target-devel/msg11419.html
> 
> Please apply these patches to target-pending.
> 
> Thanks,
> Himanshu
> 
> Quinn Tran (2):
>   target/transport: add flag to indicate CPU Affinity is observed
>   qla2xxx: use TARGET_SCF_USE_CPUID flag to indiate CPU Affinity
> 
>  drivers/scsi/qla2xxx/qla_target.c  |4 ++--
>  drivers/scsi/qla2xxx/tcm_qla2xxx.c |3 +++
>  drivers/target/target_core_transport.c |   12 +---
>  include/target/target_core_base.h  |2 ++
>  4 files changed, 16 insertions(+), 5 deletions(-)
> 

Applied to target-pending/master.

Thanks Himanshu & Quinn!

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


Business Partnership

2016-02-10 Thread EYADEMA
Hello,

I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached 
proposal.
Thanks in anticipation of your urgent response,


LAURENT EYADEMA

proposal.docx
Description: Binary data


[PATCH RESEND] scsi: sim710: fix build warning

2016-02-10 Thread Sudip Mukherjee
We are getting build warning about:
 "Section mismatch in reference from the variable sim710_eisa_driver to
 the function .init.text:sim710_eisa_probe()
 The variable sim710_eisa_driver references the function __init
 sim710_eisa_probe()"

sim710_eisa_probe() was having __init but that was being referenced from
sim710_eisa_driver.

Signed-off-by: Sudip Mukherjee 
---

patch first sent on 4th Sept.2015. There is no review or ACK yet.
warning is still there with next-20160209,
build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/107948115

 drivers/scsi/sim710.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/sim710.c b/drivers/scsi/sim710.c
index 3b3b56f..82ed998 100644
--- a/drivers/scsi/sim710.c
+++ b/drivers/scsi/sim710.c
@@ -176,8 +176,7 @@ static struct eisa_device_id sim710_eisa_ids[] = {
 };
 MODULE_DEVICE_TABLE(eisa, sim710_eisa_ids);
 
-static __init int
-sim710_eisa_probe(struct device *dev)
+static int sim710_eisa_probe(struct device *dev)
 {
struct eisa_device *edev = to_eisa_device(dev);
unsigned long io_addr = edev->base_addr;
-- 
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


[PATCH] target: Fix incorrect unmap_zeroes_data_store return

2016-02-10 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

This patch fixes an incorrect return of zero from the new
unmap_zeroes_data_store() configfs store attribute handler
introduced in v4.5-rc1, to use the correct 'count' bytes
return value.

Signed-off-by: Nicholas Bellinger 
---
 drivers/target/target_core_configfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/target_core_configfs.c 
b/drivers/target/target_core_configfs.c
index 3327c49..713c63d9 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -898,7 +898,7 @@ static ssize_t unmap_zeroes_data_store(struct config_item 
*item,
da->unmap_zeroes_data = flag;
pr_debug("dev[%p]: SE Device Thin Provisioning LBPRZ bit: %d\n",
 da->da_dev, flag);
-   return 0;
+   return count;
 }
 
 /*
-- 
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


Re: [PATCH-v4 0/5] Fix LUN_RESET active I/O + TMR handling

2016-02-10 Thread Nicholas A. Bellinger
Hi Himanshu & Co,

On Tue, 2016-02-09 at 18:03 +, Himanshu Madhani wrote:
> Hi Nic, 
> 
> 
> On 2/8/16, 9:25 PM, "Nicholas A. Bellinger"  wrote:
> 
> >Hi Himanshu,
> >
> >On Mon, 2016-02-08 at 23:27 +, Himanshu Madhani wrote:
> >> 
> >> I am testing this series with with 4.5.0-rc2+ kernel and I am seeing
> >>issue
> >> where trying to trigger
> >> sg_reset with option of host/device/bus in loop at 120second interval
> >> causes call stack. At this point
> >> removing configuration hangs indefinitely. See attached dmesg output
> >>from
> >> my setup. 
> >> 
> >
> >Thanks alot for testing this.
> >
> >So It looks like we're still hitting a indefinite schedule() on
> >se_cmd->cmd_wait_comp once tcm_qla2xxx session disconnect/reconnect
> >occurs, after repeated explicit active I/O remote-port sg_resets.
> >
> >Does this trigger on the first tcm_qla2xxx session reconnect after
> >explicit remote-port sg_reset..?  Are session reconnects actively being
> >triggered during the test..?
> >
> >To verify the latter for iscsi-target, I've been using a small patch to
> >trigger session reset from TMR kthread context in order to simulate the
> >I_T disconnects.  Something like that would be useful for verifying with
> >tcm_qla2xxx too.
> >
> >That said, I'll be reproducing with tcm_qla2xxx ports this week, and
> >will enable various debug in a WIP branch for testing.

Following up here..

So far using my test setup with ISP2532 ports in P2P + RAMDISK_MCP and
v4.5-rc1, repeated remote-port active I/O LUN_RESET (sg_reset -d) has
been functioning as expected with a blocksize_range=4k-256k + iodepth=32
fio write-verify style workload.

No ->cmd_kref -1 OOPsen or qla2xxx initiator generated ABORT_TASKs from
outstanding target TAS responses, nor fio write-verify failures to
report after 800x remote-port active I/O LUN_RESETS.

Next step will be to verify explicit tcm_qla2xxx port + module shutdown
after 1K test iterations, and then IBLOCK async completions <-> NVMe
backends with the same case.

> Let me know if I can help in any way for testing/validating this series.
> 

Thanks.  :)

So based on your original log, it's still unclear clear if the session
reset resulting in se_cmd->cmd_wait_comp indefinite sleep + ->cmd_kref
leak is happen concurrently with repeated remote port LUN_RESET, or the
session reset -> target_wait_for_sess_cmds() occurs after active I/O has
already completed..?  Please confirm.

To that end, target-pending/debug-for-himanshu has been pushed to enable
extra debug for test, please update.

Also, you'll want to enable microsecond ring buffer timestamps in your
kernel build too, as it's very useful for type this debugging.

Thank you,

--nab

--
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 RESEND] scsi: ppa: use new parport device model

2016-02-10 Thread Sudip Mukherjee
Modify ppa driver to use the new parallel port device model.

Signed-off-by: Sudip Mukherjee 
---

Resending as there was no review or ACK for this change.
This has exactly same changes as done in scsi/imm.c which has already
been accepted.

 drivers/scsi/ppa.c | 46 --
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/ppa.c b/drivers/scsi/ppa.c
index ee00e27..f6ad579 100644
--- a/drivers/scsi/ppa.c
+++ b/drivers/scsi/ppa.c
@@ -37,6 +37,7 @@ typedef struct {
unsigned long recon_tmo;/* How many usecs to wait for 
reconnection (6th bit) */
unsigned int failed:1;  /* Failure flag */
unsigned wanted:1;  /* Parport sharing busy flag*/
+   unsigned int dev_no;/* Device number*/
wait_queue_head_t *waiting;
struct Scsi_Host *host;
struct list_head list;
@@ -985,15 +986,40 @@ static struct scsi_host_template ppa_template = {
 
 static LIST_HEAD(ppa_hosts);
 
+/*
+ * Finds the first available device number that can be alloted to the
+ * new ppa device and returns the address of the previous node so that
+ * we can add to the tail and have a list in the ascending order.
+ */
+
+static inline ppa_struct *find_parent(void)
+{
+   ppa_struct *dev, *par = NULL;
+   unsigned int cnt = 0;
+
+   if (list_empty(_hosts))
+   return NULL;
+
+   list_for_each_entry(dev, _hosts, list) {
+   if (dev->dev_no != cnt)
+   return par;
+   cnt++;
+   par = dev;
+   }
+
+   return par;
+}
+
 static int __ppa_attach(struct parport *pb)
 {
struct Scsi_Host *host;
DECLARE_WAIT_QUEUE_HEAD_ONSTACK(waiting);
DEFINE_WAIT(wait);
-   ppa_struct *dev;
+   ppa_struct *dev, *temp;
int ports;
int modes, ppb, ppb_hi;
int err = -ENOMEM;
+   struct pardev_cb ppa_cb;
 
dev = kzalloc(sizeof(ppa_struct), GFP_KERNEL);
if (!dev)
@@ -1002,8 +1028,15 @@ static int __ppa_attach(struct parport *pb)
dev->mode = PPA_AUTODETECT;
dev->recon_tmo = PPA_RECON_TMO;
init_waitqueue_head();
-   dev->dev = parport_register_device(pb, "ppa", NULL, ppa_wakeup,
-   NULL, 0, dev);
+   temp = find_parent();
+   if (temp)
+   dev->dev_no = temp->dev_no + 1;
+
+   memset(_cb, 0, sizeof(ppa_cb));
+   ppa_cb.private = dev;
+   ppa_cb.wakeup = ppa_wakeup;
+
+   dev->dev = parport_register_dev_model(pb, "ppa", _cb, dev->dev_no);
 
if (!dev->dev)
goto out;
@@ -1110,9 +1143,10 @@ static void ppa_detach(struct parport *pb)
 }
 
 static struct parport_driver ppa_driver = {
-   .name   = "ppa",
-   .attach = ppa_attach,
-   .detach = ppa_detach,
+   .name   = "ppa",
+   .match_port = ppa_attach,
+   .detach = ppa_detach,
+   .devmodel   = true,
 };
 
 static int __init ppa_driver_init(void)
-- 
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


Business Partnership

2016-02-10 Thread EYADEMA
Hello,

I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached 
proposal.
Thanks in anticipation of your urgent response,


LAURENT EYADEMA

proposal.docx
Description: Binary data


Re: [PATCH] lpfc: Remove redundant code block in lpfc_scsi_cmd_iocb_cmpl

2016-02-10 Thread Martin K. Petersen
> "Johannes" == Johannes Thumshirn  writes:

Johannes> This removes a redundant code block that will either be
Johannes> executed if the ENABLE_FCP_RING_POLLING flag is set in
Johannes> phba->cfg_poll or not. The code is just duplicated in both
Johannes> cases, hence we unify it again.

Johannes> This probably is a left over from some sort of refactoring.

Applied to 4.6/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] megaraid_sas: add an i/o barrier

2016-02-10 Thread Martin K. Petersen
> "Tomas" == Tomas Henzl  writes:

Tomas> A barrier should be added to ensure proper ordering of memory
Tomas> mapped writes.

Applied to 4.6/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/7] SCSI bug fixes for 4.6

2016-02-10 Thread Martin K. Petersen
> "Arnd" == Arnd Bergmann  writes:

Arnd> Here are a bunch of fixes for harmless bugs I found during ARM
Arnd> randconfig testing. It would be nice to get them mered in 4.6, but
Arnd> there is no need to have them in 4.5 as no incorrect behavior
Arnd> results from the current code, and the warnings are all hard to
Arnd> trigger.

Applied to 4.6/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


[PATCH v2 0/7] ibmvscsi code cleanup

2016-02-10 Thread Tyrel Datwyler
Fixed up a couple spots that were out of line with the PAPR in regards
to its defined VSCSI protocol. Did away with some magic numbers directly
in the code. Fixed a minor endian issue.

--

v2 changes:

-Renamed CRQ header enums and added enums for INIT formats
-Check that crq->valid != VIOSRP_CRQ_FREE before handling in place
of hacky bitwise & to check for first bit being set.
-Added define for AIX os_type
-Left sysfs config attribute to prevent breaking userspace

Tyrel Datwyler (7):
  ibmvscsi: Correct values for several viosrp_crq_format enums
  ibmvscsi: Add and use enums for valid CRQ header values
  ibmvscsi: Replace magic values in set_adpater_info() with defines
  ibmvscsi: Use of_root to access OF device tree root node
  ibmvscsi: Remove unsupported host config MAD
  ibmvscsi: Add endian conversions to sysfs attribute show functions
  ibmvscsi: use H_CLOSED instead of magic number

 drivers/scsi/ibmvscsi/ibmvscsi.c | 128 ++-
 drivers/scsi/ibmvscsi/viosrp.h   |  26 +---
 2 files changed, 49 insertions(+), 105 deletions(-)

-- 
2.5.0

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


[PATCH v2 4/7] ibmvscsi: Use of_root to access OF device tree root node

2016-02-10 Thread Tyrel Datwyler
The root node of the OF device tree is exported as of_root. No need
to look up the root by path name. Instead just get a reference
directly via of_root.

Signed-off-by: Tyrel Datwyler 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/ibmvscsi/ibmvscsi.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index 4b09a9b..c208295 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -248,25 +248,23 @@ static void ibmvscsi_task(void *data)
 
 static void gather_partition_info(void)
 {
-   struct device_node *rootdn;
-
const char *ppartition_name;
const __be32 *p_number_ptr;
 
/* Retrieve information about this partition */
-   rootdn = of_find_node_by_path("/");
-   if (!rootdn) {
+   if (!of_root)
return;
-   }
 
-   ppartition_name = of_get_property(rootdn, "ibm,partition-name", NULL);
+   of_node_get(of_root);
+
+   ppartition_name = of_get_property(of_root, "ibm,partition-name", NULL);
if (ppartition_name)
strncpy(partition_name, ppartition_name,
sizeof(partition_name));
-   p_number_ptr = of_get_property(rootdn, "ibm,partition-no", NULL);
+   p_number_ptr = of_get_property(of_root, "ibm,partition-no", NULL);
if (p_number_ptr)
partition_number = of_read_number(p_number_ptr, 1);
-   of_node_put(rootdn);
+   of_node_put(of_root);
 }
 
 static void set_adapter_info(struct ibmvscsi_host_data *hostdata)
-- 
2.5.0

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


[PATCH v2 6/7] ibmvscsi: Add endian conversions to sysfs attribute show functions

2016-02-10 Thread Tyrel Datwyler
The values returned by the show functions for the host os_type,
mad_version, and partition_number attributes get their values
directly from the madapter_info struct whose associated fields are
__be32 typed. Added endian conversion to ensure these values are
sane on LE platforms.

Signed-off-by: Tyrel Datwyler 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/ibmvscsi/ibmvscsi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index e8d4af5..6025481 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -1983,7 +1983,7 @@ static ssize_t show_host_partition_number(struct device 
*dev,
int len;
 
len = snprintf(buf, PAGE_SIZE, "%d\n",
-  hostdata->madapter_info.partition_number);
+  be32_to_cpu(hostdata->madapter_info.partition_number));
return len;
 }
 
@@ -2003,7 +2003,7 @@ static ssize_t show_host_mad_version(struct device *dev,
int len;
 
len = snprintf(buf, PAGE_SIZE, "%d\n",
-  hostdata->madapter_info.mad_version);
+  be32_to_cpu(hostdata->madapter_info.mad_version));
return len;
 }
 
@@ -2022,7 +2022,8 @@ static ssize_t show_host_os_type(struct device *dev,
struct ibmvscsi_host_data *hostdata = shost_priv(shost);
int len;
 
-   len = snprintf(buf, PAGE_SIZE, "%d\n", hostdata->madapter_info.os_type);
+   len = snprintf(buf, PAGE_SIZE, "%d\n",
+  be32_to_cpu(hostdata->madapter_info.os_type));
return len;
 }
 
-- 
2.5.0

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


[PATCH v2 7/7] ibmvscsi: use H_CLOSED instead of magic number

2016-02-10 Thread Tyrel Datwyler
In a couple places the magic value of 2 is used to check the return
code of hypercalls. This translates to H_CLOSED.

Signed-off-by: Tyrel Datwyler 
---
 drivers/scsi/ibmvscsi/ibmvscsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index 6025481..d9534ee 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -314,7 +314,7 @@ static int ibmvscsi_reset_crq_queue(struct crq_queue *queue,
rc = plpar_hcall_norets(H_REG_CRQ,
vdev->unit_address,
queue->msg_token, PAGE_SIZE);
-   if (rc == 2) {
+   if (rc == H_CLOSED) {
/* Adapter is good, but other end is not ready */
dev_warn(hostdata->dev, "Partner adapter not ready\n");
} else if (rc != 0) {
@@ -364,7 +364,7 @@ static int ibmvscsi_init_crq_queue(struct crq_queue *queue,
rc = ibmvscsi_reset_crq_queue(queue,
  hostdata);
 
-   if (rc == 2) {
+   if (rc == H_CLOSED) {
/* Adapter is good, but other end is not ready */
dev_warn(hostdata->dev, "Partner adapter not ready\n");
retrc = 0;
-- 
2.5.0

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


Re: [PATCH v7 00/14] Big fixes, retries, handle a race condition

2016-02-10 Thread Martin K. Petersen
> "Yaniv" == Yaniv Gardi  writes:

Yaniv> V7: updated patch 0001 according to a comment also, removed patch
Yaniv> 07/15 from V6, so now there are only 14 patches

Applied to 4.6/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: [Resend PATCH 1/3] scsi:stex.c Support to Pegasus series.

2016-02-10 Thread Martin K. Petersen
> "Charles" == Charles Chiou  writes:

Charles,

Charles> Pegasus is a high performace hardware RAID solution designed to
Charles> unleash the raw power of Thunderbolt technology.

Please address Oliver's concerns about power management.

Also, I was going to merge the first two patches in the series but your
mailer mangled them and they did not apply. Please use git send-email to
submit patches.

Thank you!

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


[PATCH v2 3/7] ibmvscsi: Replace magic values in set_adpater_info() with defines

2016-02-10 Thread Tyrel Datwyler
Add defines for mad version and mad os_type, and replace the magic
numbers in set_adapter_info() accordingly.

Signed-off-by: Tyrel Datwyler 
---
 drivers/scsi/ibmvscsi/ibmvscsi.c | 8 
 drivers/scsi/ibmvscsi/viosrp.h   | 3 +++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index c888ea1..4b09a9b 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -283,8 +283,8 @@ static void set_adapter_info(struct ibmvscsi_host_data 
*hostdata)
hostdata->madapter_info.partition_number =
cpu_to_be32(partition_number);
 
-   hostdata->madapter_info.mad_version = cpu_to_be32(1);
-   hostdata->madapter_info.os_type = cpu_to_be32(2);
+   hostdata->madapter_info.mad_version = cpu_to_be32(SRP_MAD_VERSION_1);
+   hostdata->madapter_info.os_type = cpu_to_be32(SRP_MAD_OS_LINUX);
 }
 
 /**
@@ -1398,7 +1398,7 @@ static void adapter_info_rsp(struct srp_event_struct 
*evt_struct)
hostdata->host->max_sectors = 

be32_to_cpu(hostdata->madapter_info.port_max_txu[0]) >> 9;

-   if (be32_to_cpu(hostdata->madapter_info.os_type) == 3 &&
+   if (be32_to_cpu(hostdata->madapter_info.os_type) == 
SRP_MAD_OS_AIX &&
strcmp(hostdata->madapter_info.srp_version, "1.6a") <= 0) {
dev_err(hostdata->dev, "host (Ver. %s) doesn't support 
large transfers\n",
hostdata->madapter_info.srp_version);
@@ -1407,7 +1407,7 @@ static void adapter_info_rsp(struct srp_event_struct 
*evt_struct)
hostdata->host->sg_tablesize = MAX_INDIRECT_BUFS;
}
 
-   if (be32_to_cpu(hostdata->madapter_info.os_type) == 3) {
+   if (be32_to_cpu(hostdata->madapter_info.os_type) == 
SRP_MAD_OS_AIX) {
enable_fast_fail(hostdata);
return;
}
diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h
index 3d20851..d0f689b 100644
--- a/drivers/scsi/ibmvscsi/viosrp.h
+++ b/drivers/scsi/ibmvscsi/viosrp.h
@@ -221,7 +221,10 @@ struct mad_adapter_info_data {
char srp_version[8];
char partition_name[96];
__be32 partition_number;
+#define SRP_MAD_VERSION_1 1
__be32 mad_version;
+#define SRP_MAD_OS_LINUX 2
+#define SRP_MAD_OS_AIX 3
__be32 os_type;
__be32 port_max_txu[8]; /* per-port maximum transfer */
 };
-- 
2.5.0

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


[PATCH v2 5/7] ibmvscsi: Remove unsupported host config MAD

2016-02-10 Thread Tyrel Datwyler
A VIOSRP_HOST_CONFIG_TYPE management datagram (MAD) has existed in
the code for some time. From what information I've gathered from
Brian King this was likely implemented on the host side in a SLES 9
based VIOS, which is no longer supported anywhere. Further, it is
not defined in PAPR or supported by any AIX based VIOS.

Treating as bit rot and removing the associated host config code.
The config attribute and its show function are left as not to break
userspace. The behavior remains the same returning nothing.

Signed-off-by: Tyrel Datwyler 
---
 drivers/scsi/ibmvscsi/ibmvscsi.c | 71 +++-
 drivers/scsi/ibmvscsi/viosrp.h   |  7 
 2 files changed, 4 insertions(+), 74 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index c208295..e8d4af5 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -1853,62 +1853,6 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,
 }
 
 /**
- * ibmvscsi_get_host_config: Send the command to the server to get host
- * configuration data.  The data is opaque to us.
- */
-static int ibmvscsi_do_host_config(struct ibmvscsi_host_data *hostdata,
-  unsigned char *buffer, int length)
-{
-   struct viosrp_host_config *host_config;
-   struct srp_event_struct *evt_struct;
-   unsigned long flags;
-   dma_addr_t addr;
-   int rc;
-
-   evt_struct = get_event_struct(>pool);
-   if (!evt_struct) {
-   dev_err(hostdata->dev, "couldn't allocate event for 
HOST_CONFIG!\n");
-   return -1;
-   }
-
-   init_event_struct(evt_struct,
- sync_completion,
- VIOSRP_MAD_FORMAT,
- info_timeout);
-
-   host_config = _struct->iu.mad.host_config;
-
-   /* The transport length field is only 16-bit */
-   length = min(0x, length);
-
-   /* Set up a lun reset SRP command */
-   memset(host_config, 0x00, sizeof(*host_config));
-   host_config->common.type = cpu_to_be32(VIOSRP_HOST_CONFIG_TYPE);
-   host_config->common.length = cpu_to_be16(length);
-   addr = dma_map_single(hostdata->dev, buffer, length, DMA_BIDIRECTIONAL);
-
-   if (dma_mapping_error(hostdata->dev, addr)) {
-   if (!firmware_has_feature(FW_FEATURE_CMO))
-   dev_err(hostdata->dev,
-   "dma_mapping error getting host config\n");
-   free_event_struct(>pool, evt_struct);
-   return -1;
-   }
-
-   host_config->buffer = cpu_to_be64(addr);
-
-   init_completion(_struct->comp);
-   spin_lock_irqsave(hostdata->host->host_lock, flags);
-   rc = ibmvscsi_send_srp_event(evt_struct, hostdata, info_timeout * 2);
-   spin_unlock_irqrestore(hostdata->host->host_lock, flags);
-   if (rc == 0)
-   wait_for_completion(_struct->comp);
-   dma_unmap_single(hostdata->dev, addr, length, DMA_BIDIRECTIONAL);
-
-   return rc;
-}
-
-/**
  * ibmvscsi_slave_configure: Set the "allow_restart" flag for each disk.
  * @sdev:  struct scsi_device device to configure
  *
@@ -2093,21 +2037,14 @@ static struct device_attribute ibmvscsi_host_os_type = {
 static ssize_t show_host_config(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   struct Scsi_Host *shost = class_to_shost(dev);
-   struct ibmvscsi_host_data *hostdata = shost_priv(shost);
-
-   /* returns null-terminated host config data */
-   if (ibmvscsi_do_host_config(hostdata, buf, PAGE_SIZE) == 0)
-   return strlen(buf);
-   else
-   return 0;
+   return 0;
 }
 
 static struct device_attribute ibmvscsi_host_config = {
.attr = {
-.name = "config",
-.mode = S_IRUGO,
-},
+   .name = "config",
+   .mode = S_IRUGO,
+   },
.show = show_host_config,
 };
 
diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h
index d0f689b..c1ab8a4 100644
--- a/drivers/scsi/ibmvscsi/viosrp.h
+++ b/drivers/scsi/ibmvscsi/viosrp.h
@@ -99,7 +99,6 @@ enum viosrp_mad_types {
VIOSRP_EMPTY_IU_TYPE = 0x01,
VIOSRP_ERROR_LOG_TYPE = 0x02,
VIOSRP_ADAPTER_INFO_TYPE = 0x03,
-   VIOSRP_HOST_CONFIG_TYPE = 0x04,
VIOSRP_CAPABILITIES_TYPE = 0x05,
VIOSRP_ENABLE_FAST_FAIL = 0x08,
 };
@@ -165,11 +164,6 @@ struct viosrp_adapter_info {
__be64 buffer;
 };
 
-struct viosrp_host_config {
-   struct mad_common common;
-   __be64 buffer;
-};
-
 struct viosrp_fast_fail {
struct mad_common common;
 };
@@ -207,7 +201,6 @@ union mad_iu {
struct viosrp_empty_iu empty_iu;
struct viosrp_error_log error_log;
struct viosrp_adapter_info adapter_info;
-   struct viosrp_host_config 

[PATCH v2 2/7] ibmvscsi: Add and use enums for valid CRQ header values

2016-02-10 Thread Tyrel Datwyler
The PAPR defines four valid header values for the first byte of a
CRQ message. Namely, an unused/empty message (0x00), a valid
command/response entry (0x80), a valid initialization entry (0xC0),
and a valid transport event (0xFF). Further, initialization responses
have two formats namely initialize (0x01) and initialize complete
(0x02). Define these values as enums and use them in the code in
place of their magic number equivalents.

Signed-off-by: Tyrel Datwyler 
---
 drivers/scsi/ibmvscsi/ibmvscsi.c | 18 +-
 drivers/scsi/ibmvscsi/viosrp.h   | 12 
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index adfef9d..c888ea1 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -182,7 +182,7 @@ static struct viosrp_crq *crq_queue_next_crq(struct 
crq_queue *queue)
 
spin_lock_irqsave(>lock, flags);
crq = >msgs[queue->cur];
-   if (crq->valid & 0x80) {
+   if (crq->valid != VIOSRP_CRQ_FREE) {
if (++queue->cur == queue->size)
queue->cur = 0;
 
@@ -231,7 +231,7 @@ static void ibmvscsi_task(void *data)
/* Pull all the valid messages off the CRQ */
while ((crq = crq_queue_next_crq(>queue)) != NULL) {
ibmvscsi_handle_crq(crq, hostdata);
-   crq->valid = 0x00;
+   crq->valid = VIOSRP_CRQ_FREE;
}
 
vio_enable_interrupts(vdev);
@@ -239,7 +239,7 @@ static void ibmvscsi_task(void *data)
if (crq != NULL) {
vio_disable_interrupts(vdev);
ibmvscsi_handle_crq(crq, hostdata);
-   crq->valid = 0x00;
+   crq->valid = VIOSRP_CRQ_FREE;
} else {
done = 1;
}
@@ -474,7 +474,7 @@ static int initialize_event_pool(struct event_pool *pool,
struct srp_event_struct *evt = >events[i];
memset(>crq, 0x00, sizeof(evt->crq));
atomic_set(>free, 1);
-   evt->crq.valid = 0x80;
+   evt->crq.valid = VIOSRP_CRQ_CMD_RSP;
evt->crq.IU_length = cpu_to_be16(sizeof(*evt->xfer_iu));
evt->crq.IU_data_ptr = cpu_to_be64(pool->iu_token +
sizeof(*evt->xfer_iu) * i);
@@ -1767,9 +1767,9 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,
struct srp_event_struct *evt_struct =
(__force struct srp_event_struct *)crq->IU_data_ptr;
switch (crq->valid) {
-   case 0xC0:  /* initialization */
+   case VIOSRP_CRQ_INIT_RSP:   /* initialization */
switch (crq->format) {
-   case 0x01:  /* Initialization message */
+   case VIOSRP_CRQ_INIT:   /* Initialization message */
dev_info(hostdata->dev, "partner initialized\n");
/* Send back a response */
rc = ibmvscsi_send_crq(hostdata, 0xC002LL, 
0);
@@ -1781,7 +1781,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,
}
 
break;
-   case 0x02:  /* Initialization response */
+   case VIOSRP_CRQ_INIT_COMPLETE:  /* Initialization response */
dev_info(hostdata->dev, "partner initialization 
complete\n");
 
/* Now login */
@@ -1791,7 +1791,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,
dev_err(hostdata->dev, "unknown crq message type: 
%d\n", crq->format);
}
return;
-   case 0xFF:  /* Hypervisor telling us the connection is closed */
+   case VIOSRP_CRQ_XPORT_EVENT:/* Hypervisor telling us the connection 
is closed */
scsi_block_requests(hostdata->host);
atomic_set(>request_limit, 0);
if (crq->format == 0x06) {
@@ -1807,7 +1807,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,
ibmvscsi_reset_host(hostdata);
}
return;
-   case 0x80:  /* real payload */
+   case VIOSRP_CRQ_CMD_RSP:/* real payload */
break;
default:
dev_err(hostdata->dev, "got an invalid message type 0x%02x\n",
diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h
index d1044e9..3d20851 100644
--- a/drivers/scsi/ibmvscsi/viosrp.h
+++ b/drivers/scsi/ibmvscsi/viosrp.h
@@ -51,6 +51,18 @@ union srp_iu {
u8 reserved[SRP_MAX_IU_LEN];
 };
 
+enum viosrp_crq_headers {
+   VIOSRP_CRQ_FREE = 0x00,
+   VIOSRP_CRQ_CMD_RSP = 0x80,
+   VIOSRP_CRQ_INIT_RSP = 0xC0,
+   VIOSRP_CRQ_XPORT_EVENT = 0xFF

[PATCH v2 1/7] ibmvscsi: Correct values for several viosrp_crq_format enums

2016-02-10 Thread Tyrel Datwyler
The enum values for VIOSRP_LINUX_FORMAT and VIOSRP_INLINE_FORMAT are
off by one. They are currently defined as 0x06 and 0x07 respetively.
These values are defined in PAPR correctly as 0x05 and 0x06. This
inconsistency has gone unnoticed as neither enum is currently used.
The possible future support of PING messages between the VIOS and
client adapter relies on VIOSRP_INLINE_FORMAT crq messages.
Corrected these enum values to match PAPR definitions.

Signed-off-by: Tyrel Datwyler 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/ibmvscsi/viosrp.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/viosrp.h b/drivers/scsi/ibmvscsi/viosrp.h
index 1162430..d1044e9 100644
--- a/drivers/scsi/ibmvscsi/viosrp.h
+++ b/drivers/scsi/ibmvscsi/viosrp.h
@@ -56,8 +56,8 @@ enum viosrp_crq_formats {
VIOSRP_MAD_FORMAT = 0x02,
VIOSRP_OS400_FORMAT = 0x03,
VIOSRP_AIX_FORMAT = 0x04,
-   VIOSRP_LINUX_FORMAT = 0x06,
-   VIOSRP_INLINE_FORMAT = 0x07
+   VIOSRP_LINUX_FORMAT = 0x05,
+   VIOSRP_INLINE_FORMAT = 0x06
 };
 
 enum viosrp_crq_status {
-- 
2.5.0

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


Re: [PATCH 00/23] ALUA device handler update, part II

2016-02-10 Thread Martin K. Petersen
> "Bart" == Bart Van Assche  writes:

Bart,

Bart> I will try to free up some time to help with reviewing and testing
Bart> this patch series. But before I can do that the v4.5-rc multipath
Bart> code needs to be stabilized first. See also
Bart> https://www.redhat.com/archives/dm-devel/2016-February/msg00066.html.

Have you had time to take a look?

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


Business Partnership

2016-02-10 Thread EYADEMA
Hello,

I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached 
proposal.
Thanks in anticipation of your urgent response,


LAURENT EYADEMA

proposal.docx
Description: Binary data