- 02 Oct, 2020 4 commits
-
-
Ye Bin authored
Fix the following warnings: [drivers/scsi/qla2xxx/tcm_qla2xxx.c:884]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [drivers/scsi/qla2xxx/tcm_qla2xxx.c:885]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [drivers/scsi/qla2xxx/tcm_qla2xxx.c:886]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [drivers/scsi/qla2xxx/tcm_qla2xxx.c:887]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [drivers/scsi/qla2xxx/tcm_qla2xxx.c:888]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. Link: https://lore.kernel.org/r/20200930022515.2862532-2-yebin10@huawei.comReported-by:
Hulk Robot <hulkci@huawei.com> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Mike Christie authored
Some iSCSI targets went with the traditional "export N ports" approach and then allowed the initiator to multipath over them. Other targets went the opposite direction and export a single port, and then software on the target side performs load balancing and failover to other targets via an iSCSI specific feature or IP takover. The problem for the 2nd type of config is we quickly run out of our five retries and get I/O errors. In these setups we want to reduce resource use on the initiator side so we only wanted the one session and no dm-multipath. To handle traditional multipath operations like failover we do IP takover on the target side. So we would have an iSCSI target running on node1. Some monitoring software decides it's dead or the node is overloaded so it starts the iSCSI target on node2. The problem is for the failover case where we might have the equivalent of a dm-multipath temporary all paths down, or we just have to try more than 5 nodes before finding a good one. To handle this type of issue allow the user to configure the disk cmd retries from -1 to the current max of 5. -1 means infinite retries and should be used for setups where some other setting is going to control when to fail. For example iSCSI has the replacement/recovery timeout and fc (some users have used FC with NPIV and done something similar as IP takover) has dev_loss_tmo/fast_io_fail which will eventually expire and fail I/O. Link: https://lore.kernel.org/r/1601566554-26752-3-git-send-email-michael.christie@oracle.comReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Mike Christie authored
Add infinite retry support to SCSI midlayer by combining common checks for retries into some helper functions, and then checking for the -1/SCSI_CMD_RETRIES_NO_LIMIT. Link: https://lore.kernel.org/r/1601566554-26752-2-git-send-email-michael.christie@oracle.comReviewed-by:
-
Roman Bolshakov authored
trace-cmd report doesn't show events from target subsystem because scsi_command_size() leaks through event format string: [target:target_sequencer_start] function scsi_command_size not defined [target:target_cmd_complete] function scsi_command_size not defined Addition of scsi_command_size() to plugin_scsi.c in trace-cmd doesn't help because an expression is used inside TP_printk(). trace-cmd event parser doesn't understand minus sign inside [ ]: Error: expected ']' but read '-' Rather than duplicating kernel code in plugin_scsi.c, provide a dedicated field for CONTROL byte. Link: https://lore.kernel.org/r/20200929125957.83069-1-r.bolshakov@yadro.comReviewed-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
-
- 30 Sep, 2020 8 commits
-
-
Nilesh Javali authored
Link: https://lore.kernel.org/r/20200929102152.32278-8-njavali@marvell.comReviewed-by:
-
Arun Easi authored
Driver was using a shorter timeout waiting for PLOGI from the peer in point-to-point configurations. Some devices takes some time (~4 seconds) to initiate the PLOGI. This peer initiating PLOGI is when the peer has a higher P-WWN. Increase the wait time based on N2N R_A_TOV. Link: https://lore.kernel.org/r/20200929102152.32278-7-njavali@marvell.comReviewed-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Quinn Tran authored
On unload, session cleanup prematurely gave the signal for driver unload path to advance. Link: https://lore.kernel.org/r/20200929102152.32278-6-njavali@marvell.com Fixes: 726b8548 ("qla2xxx: Add framework for async fabric discovery") Cc: stable@vger.kernel.org Reviewed-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
-
Arun Easi authored
Normally, the MPI firmware is reset when an MPI dump is collected. If an unsaved MPI dump exists in the driver, though, an alternate mechanism is used. This mechanism, which was not fully correct, is not recommended and instead an MPI dump template walk is suggested to perform the MPI reset. To allow for the MPI dump template walk, extra space is reserved in the MPI dump buffer which gets used only when there is already an MPI dump in place. Link: https://lore.kernel.org/r/20200929102152.32278-5-njavali@marvell.com Fixes: cbb01c2f ("scsi: qla2xxx: Fix MPI failure AEN (8200) handling") Cc: stable@vger.kernel.org Reviewed-by:
-
Arun Easi authored
When printing the message: "MPI Heartbeat stop. MPI reset is not needed.." ..the wrong register was checked leading to always printing that MPI reset is not needed, even when it is needed. Fix the MPI reset message. Link: https://lore.kernel.org/r/20200929102152.32278-4-njavali@marvell.com Fixes: cbb01c2f ("scsi: qla2xxx: Fix MPI failure AEN (8200) handling") Cc: stable@vger.kernel.org Reviewed-by:
-
Quinn Tran authored
Current code uses wrong mailbox option to extract bbc from firmware. This field is nested inside of PLOGI payload. Extract bbc from PLOGI template payload. Link: https://lore.kernel.org/r/20200929102152.32278-3-njavali@marvell.comReviewed-by:
-
Saurav Kashyap authored
Since the version string has been modified, sscanf() returns 4 instead of 6. Link: https://lore.kernel.org/r/20200929102152.32278-2-njavali@marvell.comReviewed-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
-
Bean Huo authored
Use devm_platform_ioremap_resource_byname() to simplify the code. Link: https://lore.kernel.org/r/20200916084017.14086-1-huobean@gmail.comAcked-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
- 23 Sep, 2020 5 commits
-
-
Stanley Chu authored
Add "mediatek,mt8192-ufshci" compatible string to for MediaTek UFS host controller present on MT8192 chipsets. Link: https://lore.kernel.org/r/20200914050052.3974-3-stanley.chu@mediatek.comAcked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Stanley Chu authored
Some MediaTek UFS platforms support high-performance mode that inline encryption engine can be boosted while UFS is not clock-gated. The high-performance mode will be enabled if all below conditions are well-declaired in device tree, - Proper platform-specific compatible string which enables the host capability "UFS_MTK_CAP_BOOST_CRYPT_ENGINE". - "dvfsrc-vcore" node is available in this platform. - Required minimum vcore voltage for high-performance mode. - Clock mux and clock parents of inline encryption engine for both "low-power mode" and "high-performance mode". Link: https://lore.kernel.org/r/20200914050052.3974-2-stanley.chu@mediatek.comSigned-off-by:
-
Liu Shixin authored
Simplify the return expression. Link: https://lore.kernel.org/r/20200921134558.3478922-1-liushixin2@huawei.comReviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Signed-off-by:
-
Jing Xiangfeng authored
No point in initializing ret with -ENOMEM. Link: https://lore.kernel.org/r/20200918090747.44645-1-jingxiangfeng@huawei.comAcked-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by:
-
Qinglang Miao authored
The mutex bnx2i_dev_lock is initialized statically. It is unnecessary to initialize by mutex_init(). Link: https://lore.kernel.org/r/20200916062133.191000-1-miaoqinglang@huawei.comAcked-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
- 22 Sep, 2020 17 commits
-
-
Nilesh Javali authored
Update internal driver version and remove module version macro. Link: https://lore.kernel.org/r/20200904045128.23631-14-njavali@marvell.comReviewed-by:
-
Saurav Kashyap authored
BIT_13 of extended FW attribute informs about NVMe-2 support. Set BIT_15 of special feature control block for enabling SLER in FW. Set bit 8 (SLER supported) to 1 for the service parameter information when sending NVMe PRLI request. Set BIT_14 of special feature control block for enabling PI Control in FW. Driver should set bit 9 (PI Control supported) to 1 for the service parameter information when sending NVMe PRLI request. Set BIT_13 for NVMe Async events. Link: https://lore.kernel.org/r/20200904045128.23631-13-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
This patch tracks number of IOCB resources used in the I/O fast path. If the number of used IOCBs reach a high water limit, driver would return the I/O as busy and let upper layer retry. This prevents over subscription of IOCB resources where any future error recovery command is unable to cut through. Enable IOCB throttling by default. Link: https://lore.kernel.org/r/20200904045128.23631-12-njavali@marvell.comReviewed-by:
-
Arun Easi authored
This patch adds rport fields in debugfs. Link: https://lore.kernel.org/r/20200904045128.23631-11-njavali@marvell.comReviewed-by:
-
Arun Easi authored
tgt_port_database data is today exported only in target mode, allow it to be shown in initiator mode as well. Link: https://lore.kernel.org/r/20200904045128.23631-10-njavali@marvell.comReviewed-by:
-
Arun Easi authored
In .fcp_io(), returning ENODEV as soon as remote port delete has started can cause I/O errors. Fix this by returning EBUSY until the remote port delete finishes. Link: https://lore.kernel.org/r/20200904045128.23631-9-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Move statistics fields from vha struct to qpair to reduce memory thrashing. Link: https://lore.kernel.org/r/20200904045128.23631-8-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Memory size calculations for Extended Login used in hardware offload got truncated. Fix this by changing definition of exlogin_size to use uint32_t. Link: https://lore.kernel.org/r/20200904045128.23631-7-njavali@marvell.comReviewed-by:
-
Quinn Tran authored
Indicate correct speed for 16G Mezz card. Link: https://lore.kernel.org/r/20200904045128.23631-6-njavali@marvell.comReviewed-by:
-
Arun Easi authored
FCP-4 (referred FCP-4 rev-2b) identifies the earlier known "retry delay timer" field as "status qualifier", which is described in SAM-5 and later specs. This fix makes appropriate driver side modifications to honor the new definition. The SAM document referred was SAM-6 rev-5. Link: https://lore.kernel.org/r/20200904045128.23631-5-njavali@marvell.comReviewed-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Arun Easi authored
Add a remote port debugfs entry to get/set dev_loss_tmo for NVMe devices. Link: https://lore.kernel.org/r/20200904045128.23631-4-njavali@marvell.comReported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Arun Easi authored
Create a base for adding remote port related entries in debugfs. Link: https://lore.kernel.org/r/20200904045128.23631-3-njavali@marvell.comReviewed-by:
-
Arun Easi authored
Driver was using a lower value for dev_loss_tmo making it more prone to I/O failures during remote port toggle testing. Set dev_loss_tmo to zero during remote port registration to allow nvme-fc default dev_loss_tmo to be used, which is higher than what driver was using. Link: https://lore.kernel.org/r/20200904045128.23631-2-njavali@marvell.comReviewed-by:
-
Brian King authored
In the discovery thread, ibmvfc does a vhost->task_set++ without any lock held. This could result in two targets getting the same cancel key, which could have strange effects in error recovery. The actual probability of this occurring should be extremely small, since this should all be done in a single threaded loop from the discovery thread, but let's fix it up anyway to be safe. Link: https://lore.kernel.org/r/1600286999-22059-1-git-send-email-brking@linux.vnet.ibm.comSigned-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Bodo Stroesser authored
scatter_data_area() has two purposes: 1) Create the iovs for the data area buffer of a SCSI cmd. 2) If there is data in DMA_TO_DEVICE direction, copy the data from sg_list to data area buffer. Both are done in a common loop. In case of DMA_FROM_DEVICE data transfer, scatter_data_area() is called with parameter copy_data = false. But this flag is just used to skip memcpy() for data, while radix_tree_lookup still is called for every dbi of the area area buffer, and kmap and kunmap are called for every page from sg_list and data_area as well as flush_dcache_page() for the data area pages. Since the only thing to do with copy_data = false would be to set up the iovs, this is a noticeable overhead. Rework the iov creation in the main loop of scatter_data_area() providing the new function new_block_to_iov(). Based on this, create the short new function tcmu_setup_iovs() that only writes the iovs with no overhead. This new function is now called instead of scatter_data_area() for bidi buffers and for data buffers in those cases where memcpy() would have been skipped. Link: https://lore.kernel.org/r/20200910155041.17654-4-bstroesser@ts.fujitsu.comAcked-by:Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by:
-
Bodo Stroesser authored
queue_cmd_ring() needs to check whether there is enough space in cmd ring and data area for the cmd to queue. Currently the sequence is: 1) Calculate size the cmd will occupy on the ring based on estimation of needed iovs. 2) Check whether there is enough space on the ring based on size from 1) 3) Allocate buffers in data area. 4) Calculate number of iovs the command really needs while copying incoming data (if any) to data area. 5) Re-calculate real size of cmd on ring based on real number of iovs. 6) Set up possible padding and cmd on the ring. Step 1) must not underestimate the cmd size so use max possible number of iovs for the given I/O data size. The resulting overestimation can be really high so this sequence is not ideal. The earliest the real number of iovs can be calculated is after data buffer allocation. Therefore rework the code to implement the following sequence: A) Allocate buffers on data area and calculate number of necessary iovs during this. B) Calculate real size of cmd on ring based on number of iovs. C) Check whether there is enough space on the ring. D) Set up possible padding and cmd on the ring. The new sequence enforces the split of new function tcmu_alloc_data_space() from is_ring_space_avail(). Using this function, change queue_cmd_ring() according to the new sequence. Change routines called by tcmu_alloc_data_space() to allow calculating and returning the iov count. Remove counting of iovs in scatter_data_area(). Link: https://lore.kernel.org/r/20200910155041.17654-3-bstroesser@ts.fujitsu.comAcked-by: -
Bodo Stroesser authored
Simplify code by joining tcmu_cmd_get_data_length() and tcmu_cmd_get_block_cnt() into tcmu_cmd_set_block_cnts(). The new function sets tcmu_cmd->dbi_cnt and also the new field tcmu_cmd->dbi_bidi_cnt which is needed for further enhancements in following patches. Simplify some code by using tcmu_cmd->dbi(_bidi)_cnt instead of calculation from length. Please note: The calculation of the number of dbis needed for bidi was wrong. It was based on the length of the first bidi sg only. I changed it to correctly sum up entire length of all bidi sgs. Link: https://lore.kernel.org/r/20200910155041.17654-2-bstroesser@ts.fujitsu.comAcked-by:
-
- 16 Sep, 2020 6 commits
-
-
Ming Lei authored
The request queue is currently run unconditionally in scsi_end_request() if both target queue and host queue are ready. Recently Long Li reported that cost of a queue run can be very heavy in case of high queue depth. Improve this situation by only running the request queue when this LUN is busy. Link: https://lore.kernel.org/r/20200910075056.36509-1-ming.lei@redhat.comReported-by:
Long Li <longli@microsoft.com> Tested-by:
Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
-
Alex Dewar authored
kmemdup() can be used instead of kmalloc()+memcpy(). Replace two occurrences of this pattern. Issue identified with Coccinelle. Link: https://lore.kernel.org/r/20200909185855.151964-1-alex.dewar90@gmail.comSigned-off-by:
Alex Dewar <alex.dewar90@gmail.com> Signed-off-by:
-
Matej Genci authored
VirtIO 1.0 spec says: The removed and rescan events ... when sent for LUN 0, they MAY apply to the entire target so the driver can ask the initiator to rescan the target to detect this. This change introduces the behaviour described above by scanning the entire SCSI target when LUN is set to 0. This is both a functional and a performance fix. It aligns the driver with the spec and allows control planes to hotplug targets with large numbers of LUNs without having to request a RESCAN for each one of them. Link: https://lore.kernel.org/r/CY4PR02MB33354370E0A81E75DD9DFE74FB520@CY4PR02MB3335.namprd02.prod.outlook.comSuggested-by:Felipe Franciosi <felipe@nutanix.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Matej Genci <matej.genci@nutanix.com> Signed-off-by:
-
Jason Yan authored
This addresses the following sparse warning: drivers/scsi/myrb.c:2229:27: warning: symbol 'myrb_template' was not declared. Should it be static? drivers/scsi/myrb.c:2318:31: warning: symbol 'myrb_raid_functions' was not declared. Should it be static? drivers/scsi/myrb.c:2492:6: warning: symbol 'myrb_err_status' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200915084018.2826922-1-yanaijie@huawei.comReported-by:
-
Jason Yan authored
This addresses the following sparse warning: drivers/scsi/myrs.c:1532:5: warning: symbol 'myrs_host_reset' was not declared. Should it be static? drivers/scsi/myrs.c:1922:27: warning: symbol 'myrs_template' was not declared. Should it be static? drivers/scsi/myrs.c:2036:31: warning: symbol 'myrs_raid_functions' was not declared. Should it be static? drivers/scsi/myrs.c:2046:6: warning: symbol 'myrs_flush_cache' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200915084008.2826835-1-yanaijie@huawei.comReported-by:
-
Jason Yan authored
This addresses the following sparse warning: drivers/scsi/isci/phy.c:672:6: warning: symbol 'scu_link_layer_set_txcomsas_timeout' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200915084000.2826741-1-yanaijie@huawei.comReported-by:
-
