Re: [PATCH v2] scsi: Change sense buffer size to 252
On 03/14/2014 07:00 AM, Fam Zheng wrote:
> According to SPC-4, section 4.5.2.1, 252 is the limit of sense data. So
> increase the values.
>
> Tested by hacking QEMU to fake virtio-scsi request sense len to 252.
> Without this patch the driver stops working immediately when it gets the
> request.
>
> Signed-off-by: Fam Zheng
> ---
> include/linux/virtio_scsi.h | 2 +-
> include/scsi/scsi_cmnd.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/virtio_scsi.h b/include/linux/virtio_scsi.h
> index 4195b97..a437f7f 100644
> --- a/include/linux/virtio_scsi.h
> +++ b/include/linux/virtio_scsi.h
> @@ -28,7 +28,7 @@
> #define _LINUX_VIRTIO_SCSI_H
>
> #define VIRTIO_SCSI_CDB_SIZE 32
> -#define VIRTIO_SCSI_SENSE_SIZE 96
> +#define VIRTIO_SCSI_SENSE_SIZE 252
>
> /* SCSI command request, followed by data-out */
> struct virtio_scsi_cmd_req {
> diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
> index 91558a1..a64dac03 100644
> --- a/include/scsi/scsi_cmnd.h
> +++ b/include/scsi/scsi_cmnd.h
> @@ -104,7 +104,7 @@ struct scsi_cmnd {
> struct request *request;/* The command we are
> working on */
>
> -#define SCSI_SENSE_BUFFERSIZE96
> +#define SCSI_SENSE_BUFFERSIZE252
> unsigned char *sense_buffer;
> /* obtained by REQUEST SENSE when
>* CHECK CONDITION is received on original
>
Not without careful review.
Blindly increasing the buffersize is not a good idea; this define is
used at several locations and even within the drivers themselves.
So we cannot just increase the define for the SCSI stack.
And, btw, so far I haven't come across any issue where a sense
buffer overflow occurred. We first need to implement a proper sense
code handling (descriptor sense parsing etc) before we need to worry
about this.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] scsi: Change sense buffer size to 252
According to SPC-4, section 4.5.2.1, 252 is the limit of sense data. So
increase the values.
Tested by hacking QEMU to fake virtio-scsi request sense len to 252.
Without this patch the driver stops working immediately when it gets the
request.
Signed-off-by: Fam Zheng
---
include/linux/virtio_scsi.h | 2 +-
include/scsi/scsi_cmnd.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/virtio_scsi.h b/include/linux/virtio_scsi.h
index 4195b97..a437f7f 100644
--- a/include/linux/virtio_scsi.h
+++ b/include/linux/virtio_scsi.h
@@ -28,7 +28,7 @@
#define _LINUX_VIRTIO_SCSI_H
#define VIRTIO_SCSI_CDB_SIZE 32
-#define VIRTIO_SCSI_SENSE_SIZE 96
+#define VIRTIO_SCSI_SENSE_SIZE 252
/* SCSI command request, followed by data-out */
struct virtio_scsi_cmd_req {
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index 91558a1..a64dac03 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -104,7 +104,7 @@ struct scsi_cmnd {
struct request *request;/* The command we are
working on */
-#define SCSI_SENSE_BUFFERSIZE 96
+#define SCSI_SENSE_BUFFERSIZE 252
unsigned char *sense_buffer;
/* obtained by REQUEST SENSE when
* CHECK CONDITION is received on original
--
1.9.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] hpsa: fix bad endif placement in RAID 5 mapper code
From: Stephen M. Cameron It caused the i/o request to always be counted as ineligible for the accelerated i/o path on 32 bit systems and negatively affected performance. Signed-off-by: Stephen M. Cameron --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index a32a510..eb9af2f 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -3828,8 +3828,8 @@ static int hpsa_scsi_ioaccel_raid_map(struct ctlr_info *h, #else first_group = (first_block % stripesize) / r5or6_blocks_per_row; last_group = (last_block % stripesize) / r5or6_blocks_per_row; - if (first_group != last_group) #endif + if (first_group != last_group) return IO_ACCEL_INELIGIBLE; /* Verify request is in a single row of RAID 5/6 */ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hpsa: update driver version to 3.4.4-1
From: Stephen M. Cameron Signed-off-by: Stephen M. Cameron --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index eb9af2f..9a6e4a2 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -53,7 +53,7 @@ #include "hpsa.h" /* HPSA_DRIVER_VERSION must be 3 byte values (0-255) separated by '.' */ -#define HPSA_DRIVER_VERSION "3.4.0-1" +#define HPSA_DRIVER_VERSION "3.4.4-1" #define DRIVER_NAME "HP HPSA Driver (v " HPSA_DRIVER_VERSION ")" #define HPSA "hpsa" -- 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] qla2xxx: Fix build errors related to invalid print fields on some architectures.
From: Chad Dupuis
Fixes some build warnings such as:
drivers/scsi/qla2xxx/qla_attr.c:162:6: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 6 has type 'size_t'"
and
drivers/scsi/qla2xxx/qla_init.c:5198:7: warning: format '%lx' expects argument
of type 'long unsigned int', but argument 5 has type 'uint32_t' [-Wformat]
Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_attr.c |6 +++---
drivers/scsi/qla2xxx/qla_init.c | 12 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
index aa81829..07befcf 100644
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -159,7 +159,7 @@ qla2x00_sysfs_read_fw_dump_template(struct file *filp,
struct kobject *kobj,
return 0;
ql_dbg(ql_dbg_user, vha, 0x70e2,
- "chunk <- off=%llx count=%lx\n", off, count);
+ "chunk <- off=%llx count=%zx\n", off, count);
return memory_read_from_buffer(buf, count, &off,
ha->fw_dump_template, ha->fw_dump_template_len);
}
@@ -200,11 +200,11 @@ qla2x00_sysfs_write_fw_dump_template(struct file *filp,
struct kobject *kobj,
if (off + count > ha->fw_dump_template_len) {
count = ha->fw_dump_template_len - off;
ql_dbg(ql_dbg_user, vha, 0x70d3,
- "chunk -> truncating to %lx bytes.\n", count);
+ "chunk -> truncating to %zx bytes.\n", count);
}
ql_dbg(ql_dbg_user, vha, 0x70d4,
- "chunk -> off=%llx count=%lx\n", off, count);
+ "chunk -> off=%llx count=%zx\n", off, count);
memcpy(ha->fw_dump_template + off, buf, count);
if (off + count == ha->fw_dump_template_len) {
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 0a25e8b..38aeb54 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -5291,8 +5291,8 @@ qla24xx_load_risc_flash(scsi_qla_host_t *vha, uint32_t
*srisc_addr,
"-> template size %x bytes\n", dlen);
if (dlen > risc_size * sizeof(*dcode)) {
ql_log(ql_log_warn, vha, 0x0167,
- "Failed fwdump template exceeds array by %lx bytes\n",
- dlen - risc_size * sizeof(*dcode));
+ "Failed fwdump template exceeds array by %x bytes\n",
+ (uint32_t)(dlen - risc_size * sizeof(*dcode)));
goto default_template;
}
ha->fw_dump_template_len = dlen;
@@ -5558,8 +5558,8 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha, uint32_t
*srisc_addr)
ha->fw_dump_template_len = 0;
ql_dbg(ql_dbg_init, vha, 0x171,
- "Loading fwdump template from %lx\n",
- (void *)fwcode - (void *)blob->fw->data);
+ "Loading fwdump template from %x\n",
+ (uint32_t)((void *)fwcode - (void *)blob->fw->data));
risc_size = be32_to_cpu(fwcode[2]);
ql_dbg(ql_dbg_init, vha, 0x172,
"-> array size %x dwords\n", risc_size);
@@ -5593,8 +5593,8 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha, uint32_t
*srisc_addr)
"-> template size %x bytes\n", dlen);
if (dlen > risc_size * sizeof(*fwcode)) {
ql_log(ql_log_warn, vha, 0x0177,
- "Failed fwdump template exceeds array by %lx bytes\n",
- dlen - risc_size * sizeof(*fwcode));
+ "Failed fwdump template exceeds array by %x bytes\n",
+ (uint32_t)(dlen - risc_size * sizeof(*fwcode)));
goto default_template;
}
ha->fw_dump_template_len = dlen;
--
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: blk_iopoll_enabled
On 3/13/2014 5:34 PM, Jens Axboe wrote: On 03/12/2014 09:40 PM, Jens Axboe wrote: On 2014-03-12 11:35, Sagi Grimberg wrote: Hey Jens, So I'm looking at blk_iopoll for iSER & SRP and I have one gap I would like to get your input on. In blk-iopoll.c I see: int blk_iopoll_enabled = 1; EXPORT_SYMBOL(blk_iopoll_enabled); This is set to 1 and exported for everyone to condition and *modify* it. The documentation says the user must check this when using blk_iopoll. My question is why? it should always be true shouldn't it? Moreover, isn't it better to protect it using a get() function of it? can't someone set it to 0 and shutdown the lights on everyone else? We can kill it. IIRC, it was mostly used during development to test functionality and performance (and wired to a sysfs toggle file). But... Just because it's exported doesn't mean that random users are allowed to just disable it. What's left now is an always-on, so we can remove it. It _is_ still exported, I just forgot it was put in sysctl. I'll kill it off completely now. It's safe to toggle from user space, but only practically so if IO is idle. It makes no attempt to ensure that, as it was just a debug thing. Thanks Sagi. -- 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: mmotm 2014-03-12-16-04 uploaded (scsi/qla2xxx)
On 03/12/2014 04:05 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2014-03-12-16-04 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > > You will need quilt to apply these patches to the latest Linus release (3.x > or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > http://ozlabs.org/~akpm/mmotm/series > > The file broken-out.tar.gz contains two datestamp files: .DATE and > .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, > followed by the base kernel version against which this patch series is to > be applied. > from linux-next: on i386: drivers/scsi/qla2xxx/qla_init.c:5295:7: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'uint32_t' [-Wformat] drivers/scsi/qla2xxx/qla_init.c:5562:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'int' [-Wformat] drivers/scsi/qla2xxx/qla_init.c:5597:7: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'uint32_t' [-Wformat] drivers/scsi/qla2xxx/qla_attr.c:162:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' [-Wformat] drivers/scsi/qla2xxx/qla_attr.c:203:7: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'size_t' [-Wformat] drivers/scsi/qla2xxx/qla_attr.c:207:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' [-Wformat] -- ~Randy -- 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 v17 3/4] ata: Add APM X-Gene SoC AHCI SATA host controller driver
On Wednesday, March 12, 2014 02:19:32 PM Loc Ho wrote: > This patch adds support for the APM X-Gene SoC AHCI SATA host controller > driver. It requires the corresponding APM X-Gene SoC PHY driver. This > initial version only supports Gen3 speed. > > Signed-off-by: Loc Ho > Signed-off-by: Tuan Phan > Signed-off-by: Suman Tripathi Reviewed-by: Bartlomiej Zolnierkiewicz Thanks for fixing all the remaining issues. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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: blk_iopoll_enabled
On 03/12/2014 09:40 PM, Jens Axboe wrote: On 2014-03-12 11:35, Sagi Grimberg wrote: Hey Jens, So I'm looking at blk_iopoll for iSER & SRP and I have one gap I would like to get your input on. In blk-iopoll.c I see: int blk_iopoll_enabled = 1; EXPORT_SYMBOL(blk_iopoll_enabled); This is set to 1 and exported for everyone to condition and *modify* it. The documentation says the user must check this when using blk_iopoll. My question is why? it should always be true shouldn't it? Moreover, isn't it better to protect it using a get() function of it? can't someone set it to 0 and shutdown the lights on everyone else? We can kill it. IIRC, it was mostly used during development to test functionality and performance (and wired to a sysfs toggle file). But... Just because it's exported doesn't mean that random users are allowed to just disable it. What's left now is an always-on, so we can remove it. It _is_ still exported, I just forgot it was put in sysctl. I'll kill it off completely now. It's safe to toggle from user space, but only practically so if IO is idle. It makes no attempt to ensure that, as it was just a debug thing. -- Jens Axboe -- 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] MAINTAINERS: update Intel C600 SAS driver maintainers
Cc: Artur Paszkiewicz Signed-off-by: Lukasz Dorau Signed-off-by: Dave Jiang Signed-off-by: Maciej Patelczyk --- MAINTAINERS |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1ecfde1..cf59068 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4458,8 +4458,7 @@ K:\b(ABS|SYN)_MT_ INTEL C600 SERIES SAS CONTROLLER DRIVER M: Intel SCU Linux support -M: Lukasz Dorau -M: Maciej Patelczyk +M: Artur Paszkiewicz M: Dave Jiang L: linux-scsi@vger.kernel.org T: git git://git.code.sf.net/p/intel-sas/isci -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] megaraid_sas: make the log message about rescanning more informative.
On Wed, 2014-01-08 at 12:28 +, Saxena, Sumit wrote:
>
> >-Original Message-
> >From: Jasper Spaans [mailto:spa...@fox-it.com]
> >Sent: Friday, October 25, 2013 5:53 PM
> >To: DL-MegaRAID Linux
> >Cc: linux-scsi@vger.kernel.org
> >Subject: [PATCH] megaraid_sas: make the log message about rescanning
> >more informative.
> >
> >Hi,
> >
> >I was working on one of our servers, and saw the following interesting
> >message in dmesg:
> >
> >[20961024.720972] scanning ...
> >
> >This scared me somewhat. Please find a patch to make it easier to see where
> >this message is coming from.
> >
> >Cheers,
> >Jasper
> >
> >---
> > drivers/scsi/megaraid/megaraid_sas_base.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> >b/drivers/scsi/megaraid/megaraid_sas_base.c
> >index 1f0ca68..3457289 100644
> >--- a/drivers/scsi/megaraid/megaraid_sas_base.c
> >+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> >@@ -5461,7 +5461,7 @@ megasas_aen_polling(struct work_struct *work)
> > }
> >
> > if (doscan) {
> >-printk(KERN_INFO "scanning ...\n");
> >+printk(KERN_INFO "Rescanning MegaRAID devices ...\n");
> > megasas_get_pd_list(instance);
> > for (i = 0; i < MEGASAS_MAX_PD_CHANNELS; i++) {
> > for (j = 0; j < MEGASAS_MAX_DEV_PER_CHANNEL;
> >j++) {
> >--
> >1.7.9.5
> Acked-by: Sumit Saxena
I'd prefer consistency for this: Most of the messages in this driver
have a megasas: prefix ... but there are quite a large number that don't
(and which probably should have). If this is necessary, please use the
standard driver prefix.
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 10/35] hpsa: add hp_ssd_smart_path_enabled sysfs attribute
On Tue, 2014-02-18 at 13:55 -0600, Stephen M. Cameron wrote: > From: Scott Teel > > Signed-off-by: Scott Teel > Acked-by: Stephen M. Cameron Just a note: when you send a patch to me, that should be signed-off-by. It's because you're part of the transmission path under the DCO (which the signoffs track). When you want me to apply a patch someone else sends in, you either resend it to me with your signoff or just ack it (acked by means you approve it but didn't resend it to me). I've altered all the acks from you in this series to signoffs. 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] [SCSI] megaraid: use GFP_ATOMIC under spin lock
On Wed, 2014-01-08 at 12:16 +, Saxena, Sumit wrote: > > >-Original Message- > >From: Wei Yongjun [mailto:weiyj...@gmail.com] > >Sent: Friday, December 20, 2013 8:38 AM > >To: DL-MegaRAID Linux; jbottom...@parallels.com; simon.pu...@gmail.com; > >jkos...@suse.cz > >Cc: yongjun_...@trendmicro.com.cn; linux-scsi@vger.kernel.org > >Subject: [PATCH] [SCSI] megaraid: use GFP_ATOMIC under spin lock > > > >From: Wei Yongjun > > > >A spin lock is taken here so we should use GFP_ATOMIC. > > > >Signed-off-by: Wei Yongjun > >--- > > drivers/scsi/megaraid/megaraid_mm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/drivers/scsi/megaraid/megaraid_mm.c > >b/drivers/scsi/megaraid/megaraid_mm.c > >index a706927..99fa5d3 100644 > >--- a/drivers/scsi/megaraid/megaraid_mm.c > >+++ b/drivers/scsi/megaraid/megaraid_mm.c > >@@ -570,7 +570,7 @@ mraid_mm_attach_buf(mraid_mmadp_t *adp, uioc_t > >*kioc, int xferlen) > > > > kioc->pool_index= right_pool; > > kioc->free_buf = 1; > >-kioc->buf_vaddr = pci_pool_alloc(pool->handle, GFP_KERNEL, > >+kioc->buf_vaddr = pci_pool_alloc(pool->handle, > >GFP_ATOMIC, > > &kioc->buf_paddr); > > spin_unlock_irqrestore(&pool->lock, flags); > > > > > Acked-by: Sumit Saxena This doesn't look like the right fix to me. What is the function of pool->lock around this code region? The only data you use from the pool is pool->handle which is set up at init time ... there's no need to use a lock to read a piece of data which is effectively constant, so just drop the lock. 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 v2 00/23] scsi: Use pci_enable_msix_range() instead of pci_enable_msix()
On Wed, 2014-03-12 at 22:04 -0600, Bjorn Helgaas wrote:
> On Mon, Feb 24, 2014 at 09:02:00AM +0100, Alexander Gordeev wrote:
> > Hello!
> >
> > This series is against James Bottomley's SCSI tree [1], but it needs
> > commit f7fc32c ("PCI/MSI: Add pci_enable_msi_exact() and
> > pci_enable_msix_exact()") from from Bjorn Helgaas's PCI tree [2]:
> >
> > 1. git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
> > 2. git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> >
> > Recently pci_enable_msix_exact() function has been accepted to
> > the mainline. That is a variation of pci_enable_msix_range() which
> > allows a device driver to request a particular number of MSI-Xs.
> >
> > As result, most of the changes posted in version 1 of this series
> > are invalidated and need to use pci_enable_msix_exact() instead of
> > originally posted pci_enable_msix_range() usages.
> >
> > I removed almost all ACKs, since unlike pci_enable_msix_range()
> > function which returns the number of MSI-Xs allocated or negative
> > errno, pci_enable_msix_exact() returns either zero success code or
> > a negative errno. Although this change is simple, it still entails
> > an updated error code analysis and would be better reviewed by
> > driver maintainers.
>
> Hi James,
>
> I think Alexander sent these to linux-scsi hoping that you would handle
> them, but I know it's a hassle because they depend on f7fc32c, which went
> in after the merge window.
>
> I'd be glad to review these and apply them through my tree, unless you want
> to do it. I'd like to get these merged in the v3.15 merge window so
> Alexander can move on to something else. I haven't checked for merge
> conflicts with scsi.git yet, but I assume they'd be pretty trivial if there
> are any.
Sure, any that haven't been applied ... I think we already have some
updates for drivers which do MSIX changes, but for those you'll see the
conflict with scsi.git and you can just drop the patch for that driver.
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
