[PATCH v1] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips

The files in this change implement the UFS HW (controller & PHY) specific behavior in Qualcomm MSM chips. Signed-off-by: Yaniv Gardi --- drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c | 254 +++ drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h | 216 ++ drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c | 368 +

Re: [PATCH v2 RESEND 12/23] lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()

On Mon, Aug 11, 2014 at 01:14:54PM -0400, James Smart wrote: > Alexander, > > I haven't looked too deeply, but it's clear it doesn't jive with what we've > discussed in the past. Your original patches missed several other similar > sections for revision. I had sent a revised set of patches. > > I

[PATCH v2] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips

The files in this change implement the UFS HW (controller & PHY) specific behavior in Qualcomm MSM chips. Signed-off-by: Yaniv Gardi --- drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c | 254 +++ drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h | 216 ++ drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c | 368 +

[PATCH v3 12/23] lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()

As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Sign

[RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

Sending the this patch once agin using git send-email. Up to now, Driver allocates a single contiguous block of memory pool for all reply queues and passes down a single address in the ReplyDescriptorPostQueueAddress field of the IOC Init Request Message to the firmware. When firmware receives th

RE: [PATCH 08/10] [scsi] mpt2sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state.

Driver initialization fails if driver tries to send IOC facts request message when the IOC is in reset or in a fault state. This patch will make sure that 1.Driver to send IOC facts request message only if HBA is in operational or ready state. 2.If IOC is in fault state, a diagnostic reset wou

Re: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

On Tue, 2014-08-12 at 14:54 +0530, Sreekanth Reddy wrote: > So, the proposal is to allocate memory independently for each > Reply Queue and pass down all of the addresses to the firmware. > Then the firmware will just take each address and program the value > into the correct register. trivial not

RE: [RESEND][PATCH 7/8][SCSI]mpt3sas: Added Reply Descriptor Post Queue (RDPQ) Array support

Sending this patch once again using git send-email. Up to now, Driver allocates a single contiguous block of memory pool for all reply queues and passes down a single address in the ReplyDescriptorPostQueueAddress field of the IOC Init Request Message to the firmware. When firmware receives this

Re: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

On Tue, Aug 12, 2014 at 3:07 PM, Joe Perches wrote: > On Tue, 2014-08-12 at 14:54 +0530, Sreekanth Reddy wrote: >> So, the proposal is to allocate memory independently for each >> Reply Queue and pass down all of the addresses to the firmware. >> Then the firmware will just take each address and p

Re: [RESEND][PATCH 8/8][SCSI]mpt3sas: Bump mpt3sas driver version to 04.100.00.00

Hi Martin, Among the mpt3sas phase2 and phase3 patch set, following are the patches which you have completed the review 1. [RESEND][PATCH 1/8][SCSI]mpt3sas: MPI2.5 Rev G (2.5.2) specifications 2. [RESEND][PATCH 2/8][SCSI]mpt3sas: Clear PFA Status on SGPIO when PFA Drive is Removed or Replaced 3.

Re: [RESEND][PATCH 10/10][SCSI]mpt2sas: Bump mpt2sas driver version to 18.100.00.00

Hi Martin, Among the mpt2sas phase17 and phase18 patch set, following are the patches which you have completed the review 1. [RESEND][PATCH 01/10][SCSI]mpt2sas: Added driver module parameter max_msix_vectors 2. [RESEND][PATCH 02/10][SCSI]mpt2sas: MPI2 Rev Y (2.00.17) and Rev Z (2.00.18) specifica

Re: [PATCH v2 RESEND 04/23] bfa: Use pci_enable_msix_exact() instead of pci_enable_msix()

On Mon, Aug 11, 2014 at 11:02:56AM +, Anil Gurumurthy wrote: > Acked-by: Anil Gurumurthy Many thanks, Anil! If your Ack apply to this patch only or to all three 'bfa' patches in this series? Thanks! > -Original Message- > From: Alexander Gordeev [mailto:agord...@redhat.com] > Sent

Re: [Xen-devel] [PATCH V4 2/4] Introduce xen-scsifront module

On 08/11/2014 07:50 PM, Christoph Hellwig wrote: On Mon, Aug 11, 2014 at 12:27:29PM +0200, Juergen Gross wrote: What do you mean with "unusual"? You mean transferring the EH action to Dom0? Yes. Note that hyperv tries something similar and they've run into timeout issues, you might want to re

Re: [Xen-devel] [PATCH V4 3/4] Introduce XEN scsiback module

On 08/11/2014 08:14 PM, Christoph Hellwig wrote: +#include __scsi_print_sense() +#include struct scsi_sense_hdr +#include SG_ALL What do you need these for? Normally target drivers shouldn't need these. +struct vscsibk_emulate { + void (*pre_function)(struct vscsibk_pend

Re: [Xen-devel] [PATCH V4 3/4] Introduce XEN scsiback module

On 08/12/2014 02:29 PM, Juergen Gross wrote: On 08/11/2014 08:14 PM, Christoph Hellwig wrote: +static void scsiback_notify_work(struct vscsibk_info *info) +{ +info->waiting_reqs = 1; +wake_up(&info->wq); +} + +static irqreturn_t scsiback_intr(int irq, void *dev_id) +{ +scsiback_notif

RE: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense()

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Yoshihiro YUNOMAE > Sent: Friday, 08 August, 2014 6:50 AM ... > Subject: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in > __scsi_print_sense() > > A device

[Bug 81861] Oops by mvsas v0.8.16: sas: ataX: end_device-Y:0:Z: dev error handler -> general protection fault, RIP: mvs_task_prep_ata+0x80/0x3a0

https://bugzilla.kernel.org/show_bug.cgi?id=81861 --- Comment #3 from linux-...@crashplan.pro --- Because Ubuntu doesn't provide debug symbols for their mainline kernel builds I am reverting back to their kernel version 3.13

Re: [PATCH V4 3/4] Introduce XEN scsiback module

Hi Juergen & Co, Finally had a chance to review this code. Comments are inline below.. On Fri, 2014-08-08 at 09:49 +0200, jgr...@suse.com wrote: > From: Juergen Gross > > Introduces the XEN pvSCSI backend. With pvSCSI it is possible for a XEN domU > to issue SCSI commands to a SCSI LUN assigne

[Bug 81861] Oops by mvsas v0.8.16: sas: ataX: end_device-Y:0:Z: dev error handler -> general protection fault, RIP: mvs_task_prep_ata+0x80/0x3a0

https://bugzilla.kernel.org/show_bug.cgi?id=81861 --- Comment #4 from linux-...@crashplan.pro --- Trying to debug mvs_task_prep with the help of the tutorial at . # cat /sys/module/mvsas/sections/.init.text 0xa00c8000 #

[PATCH v3 2/3] cxgb4: use module_long_probe_init()

From: "Luis R. Rodriguez" cxgb4 probe can take up to over 1 minute when the firmware is is written and installed on the device, even after this the device driver still does some device probing and can take quite a bit. This driver needs fixing but right now it simply wont' work on some systems. U

[PATCH v3 3/3] mptsas: use module_long_probe_init()

From: "Luis R. Rodriguez" Its reported that mptsas can at times take over 30 seconds to recognize SCSI storage devices [0], this is done on the driver's probe path. Use the the new module_long_probe_init() to annotate this driver's probe is broken and require some love, but makes the driver opera

[PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

From: "Luis R. Rodriguez" Tetsuo bisected and found that commit 786235ee "kthread: make kthread_create() killable" modified kthread_create() to bail as soon as SIGKILL is received. This is causing some issues with some drivers and at times boot. Joseph then found that failures occur as the system

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

Luis R. Rodriguez wrote: > Tetsuo bisected and found that commit 786235ee \"kthread: make > kthread_create() killable\" modified kthread_create() to bail as > soon as SIGKILL is received. I just wrote commit 786235ee. It is not Tetsuo who bisected it. > @@ -128,4 +129,38 @@ bool queue_kthread_wor

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

On Wed, Aug 13, 2014 at 07:59:06AM +0900, Tetsuo Handa wrote: > Luis R. Rodriguez wrote: > > Tetsuo bisected and found that commit 786235ee \"kthread: make > > kthread_create() killable\" modified kthread_create() to bail as > > soon as SIGKILL is received. > > I just wrote commit 786235ee. It is

Re: Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace

Hi Douglas, Thank you for your comment. (2014/08/08 22:07), Douglas Gilbert wrote: On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote: Hi All, This patch set introduces new traceevents in order to output continuous error messages. Current SCSI printk messages in upstream kernel can be divided by a

Re: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense()

Hi Elliot, Thank you for your comment. (2014/08/12 23:51), Elliott, Robert (Server Storage) wrote: -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Yoshihiro YUNOMAE Sent: Friday, 08 August, 2014 6:50 AM ... Subject:

Re: [PATCH V5] Save command pool address of Scsi_Host

On 08/04/2014 01:30 PM, jgr...@suse.com wrote: From: Juergen Gross If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's private command pool is needed. scsi_find_host_cmd_pool() will locate it, but scsi_alloc_host_cmd_pool() isn't saving the pool address in the host t