- 30 Sep, 2020 1 commit
-
-
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:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 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:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-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:
Saurav Kashyap <skashyap@marvell.com> Signed-off-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:
Quinn Tran <qutran@marvell.com> Signed-off-by:
Arun Easi <aeasi@marvell.com> Signed-off-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:Mike Christie <michael.christie@oracle.com> Signed-off-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 15 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:
Bart Van Assche <bvanassche@acm.org> 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:
Hulk Robot <hulkci@huawei.com> Signed-off-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:
-
Jason Yan authored
This eliminates the following sparse warning: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:53:1: warning: symbol 'bnx2fc_global_lock' was not declared. Should it be static? drivers/scsi/bnx2fc/bnx2fc_fcoe.c:111:6: warning: symbol 'bnx2fc_devloss_tmo' was not declared. Should it be static? drivers/scsi/bnx2fc/bnx2fc_fcoe.c:116:6: warning: symbol 'bnx2fc_max_luns' was not declared. Should it be static? drivers/scsi/bnx2fc/bnx2fc_fcoe.c:121:6: warning: symbol 'bnx2fc_queue_depth' was not declared. Should it be static? drivers/scsi/bnx2fc/bnx2fc_fcoe.c:126:6: warning: symbol 'bnx2fc_log_fka' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200912033758.142601-1-yanaijie@huawei.comReported-by:
-
Jason Yan authored
This eliminates the following sparse warning: drivers/scsi/isci/init.c:145:25: warning: symbol 'isci_host_attrs' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200912033741.142415-1-yanaijie@huawei.comReported-by:
-
Jason Yan authored
This eliminates the following sparse warning: drivers/scsi/aacraid/aachba.c:245:5: warning: symbol 'aac_convert_sgl' was not declared. Should it be static? drivers/scsi/aacraid/aachba.c:293:5: warning: symbol 'acbsize' was not declared. Should it be static? drivers/scsi/aacraid/aachba.c:324:5: warning: symbol 'aac_wwn' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200912033749.142488-1-yanaijie@huawei.comReported-by:
-
Ye Bin authored
If (x_status & XE_PARITY_ERR) is true we set cam_status = DID_PARITY, othervise cam_status always ends up being DID_ERROR. Delete superfluous else-if statements. Link: https://lore.kernel.org/r/20200902061646.576966-1-yebin10@huawei.comSigned-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
-
Brian King authored
When a canister on a FS9100, or similar storage, running in NPIV mode, is rebooted, its WWPNs will fail over to another canister. When this occurs, we see a WWPN going away from the fabric at one N-Port ID, and, a short time later, the same WWPN appears at a different N-Port ID. When the canister is fully operational again, the WWPNs fail back to the original canister. If there is any I/O outstanding to the target when this occurs, it will result in the implicit logout the ibmvfc driver issues before removing the rport to fail. When the WWPN then shows up at a different N-Port ID, and we issue a PLOGI to it, the VIOS will see that it still has a login for this WWPN at the old N-Port ID, which results in the VIOS simulating a link down / link up sequence to the client, in order to get the VIOS and client LPAR in sync. The patch below improves the way we handle this scenario so as to avoid the link bounce, which affects all targets under the virtual host adapter. The change is to utilize the Move Login MAD, which will work even when I/O is outstanding to the target. The change only alters the target state machine for the case where the implicit logout fails prior to deleting the rport. If this implicit logout fails, we defer deleting the ibmvfc_target object after calling fc_remote_port_delete. This enables us to later retry the implicit logout after terminate_rport_io occurs, or to issue the Move Login request if a WWPN shows up at a new N-Port ID prior to this occurring. This has been tested by IBM's storage interoperability team on a FS9100, forcing the failover to occur. With debug tracing enabled in the ibmvfc driver, we confirmed the move login was sent in this scenario and confirmed the link bounce no longer occurred. [mkp: fix checkpatch warnings] Link: https://lore.kernel.org/r/1599859706-8505-1-git-send-email-brking@linux.vnet.ibm.comSigned-off-by:
-
Damien Le Moal authored
Add missing Additional Sense Codes listed in http://www.t10.org/lists/asc-num.txt. Link: https://lore.kernel.org/r/20200910074843.217661-3-damien.lemoal@wdc.comReviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
-
Damien Le Moal authored
No need for else after return. Link: https://lore.kernel.org/r/20200910074843.217661-2-damien.lemoal@wdc.comReviewed-by:
-
Xiongfeng Wang authored
The tcmu 'global_max_data_area_mb' parameter in sysfs is missing a newline. Add it. Link: https://lore.kernel.org/r/1599132573-33818-1-git-send-email-wangxiongfeng2@huawei.comSigned-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by:
-
Daejun Park authored
Boot occasionally fails with some Samsung low-power UFS devices. The reason is that these devices have a little bit higher latency for NOP OUT responses. This causes boot to fail because the NOP OUT command is issued during initialization to check whether the device transport protocol is ready or not. Increase NOP_OUT_TIMEOUT value from 30 to 50ms. Link: https://lore.kernel.org/r/231786897.01599016081767.JavaMail.epsvc@epcpadp2Acked-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Daejun Park <daejun7.park@samsung.com> Signed-off-by:
-
- 15 Sep, 2020 2 commits
-
-
Tomas Henzl authored
There is no need to compute modulo. A simple comparison is good enough. Link: https://lore.kernel.org/r/20200911180057.14633-1-thenzl@redhat.comAcked-by:
sreekanth reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Tomas Henzl authored
_base_process_reply_queue() called from _base_interrupt() may schedule a new irq poll. Fix this by calling synchronize_irq() first. Also ensure that enable_irq() is called only when necessary to avoid "Unbalanced enable for IRQ..." errors. Link: https://lore.kernel.org/r/20200910142126.8147-1-thenzl@redhat.com Fixes: 320e77ac ("scsi: mpt3sas: Irq poll to avoid CPU hard lockups") Acked-by:
-
