- 14 Apr, 2017 8 commits
-
-
Matthew R. Ochs authored
As staging to support FC-related updates to the SISlite specification, introduce helper routines to obtain references to FC resources that exist within the global map. This will allow changes to the underlying global map structure without impacting existing code paths. Signed-off-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Matthew R. Ochs authored
At present, the cxlflash driver only supports hardware with two FC ports. The code was initially designed with this assumption and is dependent on having two FC ports - adding more ports will break logic within the driver. To mitigate this issue, remove the existing port assumptions and transition the code to support more than two ports. As a side effect, clarify the interpretation of the DK_CXLFLASH_ALL_PORTS_ACTIVE flag. Signed-off-by:
-
Matthew R. Ochs authored
Transition from a static number of FC ports to a value that is derived during probe. For now, a static value is used but this will later be based on the type of card being configured. Signed-off-by:
-
Matthew R. Ochs authored
As staging for future function, pass the config pointer instead of the AFU pointer for port-related sysfs helper routines. Signed-off-by:
-
Matthew R. Ochs authored
Currently, RRQ processing takes place on hardware interrupt context. This can be a heavy burden in some environments due to the overhead encountered while completing RRQ entries. In an effort to improve system performance, use the IRQ polling API to schedule this processing on softirq context. This function will be disabled by default until starting values can be established for the hardware supported by this driver. Signed-off-by:
-
Matthew R. Ochs authored
As further staging to support processing the HRRQ by other means, access to the HRRQ needs to be serialized by a disabled lock. This will allow safe access in other non-hardware interrupt contexts. In an effort to minimize the period where interrupts are disabled, support is added to queue up commands harvested from the RRQ such that they can be processed with hardware interrupts enabled. While this doesn't offer any improvement with processing on a hardware interrupt it will help when IRQ polling is supported and the command completions can execute on softirq context. Signed-off-by:
-
Matthew R. Ochs authored
In order to support processing the HRRQ by other means (e.g. polling), the processing portion of the current RRQ interrupt handler needs to be broken out into a separate routine. This will allow RRQ processing from places other than the RRQ hardware interrupt handler. Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in SNIC_ERR error message text, one cannot have "Cann't". Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 12 Apr, 2017 14 commits
-
-
Xiang Chen authored
For 1 bit ECC errors, those errors can be recovered by hw. But for multi-bits ECC and AXI errors, there are something wrong with whole module or system, so try reset the controller to recover those errors instead of calling panic(). Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
John Garry authored
If a TMF timeouts (maybe due to unlikely scenario of an expander being unplugged when TMF for remote device is active), when we eventually try to free the slot, we crash as we dereference the slot's task, which has already been released. As a fix, add checks in the slot release code for a NULL task. Signed-off-by:
-
John Garry authored
This patch is a workaround for a SoC bug where an internal abort command may timeout. In v2 hw, the channel should become idle in order to finish abort process. If the target side has been sending HOLD, host side channel failed to complete the frame to send, and can not enter the idle state. Then internal abort command will timeout. As this issue is only in v2 hw, we deal with it in the hw layer. Our workaround solution is: If abort is not finished within a certain period of time, we will check HOLD status. If HOLD has been sending, we will send break command. Signed-off-by:
Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by:
-
Xiaofei Tan authored
This patch adds a workaround solution for a SoC bug which may cause SoC logic fatal error when disabling a PHY. Then we find internal abort IO timeout may occur, and the controller IO breakpoint may be corrupted. We work around this SoC bug by optimizing the flow of disabling a PHY. Signed-off-by:
-
Xiaofei Tan authored
This patch provides a workaround a SoC bug where SATA IPTTs for different devices may conflict. The workaround solution requests the following: 1. SATA device id must be even and not equal to SAS IPTT. 2. SATA device can not share the same IPTT with other SAS or SATA device. Besides we shall consider IPTT value 0 is reserved for another SoC bug (STP device open link at firstly after SAS controller reset). To sum up, the solution is: Each SATA device uses independent and continuous 32 even IPTT from 64 to 4094, then v2 hw can only support 63 SATA devices. All SAS device(SSP/SMP devices) share odd IPTT value from 1 to 4095. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Xiaofei Tan authored
After resetting the controller, the process of scanning SATA disks attached to an expander may fail occasionally. The issue is that the controller can't close the STP link created by target if the max link time is 0. To workaround this issue, we reject STP link after resetting the controller, and change the corresponding PHY to accept STP link only after receiving data. We do this check in cq interrupt handler. In order not to reduce efficiency, we use an variable to control whether we should check and change PHY to accept STP link. The function phys_reject_stp_links_v2_hw() should be called after resetting the controller. The solution of another SoC bug "SATA IO timeout", that also uses the same register to control STP link, is not effective before the PHY accepts STP link. Signed-off-by:
-
Johannes Thumshirn authored
Directly call ELS request handler functions in fc_lport_recv_els_req instead of saving the pointer to the handler's receive function and then later dereferencing this pointer. This makes the code a bit more obvious. Signed-off-by:
Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by:
-
Hannes Reinecke authored
sg_remove_sfp_usercontext() is clearing any sg requests, but needs to take 'rq_list_lock' when modifying the list. Reported-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
-
Hannes Reinecke authored
'Sg_request' is using a private list implementation; convert it to standard lists. Signed-off-by:
-
Johannes Thumshirn authored
Check for a valid direction before starting the request, otherwise we risk running into an assertion in the scsi midlayer checking for valid requests. [mkp: fixed typo] Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Hannes Reinecke authored
The 'reserved' page array is used as a short-cut for mapping data, saving us to allocate pages per request. However, the 'reserved' array is only capable of holding one request, so this patch introduces a mutex for protect 'sg_fd' against concurrent accesses. Signed-off-by:
-
Hannes Reinecke authored
Unused. Signed-off-by:
-
Hannes Reinecke authored
The ioctl SET_FORCE_LOW_DMA has never worked since the initial git check-in, and the respective setting is nowadays handled correctly. So disable it entirely. Signed-off-by:
-
Colin Ian King authored
There are several local or function parameter pointers that are being assigned NULL after a kfree where and these have no effect and hence can be removed. Fixes various cppcheck warnings: "Assignment of function parameter has no effect outside the function. Did you forget dereferencing it" Signed-off-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
-
- 06 Apr, 2017 12 commits
-
-
Nicholas Mc Guire authored
The redundant init_completion() here seems to be a cut&past error as struct scsi_qla_host only has 4 completion elements to initialize, thus the duplicate init_completion(disable_acb_comp) is simply removed. Signed-off-by:
Nicholas Mc Guire <der.herr@hofr.at> Signed-off-by:
-
Hannes Reinecke authored
There hasn't been any reports for HBAs where asynchronous abort would not work, so we should make it mandatory and remove the fallback. Signed-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
-
Hannes Reinecke authored
scsi_eh_scmd_add() currently only will fail if no error handler thread is started (which will never be the case) or if the state machine encounters an illegal transition. But if we're encountering an invalid state transition chances is we cannot fixup things with the error handler. So better add a WARN_ON for illegal host states and make scsi_dh_scmd_add() a void function. Signed-off-by:
-
Hannes Reinecke authored
If a failed command is retried and fails again we need to enter SCSI EH, otherwise we will never be able to recover the command. To detect this situation we must not clear scmd->eh_eflags when EH finishes but rather make it persistent throughout the lifetime of the command. Signed-off-by:
Benjamin Block <bblock@linux.vnet.ibm.com> Reviewed-by:
-
Christoph Hellwig authored
We now first try to call ->eh_abort_handler from a work queue, but libsas was always failing that for no good reason. Allow async aborts. Reviewed-by:
Johannes Thumshirn <jth@kernel.org> Reviewed-by:
-
Hannes Reinecke authored
When a command has timed out we always should be sending an abort; with the previous code a failed abort might signal SCSI EH to start, and all other timed out commands will never be aborted, even though they might belong to a different ITL nexus. Cc: Benjamin Block <bblock@linux.vnet.ibm.com> Signed-off-by:
-
Hannes Reinecke authored
If sd_eh_action() decides to take the device offline there is no point in returning FAILED, as taking the device offline is the ultimate step in SCSI EH anyway. So further escalation via SCSI EH is not likely to make a difference and we can as well return SUCCESS. Cc: Benjamin Block <bblock@linux.vnet.ibm.com> Signed-off-by:
-
Hannes Reinecke authored
The current medium access timeout counter will be increased for each command, so if there are enough failed commands we'll hit the medium access timeout for even a single device failure and the following kernel message is displayed: sd H:C:T:L: [sdXY] Medium access timeout failure. Offlining disk! Fix this by making the timeout per EH run, ie the counter will only be increased once per device and EH run. Fixes: 18a4d0a2 ("[SCSI] Handle disk devices which can not process medium access commands") Cc: Ewan Milne <emilne@redhat.com> Cc: Lawrence Obermann <loberman@redhat.com> Cc: Benjamin Block <bblock@linux.vnet.ibm.com> Cc: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by:
-
Christoph Hellwig authored
And get automatic MSI-X affinity for free. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Mauricio Faria de Oliveira authored
The commit 08024885 ("ses: Add power_status to SES device slot") introduced the 'power_status' attribute to enclosure components and the associated callbacks. There are 2 callbacks available to get the power status of a device: 1) ses_get_power_status() for 'struct enclosure_component_callbacks' 2) get_component_power_status() for the sysfs device attribute (these are available for kernel-space and user-space, respectively.) However, despite both methods being available to get power status on demand, that commit also introduced a call to get power status in ses_enclosure_data_process(). This dramatically increased the total probe time for SCSI devices on larger configurations, because ses_enclosure_data_process() is called several times during the SCSI devices probe and loops over the component devices (but that is another problem, another patch). That results in a tremendous continuous hammering of SCSI Receive Diagnostics commands to the enclosure-services device, which does delay the total probe time for the SCSI devices __significantly__: Originally, ~34 minutes on a system attached to ~170 disks: [ 9214.490703] mpt3sas version 13.100.00.00 loaded ... [11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) With this patch, it decreased to ~2.5 minutes -- a 13.6x faster [ 1002.992533] mpt3sas version 13.100.00.00 loaded ... [ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) Back to the commit discussion.. on the ses_get_power_status() call introduced in ses_enclosure_data_process(): impact of removing it. That may possibly be in place to initialize the power status value on device probe. However, those 2 functions available to retrieve that value _do_ automatically refresh/update it. So the potential benefit would be a direct access of the 'power_status' field which does not use the callbacks... But the only reader of 'struct enclosure_component::power_status' is the get_component_power_status() callback for sysfs attribute, and it _does_ check for and call the .get_power_status callback, (which indeed is defined and implemented by that commit), so the power status value is, again, automatically updated. So, the remaining potential for a direct/non-callback access to the power_status attribute would be out-of-tree modules -- well, for those, if they are for whatever reason interested in values that are set during device probe and not up-to-date by the time they need it.. well, that would be curious. Well, to handle that more properly, set the initial power state value to '-1' (i.e., uninitialized) instead of '1' (power 'on'), and check for it in that callback which may do an direct access to the field value _if_ a callback function is not defined. Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Fixes: 08024885 ("ses: Add power_status to SES device slot") Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
-
Bart Van Assche authored
Now that all scsi_device_get() callers check the return value of this function, make checking that return value mandatory. Signed-off-by:
-
Bart Van Assche authored
scsi_device_get() can fail. Hence check its return value. Signed-off-by:
Boaz Harrosh <ooo@electrozaur.com> Signed-off-by:
-
- 05 Apr, 2017 2 commits
-
-
Johannes Thumshirn authored
sas_domain_release_transport is unused since at least v3.13, remove it. Signed-off-by:
-
Milan P Gandhi authored
Signed-off-by:
Milan P Gandhi <mgandhi@redhat.com> Signed-off-by:
-
- 04 Apr, 2017 1 commit
-
-
Arnd Bergmann authored
gcc-7.0.1 now warns about a previously unnoticed access of uninitialized struct members: drivers/scsi/advansys.c: In function 'AscMsgOutSDTR': drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]); ^ drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code has existed in this exact form at least since v2.6.12, and the warning seems correct. This uses named initializers to ensure we initialize all members of the structure. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 30 Mar, 2017 3 commits
-
-
Christoph Hellwig authored
And get automatic MSI-X affinity for free. Signed-off-by:
Jitendra Bhivare <jitendra.bhivare@broadcom.com> Signed-off-by:
-
Szymon Mielczarek authored
This reverts commit 61e07359. The patch introduced redundant query retries as we already had such mechanism provided with _retry functions. Both ufshcd_read_desc and ufshcd_read_unit_desc_param functions call ufshcd_query_descriptor_retry wrapper. Signed-off-by:
Szymon Mielczarek <szymonx.mielczarek@intel.com> Reviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
Don Brace authored
Reviewed-by:
Gerry Morong <gerry.morong@microsemi.com> Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
