- 11 Nov, 2015 10 commits
-
-
Sreekanth Reddy authored
1. Do not enable MSI-X vectors for SAS2008 B0 controllers 2. Enable a single MSI-X vector for the following controller: a. SAS2004 b. SAS2008 c. SAS2008_1 d. SAS2008_2 e. SAS2008_3 f. SAS2116_1 g. SAS2116_2 3. Enable Combined Reply Post Queue Support (i.e. 96 MSI-X vectors) for Gen3 Invader/Fury C0 and above revision HBAs 4. Enable Combined Reply Post Queue Support (i.e. 96 MSI-X vectors) for all Intruder and Cutlass HBAs Signed-off-by:
Sreekanth Reddy <Sreekanth.Reddy@avagotech.com> Acked-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Sreekanth Reddy authored
Avoid sending PHYDISK_HIDDEN RAID action requests to SAS2 controllers since they don't support it. Also enable fast_path only for SAS3 HBAs. Signed-off-by:
-
Sreekanth Reddy authored
Gen2 HBAs use MPI scatter-gather lists whereas Gen3 HBAs use IEEE scatter-gather lists. Modify the common code part in such a way that it will build IEEE SGL tables for Gen3 HBAs and MPI SGL tables for Gen2 HBAs. Signed-off-by:
-
Sreekanth Reddy authored
Currently there is a logging level option provided for each of our drivers in the kernel configuration utility. Users can enable this option to get more verbose information. By default it is enabled. Only when this option is enabled will the functions which display the required information get compiled in. As we are merging the both drivers we can no longer provide this configuration option. Remove the SCSI_MPTXSAS_LOGGING entry from Kconfig and unconditionally enable logging (by removing the #ifdef CONFIG_SCSI_MPT3SAS_LOGGING preprocessor check conditions) so that all functions which are defined to display more verbose information get compiled in. Signed-off-by:
-
Sreekanth Reddy authored
1. Use 'hba_mpi_version_belonged' IOC varable to uniquely identify each individual generation driver functionality at runtime. 2. Declare global variable 'driver_name' and use this variable while reserving PCI regions and while allocating the IRQs. Signed-off-by:
-
Sreekanth Reddy authored
Remove .c and .h files which are no longer needed from mpt2sas driver. We are reusing this code from mpt3sas. Signed-off-by:
-
Sreekanth Reddy authored
1. Create a mpt2sas_module.c file for mpt2sas where GEN2 HBA devices register with PCI, SML, IOCTL subsystems. 2. Updated the Makefile to use the object files from mpt3sas folder. 3. Defined a compilation flag SCSI_MPT2SAS which can be used to not include those sections of code from mpt3sas driver which are not required for mpt2sas driver. 4. Inherited automatic diag buffer feature from mpt3sas driver. Signed-off-by:
-
Sreekanth Reddy authored
Created a mpt3sas_module.c file for mpt3sas driver where it can register SAS3 HBA devices with PCI, SML, IOCTL subsystems. Also removed the corresponding interfaces from mpt3sas_scsih.c file. Signed-off-by:
-
Sreekanth Reddy authored
1. Added mpt2sas driver related macros in mpt3sas header files 2. Made scsi host's, raid class', pci's, ioctl's callback functions global so that both drivers can use them. Signed-off-by:
-
Christoph Hellwig authored
Use a single set of the hardware description headers instead of having them in the source tree twice. Signed-off-by:
-
- 10 Nov, 2015 9 commits
-
-
Benjamin Rood authored
Previously, when this module was unloaded via 'rmmod' with at least one drive attached, the SCSI error handler thread would become stuck in an infinite recovery loop and lockup the system, necessitating a reboot. Once the SAS layer is detached, the driver will fail any subsequent commands since the target devices are removed. However, removing the SCSI host generates a SYNCHRONIZE CACHE (10) command, which was failed and left the error handler no method of recovery. This patch simply removes the SCSI host first so that no more commands can come down, prior to cleaning up the SAS layer. Note that the stack is built up with the SCSI host first, and then the SAS layer. Perhaps it should be reversed for symmetry, so that commands cannot be sent to the pm80xx driver prior to attaching the SAS layer? What was really strange about this bug was that it was introduced at commit cff549e4 ("[SCSI]: proper state checking and module refcount handling in scsi_device_get"). This commit appears to tinker with how the reference counting is performed for SCSI device objects. My theory is that prior to this commit, the refcount for a device object was blindly incremented at some point during the teardown process which coincidentially made the device stick around during the procedure, which also coincidentially made any commands sent to the driver not fail (since the device was technically still "there"). After this commit was applied, my theory is the refcount for the device object is not being incremented at a specific point anymore, which makes the device go away, and thus made the pm80xx driver fail any subsequent commands. You may also want to see the following for more details: [1] http://www.spinics.net/lists/linux-scsi/msg37208.html [2] http://marc.info/?l=linux-scsi&m=144416476406993&w=2Signed-off-by:
Benjamin Rood <brood@attotech.com> Acked-by:
Jack Wang <jinpu.wang@profitbricks.com> Signed-off-by:
-
Jack Wang authored
commit cff549e4 ("scsi: proper state checking and module refcount handling in scsi_device_get") the reference count of scsi device was changed, which could lead to when rmmod with at least on drive attached, SCSI error handle will run into infinite loop, and lockup the system. Fix it by remove scsi host first, this way scsi core will not send commands down after detaching SAS transport. This is a follow up fix for Benjamin's fix for pm80xx. See also: http://www.spinics.net/lists/linux-scsi/msg90088.htmlSigned-off-by:
-
Jack Wang authored
commit cff549e4 ("scsi: proper state checking and module refcount handling in scsi_device_get") the reference count of scsi device was changed, which could lead to when rmmod with at least on drive attached, SCSI error handle will run into infinite loop, and lockup the system. Fix it by remove scsi host first, this way scsi core will not send commands down after detaching SAS transport. This is a follow up fix for Benjamin's fix for pm80xx. See also: http://www.spinics.net/lists/linux-scsi/msg90088.htmlSigned-off-by:
-
Jack Wang authored
commit cff549e4 ("scsi: proper state checking and module refcount handling in scsi_device_get") , the reference count of scsi device was changed, which could lead to when rmmod with at least on drive attached, SCSI error handle will run into infinite loop, and lockup the system. Fix it by remove scsi host first, this way scsi core will not send commands down after detaching SAS transport. This is a follow up fix for Benjamin's fix for pm80xx. See also: http://www.spinics.net/lists/linux-scsi/msg90088.htmlSigned-off-by:
-
Gabriel Krisman Bertazi authored
Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Reviewed-by:
Wen Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
Some new adapters require a special Configure Cache Parameters command to enable the adapter write cache, so send this during the adapter initialization if the adapter requires it. Signed-off-by:
-
Gabriel Krisman Bertazi authored
Add an IOA Inquiry command for Page 0xC4 during IOA initialization to collect cache capabilities, particularly to check if Sync IOA Write Cache is supported. Inquiry will happen right after Cap Inquiry on page 0xD0; and will execute only if the "Supported Pages" field in Inquiry Page 0x0 shows support for Page 0xC4. Otherwise, assume Sync IOA Write Cache is not supported. Signed-off-by:
-
Gabriel Krisman Bertazi authored
According to the IPR specification, Inhibit Underlength Checking bit must be disabled when issuing commands to vsets. Enabling it in this case might cause SCSI commands to fail with an Illegal Request, so make sure we keep this bit cleared when resource is a vset. Signed-off-by:
Manoj Kumar <manoj@linux.vnet.ibm.com> Acked-by:
-
Gabriel Krisman Bertazi authored
Add a holding pattern prior to collecting dump data, to wait for the IOA indication that the Mailbox register is stable and won't change without an explicit reset. This ensures we'll be collecting meaningful dump data, even when dumping right after an adapter reset. In the event of a timeout, we still force the dump, since a partial dump still might be useful. Signed-off-by:
-
- 09 Nov, 2015 21 commits
-
-
Yaniv Gardi authored
New revisions of UFS host controller supports the new UniPro hardware controller (referred as QUniPro). This patch adds the support to enable this new UniPro controller hardware. This change also adds power optimization for bus scaling feature, as well as support for HS-G3 power mode. Reviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Reviewed-by:
Gilad Broner <gbroner@codeaurora.org> Signed-off-by:
Yaniv Gardi <ygardi@codeaurora.org> Reviewed-by:
-
Yaniv Gardi authored
Adds support for configuring and reading the test bus and debug registers. This change also adds another vops in order to print the debug registers. Reviewed-by:
-
Yaniv Gardi authored
This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS a platform device. In order to do so a few additional changes are required: 1. The ufshcd-pltfrm is no longer serves as a platform device. Now it only serves as a group of platform APIs such as PM APIs (runtime suspend/resume, system suspend/resume etc), parsers of clocks, regulators and pm_levels from DT. 2. What used to be the old platform "probe" is now "only" a pltfrm_init() routine, that does exactly the same, but only being called by the new probe function of the UFS variant. Reviewed-by:
Rob Herring <robherring2@gmail.com> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
-
Yaniv Gardi authored
In order to simplify the code a set of wrapper functions is created to test and call each of the variant operations. Reviewed-by:
Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by:
-
Yaniv Gardi authored
This patch adds ufshcd_get_variant() and ufshcd_set_variant() routines in order to get/set the variant specific data. Reviewed-by:
-
Yaniv Gardi authored
This change is required in order to be able to build the component as a module. Reviewed-by:
-
Yaniv Gardi authored
This change fixes a compilation warning that happens if SCSI_UFS_QCOM is compiled as a module. Also this patch fixes an error happens when insmod the module: "ufs_qcom: module license 'unspecified' taints kernel." Reviewed-by:
-
Yaniv Gardi authored
Export the following functions in order to avoid build errors when the component PHY_QCOM_UFS is compiled as a module: ERROR: "ufs_qcom_phy_disable_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_enable_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_is_pcs_ready" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_disable_iface_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_start_serdes" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_calibrate_phy" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_enable_dev_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_set_tx_lane_enable" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_disable_dev_ref_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_save_controller_version" [drivers/scsi/ufs/ufs-qcom.ko] undefined! ERROR: "ufs_qcom_phy_enable_iface_clk" [drivers/scsi/ufs/ufs-qcom.ko] undefined! make[1]: *** [__modpost] Error 1 Reviewed-by:
-
Tomas Henzl authored
This patch fixes a 'general protection fault' issue by moving the attribute to where it was likely meant. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
Don Brace <don.brace@pmcs.com> Signed-off-by:
-
Don Brace authored
Reviewed-by:
Justin Lindley <justin.lindley@pmcs.com> Reviewed-by:
Scott Teel <scott.teel@pmcs.com> Reviewed-by:
Kevin Barnett <kevin.barnett@pmcs.com> Reviewed-by: Gerry Morong <gerry.morong.pmcs.com> Reviewed-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
-
Kevin Barnett authored
Reviewed-by:
-
Rasmus Villemoes authored
path_info_show() seems to be broken in multiple ways. First, there's 817 return snprintf(buf, output_len+1, "%s%s%s%s%s%s%s%s", 818 path[0], path[1], path[2], path[3], 819 path[4], path[5], path[6], path[7]); so hopefully output_len contains the combined length of the eight strings. Otherwise, snprintf will stop copying to the output buffer, but still end up reporting that combined length - which in turn would result in user-space getting a bunch of useless nul bytes (thankfully the upper sysfs layer seems to clear the output buffer before passing it to the various ->show routines). But we have 767 output_len = snprintf(path[i], 768 PATH_STRING_LEN, "[%d:%d:%d:%d] %20.20s ", 769 h->scsi_host->host_no, 770 hdev->bus, hdev->target, hdev->lun, 771 scsi_device_type(hdev->devtype)); so output_len at best contains the length of the last string printed. Inside the loop, we then otherwise add to output_len. By magic, we still have PATH_STRING_LEN available every time... This wouldn't really be a problem if the bean-counting has been done properly and each line actually does fit in 50 bytes, and maybe it does, but I don't immediately see why. Suppose we end up taking this branch: 802 output_len += snprintf(path[i] + output_len, 803 PATH_STRING_LEN, 804 "BOX: %hhu BAY: %hhu %s\n", 805 box, bay, active); An optimistic estimate says this uses strlen("BOX: 1 BAY: 2 Active\n") which is 21. Now add the 20 bytes guaranteed by the %20.20s and then some for the rest of that format string, and we're easily over 50 bytes. I don't think we can get over 100 bytes even being pessimistic, so this just means we'll scribble into the next path[i+1] and maybe get that overwritten later, leading to some garbled output (in fact, since we'd overwrite the previous string's 0-terminator, we could end up with one very long string and then print various suffixes of that, leading to much more than 400 bytes of output). Except of course when we're filling path[7], where overrunning it means writing random stuff to the kernel stack, which is usually a lot of fun. We can fix all of that and get rid of the 400 byte stack buffer by simply writing directly to the given output buffer, which the upper layer guarantees is at least PAGE_SIZE. s[c]nprintf doesn't care where it is writing to, so this doesn't make the spin lock hold time any longer. Using scnprintf ensures that output_len always represents the number of bytes actually written to the buffer, so we'll report the proper amount to the upper layer. Reviewed-by:Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Don Brace authored
Reviewed-by:
-
Scott Teel authored
When external target arrays are present, disable the firmware's normal behavior of returning a cached copy of the report lun data, and force it to collect new data each time we request a report luns. This is necessary for external arrays, since there may be no reliable signal from the external array to the smart array when lun configuration changes, and thus when driver requests report luns, it may be stale data. Use diag options to turn off RPL data caching. Reviewed-by:
-
Scott Teel authored
There are problems with getting configuration change notification in pass-through RAID environments. So, activate flag h->discovery_polling when one of these devices is detected in update_scsi_devices. After discovery_polling is set, execute a report luns from rescan_controller_worker (every 30 seconds). If the data from report_luns is different than last time (binary compare), execute a full rescan via update_scsi_devices. Reviewed-by:
-
Scott Teel authored
We don't need to create fake enclosure devices at Lun0 in external target array configurations anymore. This was done to support Pre-SCSI rev 5 controllers that didn't suppoprt report luns commands, so the SCSI layer had to scan targets. If there was no LUN at LUN 0, then the target scan would stop, and move to the next target. Lun0 enclosure device was added to prevent sparsely-numbered LUNs from being missed. Reviewed-by:
-
Scott Teel authored
External array LUNs must use target and lun numbers assigned by the external array. So the driver must treat these differently from local LUNs when assigning lun/target. LUN's 'model' field has been used to detect Lun types that need special treatment, but the desire is to eliminate the need to reference specific array models, and support any external array. Pass-through RAID (PTRAID) luns are not luns of the local controller, so they are not reported in LUN count of command 'ID controller'. However, they ARE reported in "Report logical Luns" command. Local luns are listed first, then PTRAID LUNs. The number of luns from "Report LUNs" in excess of those reported by 'ID controller' are therefore the PTRAID LUNS. We can now remove function is_ext_target, and the 'white list' array of supported model names. Reviewed-by:
-
Kevin Barnett authored
preparation for adding the sas transport class Reviewed-by:
-
Kevin Barnett authored
setup for sas transport. Need to set the bus and target accordingly. Reviewed-by:
-
Don Brace authored
use an index into vpd data for SAS/SATA drives Reviewed-by:
-
Kevin Barnett authored
simplify checking for logical/physical devices Reviewed-by:
-
