- 01 Dec, 2016 7 commits
-
-
Matthew R. Ochs authored
The send_tmf() routine includes some copy/paste cruft that can be removed as well as the setting of an AFU command-specific while holding the tmf_slock. While not a bug, it is out of place and should be shifted down alongside the other command initialization statements for clarity. Signed-off-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Matthew R. Ochs authored
The original design of the cxlflash driver required AFU commands to convey state information across multiple threads. The IOASA "host use" byte was used to track if a command was done, errored, or timed out. A per-command spin lock was used to serialize access to this byte. As this is no longer required with the introduction of completions and various refactoring over time, the spin lock, state tracking, and associated code can be removed. To support the simplification, the wait_resp() routine is refactored to return a success or failure. Additionally, as the simplification to the AFU internal command routine, explicit assignments of AFU command fields to zero are removed as the memory is zeroed upon allocation. Signed-off-by:
-
Matthew R. Ochs authored
With the removal of the static private command pool, the ability to 'complete' outstanding commands was lost. While not an issue for the commands originating outside the driver, internal AFU commands are synchronous and therefore have a timeout associated with them. To avoid a stale memory access, the tear down sequence needs to ensure that there are not any active commands before proceeding. As these internal AFU commands are rare events, the simplest way to accomplish this is detecting the activity and waiting for it to timeout. Signed-off-by:
-
Matthew R. Ochs authored
Clean up and remove the remaining private command pool infrastructure that is no longer required. Signed-off-by:
-
Matthew R. Ochs authored
Instead of using a private pool of AFU commands, use cmd_size to prime the private pool of SCSI commands such that they are allocated with a size large enough to contain an aligned AFU command. Use scsi_cmd_priv() to derive the aligned/zeroed private command on queuecommand and TMF paths. Remove cmd_checkout() as it is no longer required. The remaining AFU private command infrastructure will be removed in a cleanup commit. Signed-off-by:
-
Matthew R. Ochs authored
As staging for the removal of the AFU command pool, remove the reliance upon the pool for the internal AFU sync command. Instead of obtaining an AFU command from the pool, dynamically allocate memory with the appropriate alignment requirements. Since the AFU sync service is only executed from the process environment, blocking is acceptable. Signed-off-by:
-
Matthew R. Ochs authored
The cxlflash driver originally required a per-command 4K buffer that hosted data passed to the AFU. When the routines that initiate AFU and internal SCSI commands were refactored to use scsi_execute(), the need for this buffer became obsolete. As it is no longer necessary, the buffer is removed. Signed-off-by:
-
- 30 Nov, 2016 7 commits
-
-
Souptick Joarder authored
In lpfc_new_scsi_buf_s3() and lpfc_new_scsi_buf_s4() pci_pool_alloc followed by memset will be replaced by pci_pool_zalloc() Signed-off-by:
Souptick joarder <jrdr.linux@gmail.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
-
Cathy Avery authored
On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array requires. Also the buffer needs to be cleared or the upper bytes will contain junk. Suggested-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Cathy Avery <cavery@redhat.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Quentin Lambert authored
Most error branches following the call to dst_neigh_lookup contain a call to neigh_release. This patch add these calls where they are missing. This issue was found with Hector. Signed-off-by:
Quentin Lambert <lambert.quentin@gmail.com> Acked-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Uma Krishnan authored
During test, a command room violation interrupt is occasionally seen for the master context when the CXL flash devices are stressed. After studying the code, there could be gaps in the way command room value is being cached in cxlflash. When the cached command room is zero the thread attempting to send becomes burdened with updating the cached value with the actual value from the AFU. Today, this is handled with an atomic set operation of the raw value read. Following the atomic update, the thread proceeds to send. This behavior is incorrect on two counts: - The update fails to take into account the current thread and its consumption of one of the hardware commands. - The update does not take into account other threads also atomically updating. Per design, a worker thread updates the cached value when a send thread times out. By not protecting the update with a lock, the cached value can be incorrectly clobbered. To correct these issues, the update of the cached command room has been simplified and also protected using a spin lock which is held until the MMIO is complete. This ensures the command room is properly consumed by the same thread. Update of cached value also takes into account the current thread consuming a hardware command. Signed-off-by: -
Uma Krishnan authored
Currently, the context reset routine waits for command room to be available before sending the reset request. Per review of the SISLite specification and clarifications from the CXL Flash AFU designers, this wait is unnecessary. The reset request can be sent anytime regardless of command room, so long as only a single reset request is active at any one point in time. This commit simplifies the reset routine by removing the wait for command room. Additionally it adds a debug trace to help pinpoint hardware errors when a context reset does not complete. Signed-off-by:
-
Uma Krishnan authored
During test, the following crash was observed: [34538.981505] Faulting instruction address: 0xd000000007c9c870 cpu 0x9: Vector: 300 (Data Access) at [c0000007f1e8f590] pc: d000000007c9c870: cxlflash_restore_luntable+0x70/0x1d0 [cxlflash] lr: d000000007c9c84c: cxlflash_restore_luntable+0x4c/0x1d0 [cxlflash] sp: c0000007f1e8f810 msr: 9000000100009033 dar: c00000171d637438 dsisr: 40000000 current = 0xc0000007f1e43f90 paca = 0xc000000007b25100 softe: 0 irq_happened: 0x01 pid = 493, comm = eehd enter ? for help [c0000007f1e8f8a0] d000000007c940b0 init_afu+0xd60/0x1200 [cxlflash] [c0000007f1e8f9a0] d000000007c945a8 cxlflash_pci_slot_reset+0x58/0xe0 [cxlflash] [c0000007f1e8fa20] d00000000715f790 cxl_pci_slot_reset+0x230/0x340 [cxl] [c0000007f1e8fae0] c000000000040dd4 eeh_report_reset+0x144/0x180 [c0000007f1e8fb20] c00000000003f708 eeh_pe_dev_traverse+0x98/0x170 [c0000007f1e8fbb0] c000000000041618 eeh_handle_normal_event+0x328/0x410 [c0000007f1e8fc30] c000000000041db8 eeh_handle_event+0x178/0x330 [c0000007f1e8fce0] c000000000042118 eeh_event_handler+0x1a8/0x1b0 [c0000007f1e8fd80] c00000000011420c kthread+0xec/0x100 [c0000007f1e8fe30] c00000000000a47c ret_from_kernel_thread+0x5c/0xe0 When superpipe mode is disabled for a LUN, the references for the local lun are deleted but the LUN is still identified as being present in the LUN table. This mismatched state can result in the above crash when the LUN table is restored during an error recovery operation. To fix this issue, the local LUN information structure is updated to reflect the LUN is no longer in the LUN table once all references to the LUN are gone. Signed-off-by: -
Uma Krishnan authored
The following Oops is encountered when blk_mq is enabled with the cxlflash driver: [ 2960.817172] Oops: Kernel access of bad area, sig: 11 [#5] [ 2960.817309] NIP __blk_mq_run_hw_queue+0x278/0x4c0 [ 2960.817313] LR __blk_mq_run_hw_queue+0x2bc/0x4c0 [ 2960.817314] Call Trace: [ 2960.817320] __blk_mq_run_hw_queue+0x2bc/0x4c0 (unreliable) [ 2960.817324] blk_mq_run_hw_queue+0xd8/0x100 [ 2960.817329] blk_mq_insert_requests+0x14c/0x1f0 [ 2960.817333] blk_mq_flush_plug_list+0x150/0x190 [ 2960.817338] blk_flush_plug_list+0x11c/0x2b0 [ 2960.817344] blk_finish_plug+0x58/0x80 [ 2960.817348] __do_page_cache_readahead+0x1c0/0x2e0 [ 2960.817352] force_page_cache_readahead+0x68/0xd0 [ 2960.817356] generic_file_read_iter+0x43c/0x6a0 [ 2960.817359] blkdev_read_iter+0x68/0xa0 [ 2960.817361] __vfs_read+0x11c/0x180 [ 2960.817364] vfs_read+0xa4/0x1c0 [ 2960.817366] SyS_read+0x6c/0x110 [ 2960.817369] system_call+0x38/0xb4 The SCSI blk_mq stack assumes that sg_tablesize is always a non-zero value with scsi_mq_setup_tags() allocating tags using sg_tablesize. The cxlflash driver currently uses SG_NONE (0) for the sg_tablesize as the devices it supports are not capable of scatter gather. This mismatch of values results in the Oops above. To resolve this issue, sg_tablesize for cxlflash can simply be set to 1, a value which satisfies the constraints in cxlflash and the lack of support of SG_NONE in SCSI blk_mq. Signed-off-by:
-
- 29 Nov, 2016 19 commits
-
-
subhashj@codeaurora.org authored
We would by default like to run in FAST/SLOW mode instead of FASTAUTO/SLOWAUTO mode for performance reasons. This change sets the default speed mode to FAST/SLOW mode. Reviewed-by:
Venkat Gopalakrishnan <venkatg@codeaurora.org> Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
subhashj@codeaurora.org authored
Consider following sequence of events: 1. UFS is runtime suspended, link_state = Hibern8, device_state = sleep 2. System goes into system suspend, ufshcd_system_suspend() brings both link and device to active state and then puts the device in Power_Down state and link in OFF state. 3. System resumes at some later point in time, ufshcd_system_resume() doesn't do anything as UFS state is runtime suspended. Note that link is still on OFF state and device is in Power_Down state. 4. Now system again goes into suspend without any UFS accesses before it. ufshcd_system_suspend() again brings both link and device to active state and then puts the device in Power_Down state and link if OFF state. But it's unnecessary to bring the link & device in active state as both link and device are already in desired low power states. This change fixes this issue by adding proper state checks in ufshcd_system_suspend(). Reviewed-by:
Gilad Broner <gbroner@codeaurora.org> Signed-off-by:
-
Yaniv Gardi authored
The condition in which error message is printed out was incorrect and resulted error message only if retries exhausted. But retries happens only if DME command is a peer command, and thus DME commands which are not peer commands and fail are not printed out. This change fixes this issue. Signed-off-by:
Yaniv Gardi <ygardi@codeaurora.org> Signed-off-by:
-
Dolev Raviv authored
The PHY_ADAPTER_ERROR status register indicates PHY lane errors reported by the M-PHY layer. In some occasions the controller can recover from such errors. When the error is not recoverable, a stuck DB error will occur. Since the stuck DB error is spotted separately, no action other than clearing the register is necessary. Signed-off-by:
Dolev Raviv <draviv@codeaurora.org> Signed-off-by:
-
subhashj@codeaurora.org authored
If we issue the link startup to the device while its UniPro state is LinkDown (and device state is sleep/power-down) then link startup will not move the device state to Active. Device will only move to active state if the link starup is issued when its UniPro state is LinkUp. So in this case, we would have to issue the link startup 2 times to make sure that device moves to active state. Reviewed-by:
-
subhashj@codeaurora.org authored
Some UFS devices require host PA_TACTIVATE to be higher than device PA_TACTIVATE otherwise it may get stuck during hibern8 sequence. This change allows this by using quirk. Reviewed-by:
-
subhashj@codeaurora.org authored
It is found thats UFS device may take longer than 30ms to respond to query requests and in this case we might run into following scenario: 1. UFS host SW sends a query request to UFS device to read an attribute value. SW uses tag #31 for this purpose. 2. UFS host SW waits for 30ms to get the query response (and doorbell to be cleared by UFS host HW). 3. UFS device doesn't respond back within 30ms hence UFS host SW times out waiting for the query response. 4. UFS host SW clears the tag#31 from UTRLCLR register. 5. UFS host SW waits until UFS host HW to clear tag#31 from the doorbell register. 6. UFS host SW retries the same query request on same tag#31 (sends a query request to device to read an attribute value). 7. UFS host HW gets the query response from the device but this was intended as a query response for the 1st query request sent (step-1). 8. Now UFS device sends another query response to host (for query request sent @step-6). Now there are 2 issues that could happen with above scenario: 1. UFS device should have actually responded back with only one query response but it is found that device may respond back with 2 query responses. 2. If UFS device responds back with 2 resposes on same tag, host HW/SW behaviour isn't predictable. To avoid running into above scenario, we would basically allow device to take longer (upto 1.5 seconds) for query response. Reviewed-by:
-
subhashj@codeaurora.org authored
While reading variable size descriptors (like string descriptor), some UFS devices may report the "LENGTH" (field in "Transaction Specific fields" of Query Response UPIU) same as what was requested in Query Request UPIU instead of reporting the actual size of the variable size descriptor. Although it's safe to ignore the "LENGTH" field for variable size descriptors as we can always derive the length of the descriptor from the descriptor header fields. Hence this change impose the length match check only for fixed size descriptors (for which we always request the correct size as part of Query Request UPIU). Reviewed-by:
-
Yaniv Gardi authored
According to JESD220B - UFS v2.0, the maximum size of device descriptor has changed from 0x1F to 0x40. This patch updates the maximum size of this descriptor. Signed-off-by:
-
Yaniv Gardi authored
When sending query to the device, the index of the failure is additional useful information that should be printed out as it might specify the logical unit (LU) where the error occurred. Signed-off-by:
-
Dolev Raviv authored
Some of the queries might fail during init. To avoid system failure, we add retry mechanism to issue queries several times. Signed-off-by:
-
Quentin Lambert authored
Most error branches following the call to kzalloc contain a call to kfree. This patch add these calls where they are missing. This issue was found with Hector. Signed-off-by:
-
Quentin Lambert authored
Most error branches following the call to pci_map_biosrom contain a call to pci_unmap_biosrom. This patch add these calls where they are missing. This issue was found with Hector. Signed-off-by:
-
Arnd Bergmann authored
I'm getting a new warning with gcc-7: isci/remote_node_context.c: In function 'sci_remote_node_context_destruct': isci/remote_node_context.c:69:16: error: array subscript is above array bounds [-Werror=array-bounds] This is odd, since we clearly cover all values for enum scis_sds_remote_node_context_states here. Anyway, checking for an array overflow can't harm and it makes the warning go away. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Dan Carpenter authored
There are some typos where we intended "<<" but have "<". Seems likely to cause a bunch of problems. Fixes: d3b688d3 ("scsi: hisi_sas: add v2 hw support for ECC and AXI bus fatal error") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Quentin Lambert authored
Most error branches following the call to kzalloc contain a call to kfree. This patch add these calls where they are missing and set the relevant pointers to NULL. This issue was found with Hector. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Hannes Reinecke authored
Add a sysfs attribute 'ctlr_num' holding the current HPSA controller number. This is required to construct compability 'cciss' links. [mkp: fixed typo] Signed-off-by:
Hannes Reinecke <hare@suse.com> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
Hannes Reinecke authored
NOT_READY is a sense key, not a legit scsi hostbyte value. Use DID_NO_CONNECT instead. Signed-off-by:
-
Bart Van Assche authored
Additionally, rename srp_wait_for_queuecommand() into scsi_wait_for_queuecommand() and add a comment about the queuecommand() call from scsi_send_eh_cmnd(). Note: this patch changes scsi_internal_device_block from a function that did not sleep into a function that may sleep. This is fine for all callers of this function: * scsi_internal_device_block() is called from the mpt3sas device while that driver holds the ioc->dm_cmds.mutex. This means that the mpt3sas driver calls this function from thread context. * scsi_target_block() is called by __iscsi_block_session() from kernel thread context and with IRQs enabled. * The SRP transport code also calls scsi_target_block() from kernel thread context while sleeping is allowed. * The snic driver also calls scsi_target_block() from a context from which sleeping is allowed. The scsi_target_block() call namely occurs immediately after a scsi_flush_work() call. [mkp: s/shost/sdev/] Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
-
- 25 Nov, 2016 7 commits
-
-
Dan Carpenter authored
We verified that resp_code is FC_SPP_RESP_ACK earlier so we don't need to check again here. Signed-off-by:
Johannes Thumshirn <jth@kernel.org> Signed-off-by:
-
Santosh Y authored
Reported-by:
Venkatraman S <svenkatr@ti.com> Reviewed-by:
Vinayak Holikatti <vinholikatti@gmail.com> Signed-off-by:
Santosh Y <santoshsy@gmail.com> Signed-off-by:
Zhangfei Gao <zhangfei.gao@linaro.org> Reviewed-by:
-
Xiang Chen authored
Add the function to set PHY min and max linkrate through sysfs interface. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
John Garry authored
Sometimes the value of hisi_sas_device.running_req would go negative unless we have the check for running_req >= 0 before trying to decrement. This is because using running_req is not thread-safe. As such, the value for running_req may be actually incorrect, so use atomic64_t instead. Signed-off-by:
-
Xiang Chen authored
Check ERR bit of status to decide whether there is something wrong with initial register-D2H FIS. If error exists, PHY reset the channel to restart OOB. Signed-off-by:
-
Xiang Chen authored
Modify and add some SATA commands according to SATA protocol. Signed-off-by:
-
Xiang Chen authored
Delete repeated configuration items for hisi_sas_device() when we free a device. These items are now only set in hisi_sas_dev_gone(). Signed-off-by:
-
