Re: [RFC 1/2] target: Add support for fabric IRQ completion
On 6/9/2015 10:27 AM, Christoph Hellwig wrote: diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c index 3fbb0d4..aa08d6b 100644 --- a/drivers/target/target_core_tpg.c +++ b/drivers/target/target_core_tpg.c @@ -37,6 +37,7 @@ #include #include +#include #include #include "target_core_internal.h" This hunk look unrelated. Nic, can you remove that - it breaks compilation... 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: [PATCH] scsi_dh: convert __ATTR macro to DEVICE_ATTR_RW and snprintf show method cleanup
On 06/26/2015 08:38 AM, Seymour, Shane M wrote: > > Converted dh_state to use DEVICE_ATTR_RW macro > instead of __ATTR. That forced a change to the associated > show/store function names and the name of the attribute. > > Changed usage of snprintf in show function to scnprintf per > Documentation/filesystems/sysfs.txt. > > Signed-off-by: Shane Seymour > --- Reviewed-by: Hannes Reinecke Note that I'm currently preparing a device handler update, based upon an earlier patchset from hch. I'll be folding this patch into it, unless it'll be picked up earlier. Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] implementaion of ufs variant
Hi James et. al, We had a lively discussion in the thread titled "Re: [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device" regarding the proper implementation of a UFS controller variant. After further consideration, we propose to go with what Rob initially suggested - i.e. "you should do like many other common *HCIs do and make the base UFS driver a set of library functions that drivers can use or call". The implementation of such a change would incur the following changes: 1. Moving a few generic functions from ufs/ufshcd-pltfrm.c to ufs/ufshcd.c 2. Having a ufs/ufshcd-pltfrm.c file per implementation (e.g. ufs/ufs-qcom.c) and removing the existing generic file from the code base 3. Externalizing multiple functions from the ufs/ufshcd.c file to be used by multiple variants The initialization flow would be: 1. The variant probe is called 2. The variant would call the necessary initialization functions from the generic ufs/ufshcd.c file 3. Since the event-driven mechanism is implemented in the generic implementation - during runtime ufs/ufshcd.c would call upon variant operations (vops) in the variant implementation using a set of callback provided during the probe/init phase. The pros of such an approach are: 1. A generic set of library functions that implement the UFS standard to be called by each variant 2. Will be easy to add other UFS hosts in the future 3. Similar approach to other memory solutions such as the mmc driver 4. Keeps the runtime code centralized and therefore maintainable The con to such an approach: 1. It is not backward compatible to existing (deployed) code Our feeling is that, since UFS does not have great market penetration yet, now would be the time to introduce a change such as we are proposing. As a side-effect to this solution, we are considering removing ufs/ufshcd-pci.c from the community's code. Our understanding is that this was used for initial bring ups on emulation platforms. Since each controller would have to generate its own variant implementation - should a pci based solution be required in the future, it could be reimplemented based on the new paradigm. Please let us know whether you agree with this approach. QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: megaraid_sas: "FW in FAULT state!!", how to get more debug output? [BKO63661]
Hi Kashyap, Thanks for the patch. May I ask what tree it was based on? Linus' latest? I am trying to apply it to the SLES 11 SP3 and SLES 12 kernel trees (based on kernel v3.0 + a bunch of backports and v3.12 respectively) but your patch fails to apply in both cases. I'll try harder but I don't know anything about the megaraid_sas code so I really don't know where I'm going. Does your patch depend on any other that may not be present in the SLES 11 SP3 and SLES 12 kernels? Thanks, Jean Le Thursday 28 May 2015 à 19:05 +0530, Kashyap Desai a écrit : > Bjorn/Robin, > > Apologies for delay. Here is one quick suggestion as we have seen similar > issue (not exactly similar, but high probably to have same issue) while > controller is configured on VM as pass-through and VM reboot abruptly. > In that particular issue, driver interact with FW which may require chip > reset to bring controller to operation state. > > Relevant patch was submitted for only Older controller as it was only seen > for few MegaRaid controller. Below patch already try to do chip reset, but > only for limited controllers...I have attached one more patch which does > chip reset from driver load time for Thunderbolt/Invader/Fury etc. (In > your case you have Thunderbolt controller, so attached patch is required.) > > http://www.spinics.net/lists/linux-scsi/msg67288.html > > Please post the result with attached patch. > > Thanks, Kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] target: Use scsi helpers to build the sense data correctly
Instead of open coding the sense buffer construction, use
scsi scsi_build_sense_buffer() and scsi_set_sense_information()
helpers.
This patch also fixes wrong setting of descriptor format sense data
for t10-pi integrity errors.
Signed-off-by: Sagi Grimberg
---
drivers/target/target_core_spc.c | 30 +
drivers/target/target_core_transport.c | 202 -
include/target/target_core_base.h | 9 +-
3 files changed, 30 insertions(+), 211 deletions(-)
diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index a2b377e..08114bf 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -1156,32 +1156,10 @@ static sense_reason_t spc_emulate_request_sense(struct
se_cmd *cmd)
if (!rbuf)
return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
- if (!core_scsi3_ua_clear_for_request_sense(cmd, &ua_asc, &ua_ascq)) {
- /*
-* CURRENT ERROR, UNIT ATTENTION
-*/
- buf[0] = 0x70;
- buf[SPC_SENSE_KEY_OFFSET] = UNIT_ATTENTION;
-
- /*
-* The Additional Sense Code (ASC) from the UNIT ATTENTION
-*/
- buf[SPC_ASC_KEY_OFFSET] = ua_asc;
- buf[SPC_ASCQ_KEY_OFFSET] = ua_ascq;
- buf[7] = 0x0A;
- } else {
- /*
-* CURRENT ERROR, NO SENSE
-*/
- buf[0] = 0x70;
- buf[SPC_SENSE_KEY_OFFSET] = NO_SENSE;
-
- /*
-* NO ADDITIONAL SENSE INFORMATION
-*/
- buf[SPC_ASC_KEY_OFFSET] = 0x00;
- buf[7] = 0x0A;
- }
+ if (!core_scsi3_ua_clear_for_request_sense(cmd, &ua_asc, &ua_ascq))
+ scsi_build_sense_buffer(0, buf, UNIT_ATTENTION, ua_asc,
ua_ascq);
+ else
+ scsi_build_sense_buffer(0, buf, NO_SENSE, 0x0, 0x0);
memcpy(rbuf, buf, min_t(u32, sizeof(buf), cmd->data_length));
transport_kunmap_data_sg(cmd);
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index ea83dd26..33ade5f 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2708,18 +2708,6 @@ static int transport_get_sense_codes(
return 0;
}
-static
-void transport_err_sector_info(unsigned char *buffer, sector_t bad_sector)
-{
- /* Place failed LBA in sense data information descriptor 0. */
- buffer[SPC_DESC_TYPE_OFFSET] = 0; /* Information */
- buffer[SPC_ADDITIONAL_DESC_LEN_OFFSET] = 0xa;
- buffer[SPC_VALIDITY_OFFSET] = 0x80;
-
- /* Descriptor Information: failing sector */
- put_unaligned_be64(bad_sector, &buffer[12]);
-}
-
int
transport_send_check_condition_and_sense(struct se_cmd *cmd,
sense_reason_t reason, int from_transport)
@@ -2742,227 +2730,87 @@ transport_send_check_condition_and_sense(struct se_cmd
*cmd,
if (!from_transport)
cmd->se_cmd_flags |= SCF_EMULATED_TASK_SENSE;
- /*
-* Actual SENSE DATA, see SPC-3 7.23.2 SPC_SENSE_KEY_OFFSET uses
-* SENSE KEY values from include/scsi/scsi.h
-*/
+ /* Actual SENSE DATA, see SPC-3 7.23.2 */
switch (reason) {
case TCM_NO_SENSE:
- /* CURRENT ERROR */
- buffer[0] = 0x70;
- buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
- /* Not Ready */
- buffer[SPC_SENSE_KEY_OFFSET] = NOT_READY;
- /* NO ADDITIONAL SENSE INFORMATION */
- buffer[SPC_ASC_KEY_OFFSET] = 0;
- buffer[SPC_ASCQ_KEY_OFFSET] = 0;
+ scsi_build_sense_buffer(0, buffer, NOT_READY, 0x0, 0x0);
break;
case TCM_NON_EXISTENT_LUN:
- /* CURRENT ERROR */
- buffer[0] = 0x70;
- buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
- /* ILLEGAL REQUEST */
- buffer[SPC_SENSE_KEY_OFFSET] = ILLEGAL_REQUEST;
/* LOGICAL UNIT NOT SUPPORTED */
- buffer[SPC_ASC_KEY_OFFSET] = 0x25;
+ scsi_build_sense_buffer(0, buffer, ILLEGAL_REQUEST, 0x25, 0x0);
break;
case TCM_UNSUPPORTED_SCSI_OPCODE:
case TCM_SECTOR_COUNT_TOO_MANY:
- /* CURRENT ERROR */
- buffer[0] = 0x70;
- buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
- /* ILLEGAL REQUEST */
- buffer[SPC_SENSE_KEY_OFFSET] = ILLEGAL_REQUEST;
/* INVALID COMMAND OPERATION CODE */
- buffer[SPC_ASC_KEY_OFFSET] = 0x20;
+ scsi_build_sense_buffer(0, buffer, ILLEGAL_REQUEST, 0x20, 0x0);
break;
case TCM_UNKNOWN_MODE_PAGE:
- /* CURRENT ERROR */
- buffer[0] = 0x70;
- buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
- /* I
Re: [PATCH 0/3] libfc patches for kernel v4.2
On Fri, 2015-06-05 at 14:20 -0700, Vasu Dev wrote: > These libfc fixes are for kernel 4.2 and with two patches CCed for stable > kernel also, those two could be picked for current 4.1 cycle now but in case > too late for current 4.1 then anyway should get picked up by 4.1 stable > kernel later. > > These patches were posted by Bart Van Assche at open-fcoe.org and then > I updated them per discussion on original patches to pick revised patch > and add related comments at: > > http://lists.open-fcoe.org/pipermail/fcoe-devel/2015-May/012467.html > > > Bart Van Assche (3): > libfc: Fix fc_fcp_cleanup_each_cmd() > libfc: Fix fc_exch_recv_req() error path > libfc: Fix a typo in a source code comment > > > drivers/scsi/libfc/fc_exch.c |8 > drivers/scsi/libfc/fc_fcp.c | 21 ++--- > 2 files changed, 22 insertions(+), 7 deletions(-) > Hello James and Christoph, This patch series is not applied as of now, so can you apply the patch series ? Thanks, Vasu -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 98171] [Regression] Marvell SE91xx SATA 3 controllers not recognized correctly
https://bugzilla.kernel.org/show_bug.cgi?id=98171 --- Comment #1 from nuc...@hotmail.com --- > This is a regression against 3.14? There was only one change affecting > mvsas between those kernels and that was the libsas change: > > commit bc6e7c4b0d1a1f742d96556f63d68f17f4e232c3 > Author: Dan Williams > Date: Fri Mar 14 13:52:48 2014 -0700 > > libata, libsas: kill pm_result and related cleanup > > Does reverting that make the problem go away? > It's a regression starting with linux 3.15, meaning everything still worked with linux 3.14. I have tried reverting that patch from linux-3.15.10 vanilla sources but it fails... I don't know why, maybe I'm just not leet enough: Hunk #1 succeeded at 5364 (offset 13 lines). Hunk #2 succeeded at 5388 (offset 13 lines). Hunk #3 FAILED at 5390. Hunk #4 succeeded at 5506 (offset 13 lines). Hunk #5 succeeded at 5532 (offset 13 lines). 1 out of 5 hunks FAILED -- saving rejects to file drivers/ata/libata-core.c.rej patching file drivers/ata/libata-eh.c patching file drivers/scsi/libsas/sas_ata.c patching file include/linux/libata.h Hunk #1 succeeded at 850 (offset 2 lines). Hunk #2 FAILED at 1140. 1 out of 2 hunks FAILED -- saving rejects to file include/linux/libata.h.rej patching file include/scsi/libsas.h patch unexpectedly ends in middle of line Hunk #1 succeeded at 172 with fuzz 1. What shall I do? Regards, Philip -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Backport of a fix for HPSA (Disabling a disabled device problem during kdump) driver
On Fri, May 22, 2015 at 12:19:16PM -0700, Vinson Lee wrote: > On Sat, May 2, 2015 at 10:56 AM, Greg KH wrote: > > On Mon, Apr 27, 2015 at 03:10:35PM +0200, Tomas Henzl wrote: > >> On 04/27/2015 02:55 PM, Greg KH wrote: > >> > On Mon, Apr 27, 2015 at 02:17:32PM +0200, Tomas Henzl wrote: > >> >> On 04/26/2015 11:27 AM, Greg KH wrote: > >> >>> On Mon, Apr 13, 2015 at 03:18:44PM +0200, Tomas Henzl wrote: > >> On 04/11/2015 12:45 AM, Vinson Lee wrote: > >> > On Tue, Jan 27, 2015 at 4:18 PM, Greg KH wrote: > >> >> On Tue, Jan 06, 2015 at 05:15:19PM +0100, Tomas Henzl wrote: > >> >>> On 01/05/2015 07:41 PM, Masoud Sharbiani wrote: > >> Dear stable maintainers, > >> Can you please backport commitid > >> 132aa220b45d60e9b20def1e9d8be9422eed9616 > >> (hpsa: refine the pci enable/disable handling) to 3.10 stable > >> (and > >> earlier, if applicable)? > >> >>> Please do not apply this patch isolated from his friend, the > >> >>> 859c75aba20264d87dd026bab0d0ca3bff385955 hpsa: add missing > >> >>> pci_set_master in kdump path > >> >>> needs to be applied together with the > >> >>> 132aa220b45d60e9b20def1e9d8be9422eed9616 . > >> >>> > >> >>> In addition to that, after the original issue goes away you may > >> >>> notice sometimes > >> >>> an unhandled irq 16 message, to fix this a patch is posted > >> >>> here http://www.spinics.net/lists/linux-scsi/msg80316.html > >> >>> This patch still awaits a maintainers review though. > >> >>> > >> >>> Probably the best idea is to wait until the issue is solved > >> >>> completely. > >> >> I'll wait, when it all gets worked out, please let stable@ know what > >> >> patches to apply where. > >> >> > >> >> thanks, > >> >> > >> >> greg k-h > >> >> -- > >> >> To unsubscribe from this list: send the line "unsubscribe stable" in > >> >> the body of a message to majord...@vger.kernel.org > >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > Hi, Thomas. > >> > > >> > The unhandled irq 16 issue seems to be fixed by 4.0-rc1 commit "hpsa: > >> > turn off interrupts when kdump starts". > >> > > >> > Are the following patches suitable for stable now? > >> Yes, I believe they are, just note that > >> 03741d9 hpsa: fix memory leak in kdump hard reset > >> is not a part of that group we discussed before, but it may be added > >> to stable too. > >> > >> Cheers, > >> Tomas > >> > >> > 3b74729 hpsa: turn off interrupts when kdump starts > >> > 03741d9 hpsa: fix memory leak in kdump hard reset > >> > 859c75a hpsa: add missing pci_set_master in kdump path > >> > 132aa22 hpsa: refine the pci enable/disable handling > >> >>> So what order, and to what stable tree(s) do you want these applied to? > >> >>> They seem to span a number of kernel versions, so I'm not quite sure > >> >>> what you are wanting me to do. > >> >> Please add it in this order > >> >> 1. 132aa220b4 hpsa: refine the pci enable/disable handling > >> >> 2. 859c75aba2 hpsa: add missing pci_set_master in kdump path > >> >>The first two patches create the fix Masoud has asked for originally > >> >> to port to stable. > >> >> 3. 3b74729878 hpsa: turn off interrupts when kdump starts > >> >>The third should be added too, it fixes an issue made visible by the > >> >> first patch > >> >> > >> >> The fourth patch > >> >> 03741d956e hpsa: fix memory leak in kdump hard reset > >> >> is completely unrelated to the first group, so it may be added after or > >> >> before > >> >> or in the same sequence as it is in the mainline - that is before the > >> >> third patch. > >> >> This patch is tiny error path fix - not sure if important enough for > >> >> stable. > >> > Which stable tree(s) do you want these applied to? As these "span" > >> > different kernel versions, I have no idea of what to do here. > >> > >> Masoud has asked for the inclusion, I think that what he wrote was - "3.10 > >> stable (and earlier, if applicable)", > >> I don't know much about stable so I can't decide to which tree(s) the > >> series should be ported. > > > > Ok, I'll wait for someone to clarify before doing anything here. > > > > thanks, > > > > greg k-h > > > The first and second patches are from upstream 3.18. The third patch > is from upstream 4.0. > > Please use the following list of kernels and patches for backporting. > > 3.18, 3.19 > 3b74729878 hpsa: turn off interrupts when kdump starts > > <= 3.17 > 132aa220b4 hpsa: refine the pci enable/disable handling > 859c75aba2 hpsa: add missing pci_set_master in kdump path These two worked for 3.10 and 3.14-stable. > 3b74729878 hpsa: turn off interrupts when kdump starts This one did not apply, so I can't add it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a
[PATCH] virtio scsi: fix unused variable warning
Fixes:
drivers/scsi/virtio_scsi.c: In function 'virtscsi_probe':
drivers/scsi/virtio_scsi.c:952:11: warning: unused variable 'host_prot'
[-Wunused-variable]
int err, host_prot;
^
Signed-off-by: Stephen Rothwell
---
drivers/scsi/virtio_scsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 285f77544c36..7dbbb29d24c6 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -949,7 +949,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
{
struct Scsi_Host *shost;
struct virtio_scsi *vscsi;
- int err, host_prot;
+ int err;
u32 sg_elems, num_targets;
u32 cmd_per_lun;
u32 num_queues;
@@ -1009,6 +1009,8 @@ static int virtscsi_probe(struct virtio_device *vdev)
#ifdef CONFIG_BLK_DEV_INTEGRITY
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_T10_PI)) {
+ int host_prot;
+
host_prot = SHOST_DIF_TYPE1_PROTECTION |
SHOST_DIF_TYPE2_PROTECTION |
SHOST_DIF_TYPE3_PROTECTION |
SHOST_DIX_TYPE1_PROTECTION |
SHOST_DIX_TYPE2_PROTECTION |
SHOST_DIX_TYPE3_PROTECTION;
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpCXD95hm3gR.pgp
Description: OpenPGP digital signature
[PATCH] hpsa: convert DEVICE_ATTR to RO|WO|RW and show methods must use scnprintf
Changed DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WO|RW.
This also forced some show/store function names to change.
Changed all show method sprint/snprintf usage to scnprintf per
Documentation/filesystems/sysfs.txt.
Signed-off-by: Shane Seymour
---
--- a/drivers/scsi/hpsa.c 2015-06-25 15:52:15.633031319 -0500
+++ b/drivers/scsi/hpsa.c 2015-06-29 17:28:24.628475369 -0500
@@ -376,7 +376,7 @@ static int check_for_busy(struct ctlr_in
}
static u32 lockup_detected(struct ctlr_info *h);
-static ssize_t host_show_lockup_detected(struct device *dev,
+static ssize_t lockup_detected_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
int ld;
@@ -386,10 +386,10 @@ static ssize_t host_show_lockup_detected
h = shost_to_hba(shost);
ld = lockup_detected(h);
- return sprintf(buf, "ld=%d\n", ld);
+ return scnprintf(buf, PAGE_SIZE, "ld=%d\n", ld);
}
-static ssize_t host_store_hp_ssd_smart_path_status(struct device *dev,
+static ssize_t hp_ssd_smart_path_status_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -413,7 +413,7 @@ static ssize_t host_store_hp_ssd_smart_p
return count;
}
-static ssize_t host_store_raid_offload_debug(struct device *dev,
+static ssize_t raid_offload_debug_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -438,7 +438,7 @@ static ssize_t host_store_raid_offload_d
return count;
}
-static ssize_t host_store_rescan(struct device *dev,
+static ssize_t rescan_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -449,7 +449,7 @@ static ssize_t host_store_rescan(struct
return count;
}
-static ssize_t host_show_firmware_revision(struct device *dev,
+static ssize_t firmware_revision_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct ctlr_info *h;
@@ -460,40 +460,40 @@ static ssize_t host_show_firmware_revisi
if (!h->hba_inquiry_data)
return 0;
fwrev = &h->hba_inquiry_data[32];
- return snprintf(buf, 20, "%c%c%c%c\n",
+ return scnprintf(buf, 20, "%c%c%c%c\n",
fwrev[0], fwrev[1], fwrev[2], fwrev[3]);
}
-static ssize_t host_show_commands_outstanding(struct device *dev,
+static ssize_t commands_outstanding_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct Scsi_Host *shost = class_to_shost(dev);
struct ctlr_info *h = shost_to_hba(shost);
- return snprintf(buf, 20, "%d\n",
+ return scnprintf(buf, 20, "%d\n",
atomic_read(&h->commands_outstanding));
}
-static ssize_t host_show_transport_mode(struct device *dev,
+static ssize_t transport_mode_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct ctlr_info *h;
struct Scsi_Host *shost = class_to_shost(dev);
h = shost_to_hba(shost);
- return snprintf(buf, 20, "%s\n",
+ return scnprintf(buf, 20, "%s\n",
h->transMethod & CFGTBL_Trans_Performant ?
"performant" : "simple");
}
-static ssize_t host_show_hp_ssd_smart_path_status(struct device *dev,
+static ssize_t hp_ssd_smart_path_status_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct ctlr_info *h;
struct Scsi_Host *shost = class_to_shost(dev);
h = shost_to_hba(shost);
- return snprintf(buf, 30, "HP SSD Smart Path %s\n",
+ return scnprintf(buf, 30, "HP SSD Smart Path %s\n",
(h->acciopath_status == 1) ? "enabled" : "disabled");
}
@@ -582,14 +582,14 @@ static int ctlr_needs_abort_tags_swizzle
ARRAY_SIZE(needs_abort_tags_swizzled), board_id);
}
-static ssize_t host_show_resettable(struct device *dev,
+static ssize_t resettable_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct ctlr_info *h;
struct Scsi_Host *shost = class_to_shost(dev);
h = shost_to_hba(shost);
- return snprintf(buf, 20, "%d\n", ctlr_is_resettable(h->board_id));
+ return scnprintf(buf, 20, "%d\n", ctlr_is_resettable(h->board_id));
}
static inline int is_logical_dev_addr_mode(unsigned char scsi3addr[])
@@ -631,7 +631,7 @@ static ssize_t raid_level_show(struct de
/* Is this even a logical drive? */
if (!is_logical_dev_addr_mode(hdev->scsi3addr)) {
spin_unlock_irqrestore(&h->lock, flags);
- l = snprintf(buf, PAGE_SIZE, "N/A\n");
+ l = scnprintf(buf, PAGE_SIZE, "N/A\n");
return l;
}
@@ -639,7 +639,7
[PATCH 00/20] mpt3sas: driver update
This patch set contains all the features and defect fixes from Phase4 to Phase8. Except below patch, all other patches have Reviewed-by signature from either Martin K. Petersen, Johannes Thumshirn, Tomas Henzl and Joe Lawrence. Thanks for reviewing these patches. [PATCH v2 16/20] [SCSI] mpt3sas: Added support for customer specific branding I am posting this patch set once again by promoting all the patches to v2, so that it will be easy to pick up this patch set for next kernel release. Thanks, Sreekanth Sreekanth Reddy (20): [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support [SCSI] mpt3sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state. [SCSI] mpt3sas: Don't block the drive when drive addition under the control of SML [SCSI] mpt3sas: Remove redundancy code while freeing the controller resources. [SCSI] mpt3sas: MPI 2.5 Rev I (2.5.4) specifications. [SCSI] mpt3sas: Provides the physical location of sas drives [SCSI] mpt3sas: Bump mpt3sas Driver version to v5.100.00.00 [SCSI] mpt3sas: Update MPI2 strings to MPI2.5 [SCSI] mpt3sas: MPI 2.5 Rev J (2.5.5) specification and 2.00.34 header files [SCSI] mpt3sas: Add branding string support for OEM's HBA [SCSI] mpt3sas: Add branding string support for OEM custom HBA [SCSI] mpt3sas: Bump mpt3sas driver version to v6.100.00.00 [SCSI] mpt3sas: MPI 2.5 Rev K (2.5.6) specifications [SCSI] mpt3sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081 [SCSI] mpt3sas: Return host busy error status to SML when DMA mapping of scatter gather list fails for a SCSI command [SCSI] mpt3sas: Added support for customer specific branding [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API [SCSI] mpt3sas: Call dma_mapping_error() API after mapping an address with dma_map_single() API [SCSI] mpt3sas: When device is blocked followed by unblock fails, unfreeze the I/Os [SCSI] mpt3sas : Bump mpt3sas driver version to 9.100.00.00 drivers/scsi/mpt3sas/mpi/mpi2.h | 8 +- drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 52 - drivers/scsi/mpt3sas/mpi/mpi2_ioc.h | 4 +- drivers/scsi/mpt3sas/mpi/mpi2_tool.h | 4 +- drivers/scsi/mpt3sas/mpt3sas_base.c | 310 +--- drivers/scsi/mpt3sas/mpt3sas_base.h | 57 - drivers/scsi/mpt3sas/mpt3sas_scsih.c | 343 ++- drivers/scsi/mpt3sas/mpt3sas_transport.c | 22 +- 8 files changed, 694 insertions(+), 106 deletions(-) -- 2.0.2 -- 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 02/20] [SCSI] mpt3sas: 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 would be issued.
3.If IOC is in reset state then driver will wait for 10 seconds to exit out of
reset state.
If the HBA continues to be in reset state, then the HBA wouldn't be claimed
by the driver.
Changes in v1:
If PCI Recovery is on then return with -EFAULT in the function
_base_wait_for_iocstate().
Changes in v2:
Patch version change only.
Signed-off-by: Sreekanth Reddy
Reviewed-by: Martin K. Petersen
Reviewed-by: Tomas Henzl
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 68 +
1 file changed, 68 insertions(+)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 63a8588..0410cc5 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3189,6 +3189,9 @@ _base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32
ioc_state, int timeout,
* Notes: MPI2_HIS_IOC2SYS_DB_STATUS - set to one when IOC writes to doorbell.
*/
static int
+_base_diag_reset(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+
+static int
_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout,
int sleep_flag)
{
@@ -3731,6 +3734,64 @@ _base_get_port_facts(struct MPT3SAS_ADAPTER *ioc, int
port, int sleep_flag)
}
/**
+ * _base_wait_for_iocstate - Wait until the card is in READY or OPERATIONAL
+ * @ioc: per adapter object
+ * @timeout:
+ * @sleep_flag: CAN_SLEEP or NO_SLEEP
+ *
+ * Returns 0 for success, non-zero for failure.
+ */
+static int
+_base_wait_for_iocstate(struct MPT3SAS_ADAPTER *ioc, int timeout,
+ int sleep_flag)
+{
+ u32 ioc_state;
+ int rc;
+
+ dinitprintk(ioc, printk(MPT3SAS_FMT "%s\n", ioc->name,
+ __func__));
+
+ if (ioc->pci_error_recovery) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ "%s: host in pci error recovery\n", ioc->name, __func__));
+ return -EFAULT;
+ }
+
+ ioc_state = mpt3sas_base_get_iocstate(ioc, 0);
+ dhsprintk(ioc, printk(MPT3SAS_FMT "%s: ioc_state(0x%08x)\n",
+ ioc->name, __func__, ioc_state));
+
+ if (((ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_READY) ||
+ (ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_OPERATIONAL)
+ return 0;
+
+ if (ioc_state & MPI2_DOORBELL_USED) {
+ dhsprintk(ioc, printk(MPT3SAS_FMT
+ "unexpected doorbell active!\n", ioc->name));
+ goto issue_diag_reset;
+ }
+
+ if ((ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_FAULT) {
+ mpt3sas_base_fault_info(ioc, ioc_state &
+ MPI2_DOORBELL_DATA_MASK);
+ goto issue_diag_reset;
+ }
+
+ ioc_state = _base_wait_on_iocstate(ioc, MPI2_IOC_STATE_READY,
+ timeout, sleep_flag);
+ if (ioc_state) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ "%s: failed going to ready state (ioc_state=0x%x)\n",
+ ioc->name, __func__, ioc_state));
+ return -EFAULT;
+ }
+
+ issue_diag_reset:
+ rc = _base_diag_reset(ioc, sleep_flag);
+ return rc;
+}
+
+/**
* _base_get_ioc_facts - obtain ioc facts reply and save in ioc
* @ioc: per adapter object
* @sleep_flag: CAN_SLEEP or NO_SLEEP
@@ -3748,6 +3809,13 @@ _base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int
sleep_flag)
dinitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
__func__));
+ r = _base_wait_for_iocstate(ioc, 10, sleep_flag);
+ if (r) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ "%s: failed getting to correct state\n",
+ ioc->name, __func__));
+ return r;
+ }
mpi_reply_sz = sizeof(Mpi2IOCFactsReply_t);
mpi_request_sz = sizeof(Mpi2IOCFactsRequest_t);
memset(&mpi_request, 0, mpi_request_sz);
--
2.0.2
--
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 07/20] [SCSI] mpt3sas: Bump mpt3sas Driver version to v5.100.00.00
Bump mpt3sas Driver version to v5.100.00.00 Changes in v2: Patch version change only. Signed-off-by: Sreekanth Reddy Reviewed-by: Martin K. Petersen Reviewed-by: Johannes Thumshirn --- drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index da82a97..d635612 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -71,8 +71,8 @@ #define MPT3SAS_DRIVER_NAME"mpt3sas" #define MPT3SAS_AUTHOR "Avago Technologies " #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver" -#define MPT3SAS_DRIVER_VERSION "04.100.00.00" -#define MPT3SAS_MAJOR_VERSION 4 +#define MPT3SAS_DRIVER_VERSION "05.100.00.00" +#define MPT3SAS_MAJOR_VERSION 5 #define MPT3SAS_MINOR_VERSION 100 #define MPT3SAS_BUILD_VERSION 0 #define MPT3SAS_RELEASE_VERSION00 -- 2.0.2 -- 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 08/20] [SCSI] mpt3sas: Update MPI2 strings to MPI2.5
Update MPI2 strings to MPI2.5.
Changes in v2:
Patch version change only.
Signed-off-by: Sreekanth Reddy
Reviewed-by: Martin K. Petersen
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 3 +--
drivers/scsi/mpt3sas/mpt3sas_base.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index bf2d7dc..8730160 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3924,7 +3924,7 @@ _base_send_ioc_init(struct MPT3SAS_ADAPTER *ioc, int
sleep_flag)
mpi_request.WhoInit = MPI2_WHOINIT_HOST_DRIVER;
mpi_request.VF_ID = 0; /* TODO */
mpi_request.VP_ID = 0;
- mpi_request.MsgVersion = cpu_to_le16(MPI2_VERSION);
+ mpi_request.MsgVersion = cpu_to_le16(MPI25_VERSION);
mpi_request.HeaderVersion = cpu_to_le16(MPI2_HEADER_VERSION);
if (_base_is_controller_msix_enabled(ioc))
@@ -4793,7 +4793,6 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
ioc->build_sg_scmd = &_base_build_sg_scmd_ieee;
ioc->build_sg = &_base_build_sg_ieee;
ioc->build_zero_len_sge = &_base_build_zero_len_sge_ieee;
- ioc->mpi25 = 1;
ioc->sge_size_ieee = sizeof(Mpi2IeeeSgeSimple64_t);
/*
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index d635612..c0c774f 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -826,7 +826,6 @@ struct MPT3SAS_ADAPTER {
MPT_BUILD_SG_SCMD build_sg_scmd;
MPT_BUILD_SGbuild_sg;
MPT_BUILD_ZERO_LEN_SGE build_zero_len_sge;
- u8 mpi25;
u16 sge_size_ieee;
/* function ptr for MPI sg elements only */
--
2.0.2
--
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 03/20] [SCSI] mpt3sas: Don't block the drive when drive addition under the control of SML
During hot-plugging of a disk(having a flaky link), the disk addition
stops and any further disk addition or removal doesn't happen on that
controller.
This is because, when driver receives DELAY_NOT_RESPONDING event for a disk
while it is undergoing addition at the SCSI Transport layer, the driver
would block the I/O to that disk resulting in a deadlock. i.e the disk
addition work couldn't be completed at the SCSI Transport Layer as it
can't send any I/Os (such as Inquiry, Report LUNs etc) to the disk as
I/Os are blocked to this drive. Also any subsequent device removal
(TARGET_NOT_RESPONDING) or link update(RC_PHY_CHANGED) event couldn't be
processed as they are in the queue to get processed after disk addition
event.
Description of Change:
Don't block the drive when drive addition is under the control of SML.
So that SML won't be blocked of issuing the device dicovery commands
(such as Inquiry, Report LUNs etc).
Changes in v2:
Patch version change only.
Signed-off-by: Sreekanth Reddy
Reviewed-by: Martin K. Petersen
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 4 +++-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 7 +++
drivers/scsi/mpt3sas/mpt3sas_transport.c | 18 ++
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index a7386ee..01d92db 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -301,7 +301,8 @@ struct _internal_cmd {
* @responding: used in _scsih_sas_device_mark_responding
* @fast_path: fast path feature enable bit
* @pfa_led_on: flag for PFA LED status
- *
+ * @pend_sas_rphy_add: flag to check if device is in sas_rphy_add()
+ * addition routine.
*/
struct _sas_device {
struct list_head list;
@@ -322,6 +323,7 @@ struct _sas_device {
u8 responding;
u8 fast_path;
u8 pfa_led_on;
+ u8 pend_sas_rphy_add;
};
/**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 5a97e32..d457dba 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2644,6 +2644,11 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16
handle)
{
struct MPT3SAS_DEVICE *sas_device_priv_data;
struct scsi_device *sdev;
+ struct _sas_device *sas_device;
+
+ sas_device = _scsih_sas_device_find_by_handle(ioc, handle);
+ if (!sas_device)
+ return;
shost_for_each_device(sdev, ioc->shost) {
sas_device_priv_data = sdev->hostdata;
@@ -2653,6 +2658,8 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc, u16
handle)
continue;
if (sas_device_priv_data->block)
continue;
+ if (sas_device->pend_sas_rphy_add)
+ continue;
sas_device_priv_data->block = 1;
scsi_internal_device_block(sdev);
sdev_printk(KERN_INFO, sdev,
diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c
b/drivers/scsi/mpt3sas/mpt3sas_transport.c
index efb98af..7a7aa68 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_transport.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c
@@ -649,6 +649,7 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc, u16
handle,
unsigned long flags;
struct _sas_node *sas_node;
struct sas_rphy *rphy;
+ struct _sas_device *sas_device = NULL;
int i;
struct sas_port *port;
@@ -731,10 +732,27 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc,
u16 handle,
mpt3sas_port->remote_identify.device_type);
rphy->identify = mpt3sas_port->remote_identify;
+
+ if (mpt3sas_port->remote_identify.device_type == SAS_END_DEVICE) {
+ sas_device = mpt3sas_scsih_sas_device_find_by_sas_address(ioc,
+ mpt3sas_port->remote_identify.sas_address);
+ if (!sas_device) {
+ dfailprintk(ioc, printk(MPT3SAS_FMT
+ "failure at %s:%d/%s()!\n",
+ ioc->name, __FILE__, __LINE__, __func__));
+ goto out_fail;
+ }
+ sas_device->pend_sas_rphy_add = 1;
+ }
+
if ((sas_rphy_add(rphy))) {
pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
ioc->name, __FILE__, __LINE__, __func__);
}
+
+ if (mpt3sas_port->remote_identify.device_type == SAS_END_DEVICE)
+ sas_device->pend_sas_rphy_add = 0;
+
if ((ioc->logging_level & MPT_DEBUG_TRANSPORT))
dev_printk(KERN_INFO, &rphy->dev,
"add: handle(0x%04x), sas_addr(0x%016llx)\n",
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majo
[PATCH v2 18/20] [SCSI] mpt3sas: Call dma_mapping_error() API after mapping an address with dma_map_single() API
Added dma_mapping_error() API after mapping an address with dma_map_single()
API.
Otherwise when CONFIG_DMA_API_DEBUG is enabled in the kernel, then it complains
about mpt3sas driver not calling dma_mapping_error after mapping an address with
dma_map_single
Changes in v2:
Patch version change only.
Signed-off-by: Sreekanth Reddy
Reviewed-by: Martin K. Petersen
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/mpt3sas/mpt3sas_transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c
b/drivers/scsi/mpt3sas/mpt3sas_transport.c
index 7a7aa68..70fd019 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_transport.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c
@@ -1964,7 +1964,7 @@ _transport_smp_handler(struct Scsi_Host *shost, struct
sas_rphy *rphy,
} else {
dma_addr_out = pci_map_single(ioc->pdev, bio_data(req->bio),
blk_rq_bytes(req), PCI_DMA_BIDIRECTIONAL);
- if (!dma_addr_out) {
+ if (pci_dma_mapping_error(ioc->pdev, dma_addr_out)) {
pr_info(MPT3SAS_FMT "%s(): DMA Addr out = NULL\n",
ioc->name, __func__);
rc = -ENOMEM;
@@ -1986,7 +1986,7 @@ _transport_smp_handler(struct Scsi_Host *shost, struct
sas_rphy *rphy,
} else {
dma_addr_in = pci_map_single(ioc->pdev, bio_data(rsp->bio),
blk_rq_bytes(rsp), PCI_DMA_BIDIRECTIONAL);
- if (!dma_addr_in) {
+ if (pci_dma_mapping_error(ioc->pdev, dma_addr_in)) {
pr_info(MPT3SAS_FMT "%s(): DMA Addr in = NULL\n",
ioc->name, __func__);
rc = -ENOMEM;
--
2.0.2
--
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 19/20] [SCSI] mpt3sas: When device is blocked followed by unblock fails, unfreeze the I/Os
Issue: When the disks are getting discovered and assigned device
handles by the kernel, a device block followed by an unblock
(due to broadcast primitives) issued by the driver is
interspersed by the kernel changing the state of the device.
Therefore the unblock by the driver results in a no operation
within the kernel API.
To fix this one, the below patch checks the return of the unblock API
and performs a block followed by an unblock to unfreeze the block
layer's I/O queue. Sufficient checks and prints are also added in the
driver to identify this condition caused by the kernel.
Changes in v2:
Patch version change only.
Signed-off-by: Sreekanth Reddy
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 89 ++--
1 file changed, 75 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index a136ec8..7e5926c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2605,6 +2605,75 @@ _scsih_fw_event_cleanup_queue(struct MPT3SAS_ADAPTER
*ioc)
}
/**
+ * _scsih_internal_device_block - block the sdev device
+ * @sdev: per device object
+ * @sas_device_priv_data : per device driver private data
+ *
+ * make sure device is blocked without error, if not
+ * print an error
+ */
+static void
+_scsih_internal_device_block(struct scsi_device *sdev,
+ struct MPT3SAS_DEVICE *sas_device_priv_data)
+{
+ int r = 0;
+
+ sdev_printk(KERN_INFO, sdev, "device_block, handle(0x%04x)\n",
+ sas_device_priv_data->sas_target->handle);
+ sas_device_priv_data->block = 1;
+
+ r = scsi_internal_device_block(sdev);
+ if (r == -EINVAL)
+ sdev_printk(KERN_WARNING, sdev,
+ "device_block failed with return(%d) for handle(0x%04x)\n",
+ sas_device_priv_data->sas_target->handle, r);
+}
+
+/**
+ * _scsih_internal_device_unblock - unblock the sdev device
+ * @sdev: per device object
+ * @sas_device_priv_data : per device driver private data
+ * make sure device is unblocked without error, if not retry
+ * by blocking and then unblocking
+ */
+
+static void
+_scsih_internal_device_unblock(struct scsi_device *sdev,
+ struct MPT3SAS_DEVICE *sas_device_priv_data)
+{
+ int r = 0;
+
+ sdev_printk(KERN_WARNING, sdev, "device_unblock and setting to running,
"
+ "handle(0x%04x)\n", sas_device_priv_data->sas_target->handle);
+ sas_device_priv_data->block = 0;
+ r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+ if (r == -EINVAL) {
+ /* The device has been set to SDEV_RUNNING by SD layer during
+* device addition but the request queue is still stopped by
+* our earlier block call. We need to perform a block again
+* to get the device to SDEV_BLOCK and then to SDEV_RUNNING */
+
+ sdev_printk(KERN_WARNING, sdev,
+ "device_unblock failed with return(%d) for handle(0x%04x) "
+ "performing a block followed by an unblock\n",
+ sas_device_priv_data->sas_target->handle, r);
+ sas_device_priv_data->block = 1;
+ r = scsi_internal_device_block(sdev);
+ if (r)
+ sdev_printk(KERN_WARNING, sdev, "retried device_block "
+ "failed with return(%d) for handle(0x%04x)\n",
+ sas_device_priv_data->sas_target->handle, r);
+
+ sas_device_priv_data->block = 0;
+ r = scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+ if (r)
+ sdev_printk(KERN_WARNING, sdev, "retried device_unblock"
+ " failed with return(%d) for handle(0x%04x)\n",
+ sas_device_priv_data->sas_target->handle, r);
+ }
+}
+
+/**
* _scsih_ublock_io_all_device - unblock every device
* @ioc: per adapter object
*
@@ -2623,11 +2692,10 @@ _scsih_ublock_io_all_device(struct MPT3SAS_ADAPTER *ioc)
if (!sas_device_priv_data->block)
continue;
- sas_device_priv_data->block = 0;
dewtprintk(ioc, sdev_printk(KERN_INFO, sdev,
"device_running, handle(0x%04x)\n",
sas_device_priv_data->sas_target->handle));
- scsi_internal_device_unblock(sdev, SDEV_RUNNING);
+ _scsih_internal_device_unblock(sdev, sas_device_priv_data);
}
}
@@ -2652,10 +2720,9 @@ _scsih_ublock_io_device(struct MPT3SAS_ADAPTER *ioc, u64
sas_address)
if (sas_device_priv_data->sas_target->sas_address
!= sas_address)
continue;
- if (sas_device_priv_data->block) {
- sas_device_priv_data->block = 0;
-
[PATCH v2 17/20] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API
Created a thread using alloc_ordered_workqueue() API in order to process
the works from firmware Work-queue sequentially instead of
create_singlethread_workqueue() API.
Changes in v1:
No need to check for backport compatibility in the upstream kernel.
so removing the else section where driver use
create_singlethread_workqueue() API if alloc_ordered_workqueue() API is
not defined, This else section is not required since in the latest upstream
kernel this alloc_ordered_workqueue() API is always defined.
Changes in v2:
Patch version change only.
Signed-off-by: Sreekanth Reddy
Reviewed-by: Martin K. Petersen
Reviewed-by: Joe Lawrence
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 49c412b..a136ec8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -8024,8 +8024,8 @@ _scsih_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
/* event thread */
snprintf(ioc->firmware_event_name, sizeof(ioc->firmware_event_name),
"fw_event%d", ioc->id);
- ioc->firmware_event_thread = create_singlethread_workqueue(
- ioc->firmware_event_name);
+ ioc->firmware_event_thread = alloc_ordered_workqueue(
+ ioc->firmware_event_name, WQ_MEM_RECLAIM);
if (!ioc->firmware_event_thread) {
pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
ioc->name, __FILE__, __LINE__, __func__);
--
2.0.2
--
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 20/20] [SCSI] mpt3sas : Bump mpt3sas driver version to 9.100.00.00
Bump mpt3sas driver version to 9.100.00.00 Changes in v2: Patch version change only. Signed-off-by: Sreekanth Reddy Reviewed-by: Martin K. Petersen Reviewed-by: Johannes Thumshirn --- drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h index 87e9000..f0e462b 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.h +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h @@ -71,8 +71,8 @@ #define MPT3SAS_DRIVER_NAME"mpt3sas" #define MPT3SAS_AUTHOR "Avago Technologies " #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver" -#define MPT3SAS_DRIVER_VERSION "06.100.00.00" -#define MPT3SAS_MAJOR_VERSION 6 +#define MPT3SAS_DRIVER_VERSION "09.100.00.00" +#define MPT3SAS_MAJOR_VERSION 9 #define MPT3SAS_MINOR_VERSION 100 #define MPT3SAS_BUILD_VERSION 0 #define MPT3SAS_RELEASE_VERSION00 -- 2.0.2 -- 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
