- Jun 28, 2022
-
-
Po-Wen Kao authored
Add interfaces for controlling the host power to optimize the power consumption in MediaTek UFS platforms. Link: https://lore.kernel.org/r/20220623035052.18802-7-stanley.chu@mediatek.com Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Po-Wen Kao <powen.kao@mediatek.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Po-Wen Kao authored
In MediaTek UFS platforms, UniPro will not return reset confirm if it is in POWERDOWN state thus hang issue may happen while disabling UFSHCI. Simply disable this feature before UniPro leaves POWERDOWN state. Link: https://lore.kernel.org/r/20220623035052.18802-6-stanley.chu@mediatek.com Reviewed-by:
-
Peter Wang authored
Add "PRE_CHANGE" and "POST_CHANGE" information for ref-clk control to precisely configure the low-power state of the parent of ref-clk. Link: https://lore.kernel.org/r/20220623035052.18802-5-stanley.chu@mediatek.com Reviewed-by:
Peter Wang <peter.wang@mediatek.com> Signed-off-by:
-
Peter Wang authored
Some UFSHCI hosts in MediaTek UFS platform need workaround to prevent host hang issue by setting CLK_CG bit before host is enabled. This operation shall have no side effect on those platforms which do not support this bit. Link: https://lore.kernel.org/r/20220623035052.18802-4-stanley.chu@mediatek.com Reviewed-by:
-
Peter Wang authored
MediaTek decides to always add delays before and after VCC is turned-off. Link: https://lore.kernel.org/r/20220623035052.18802-3-stanley.chu@mediatek.com Reviewed-by:
-
Stanley Chu authored
Fix build warnings: 1. ../drivers/ufs/host/ufs-mediatek.c:1375:5: error: no previous prototype for function 'ufs_mtk_system_suspend' [-Werror,-Wmissing-prototypes] int ufs_mtk_system_suspend(struct device *dev) ^ ../drivers/ufs/host/ufs-mediatek.c:1375:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int ufs_mtk_system_suspend(struct device *dev) ^ static 2. ../drivers/ufs/host/ufs-mediatek.c:702:50: error: format specifies type 'unsigned long' but the argument has type 'int' [-Werror,-Wformat] snprintf(vcc_name, MAX_VCC_NAME, "vcc-ufs%lu", ver); ~~~ ^~~ %d Link: https://lore.kernel.org/r/20220623035052.18802-2-stanley.chu@mediatek.com Reviewed-by: -
Arnd Bergmann authored
The dpt_i2o driver was fixed to stop using virt_to_bus() in 2008, but it still has a stale reference in an error handling code path that could never work. I submitted a patch to fix this reference earlier, but Hannes Reinecke suggested that removing the driver may be just as good here. The i2o driver layer was removed in 2015 with commit 4a72a7af ("staging: remove i2o subsystem"), but the even older dpt_i2o scsi driver stayed around. The last non-cleanup patches I could find were from Miquel van Smoorenburg and Mark Salyzyn back in 2008, they might know if there is any chance of the hardware still being used anywhere. Link: https://lore.kernel.org/linux-scsi/CAK8P3a1XfwkTOV7qOs1fTxf4vthNBRXKNu8A5V7TWnHT081NGA@mail.gmail.com/T/ Link: https://lore.kernel.org/r/20220624155226.2889613-3-arnd@kernel.org Cc: Miquel van Smoorenburg <mikevs@xs4all.net> Cc: Mark Salyzyn <salyzyn@android.com> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
The BusLogic driver is the last remaining driver that relies on the deprecated bus_to_virt() function, which in turn only works on a few architectures, and is incompatible with both swiotlb and iommu support. Before commit 391e2f25 ("[SCSI] BusLogic: Port driver to 64-bit."), the driver had a dependency on x86-32, presumably because of this problem. However, the change introduced another bug that made it still impossible to use the driver on any 64-bit machine. This was in turn fixed in commit 56f39614 ("scsi: BusLogic: Fix 64-bit system enumeration error for Buslogic"), 8 years later, which shows that there are not a lot of users. Maciej is still using the driver on 32-bit hardware, and Khalid mentioned that the driver works with the device emulation used in VirtualBox and VMware. Both of those only emulate it for Windows 2000 and older operating systems that did not ship with the better LSI logic driver. Do a minimum fix that searches through the list of descriptors to find one that matches the bus address. This is clearly as inefficient as was indicated in the code comment about the lack of a bus_to_virt() replacement. A better fix would likely involve changing out the entire descriptor allocation for a simpler one, but that would be much more invasive. Link: https://lore.kernel.org/r/20220624155226.2889613-2-arnd@kernel.org Cc: Maciej W. Rozycki <macro@orcam.me.uk> Cc: Matt Wang <wwentao@vmware.com> Tested-by:
Khalid Aziz <khalid@gonehiking.org> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Acked-by:
-
Colin Ian King authored
Variable wlen is being assigned a value that is never read, it is being re-assigned with a different value later on. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/scsi/fcoe/fcoe.c:1491:2: warning: Value stored to 'wlen' is never read [deadcode.DeadStores] Link: https://lore.kernel.org/r/20220623164710.76831-1-colin.i.king@gmail.com Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
For code safety, constify arrays and pointers to data which is not modified. Link: https://lore.kernel.org/r/20220623102432.108059-4-krzysztof.kozlowski@linaro.org Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Krzysztof Kozlowski authored
For code safety, constify pointers to data which is not modified. Link: https://lore.kernel.org/r/20220623102432.108059-3-krzysztof.kozlowski@linaro.org Reviewed-by:
-
- Jun 22, 2022
-
-
Varun Prakash authored
Link: https://lore.kernel.org/r/20220612121340.6746-1-varun@chelsio.com Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Tetsuo Handa authored
It seems to me that mpt3sas driver is using dedicated workqueues and is not calling schedule{,_delayed}_work{,_on}(). Then, there will be no work to flush using flush_scheduled_work(). Link: https://lore.kernel.org/r/f3b97c7c-1094-4e46-20d8-4321716d6f3f@I-love.SAKURA.ne.jp Signed-off-by:Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
Changyuan Lyu authored
Trace events like scsi_dispatch_cmd_start and scsi_dispatch_cmd_done are useful for tracking a command throughout its lifetime. But for some ATA passthrough commands, the information printed in current logs is not enough to identify and match them. For example, if two threads send SMART cmd to the same disk at the same time, their trace logs may look the same, which makes it hard to match scsi_dispatch_cmd_done and scsi_dispatch_cmd_start. Printing tags can help us solve the problem. Further, if a command failed for some reason and then is retried, its driver_tag will change. So scheduler_tag is also included such that we can track the retries of a command. Link: https://lore.kernel.org/r/20220621181125.3211399-1-changyuanl@google.com Reviewed-by:
Vishakha Channapattan <vishakhavc@google.com> Reviewed-by:
Jolly Shah <jollys@google.com> Reviewed-by:
Changyuan Lyu <changyuanl@google.com> Signed-off-by:
-
Jiang Jian authored
Remove redundant "with" in comment Link: https://lore.kernel.org/r/20220621162631.25353-1-jiangjian@cdjrlc.com Signed-off-by:
Jiang Jian <jiangjian@cdjrlc.com> Signed-off-by:
-
Jiang Jian authored
Remove redundant "on" in comment. Link: https://lore.kernel.org/r/20220621150136.9264-1-jiangjian@cdjrlc.com Signed-off-by:
-
Wolfram Sang authored
Should be "retries" instead of "retires". Link: https://lore.kernel.org/r/20220621144653.62630-1-wsa+renesas@sang-engineering.com Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Jiang Jian authored
Remove redundant "the" in comment. Link: https://lore.kernel.org/r/20220621142346.6429-1-jiangjian@cdjrlc.com Signed-off-by:
-
Jiang Jian authored
Remove redundant "the" in comment". Link: https://lore.kernel.org/r/20220621142012.4622-1-jiangjian@cdjrlc.com Signed-off-by:
-
Jiang Jian authored
Redundant "the" in the comments can be dropped. Link: https://lore.kernel.org/r/20220621103119.91492-1-jiangjian@cdjrlc.com Signed-off-by:
-
Jiang Jian authored
Properly align comment lines in slot_index_alloc_quirk_v2_hw(). Link: https://lore.kernel.org/r/20220621072405.34394-1-jiangjian@cdjrlc.com Signed-off-by:
-
Zhang Jiaming authored
There is a spelling mistake in _base_sas_ioc_info(). Change 'cant' to 'can't'. Also fix up whitespace. Link: https://lore.kernel.org/r/20220617101103.3162-1-jiaming@nfschina.com Signed-off-by:
Zhang Jiaming <jiaming@nfschina.com> Signed-off-by:
-
Ren Yu authored
Spelling mistake in comment: non-succesfull -> non-successful. Link: https://lore.kernel.org/r/20220617081557.9009-1-renyu@nfschina.com Signed-off-by:
Ren Yu <renyu@nfschina.com> Signed-off-by:
-
Bo Liu authored
Use ida_alloc_xxx()/ida_free() instead of ida_simple_get()/ida_simple_remove(). The latter is deprecated and more verbose. Link: https://lore.kernel.org/r/20220617020430.2300-1-liubo03@inspur.com Signed-off-by:
Bo Liu <liubo03@inspur.com> Signed-off-by:
-
Mike Christie authored
The conn_send_pdu API is evil in that it returns a pointer to an iscsi_task, but that task might have been freed already so you can't touch it. This patch splits the task allocation and transmission, so functions like iscsi_send_nopout() can access the task before its sent and do whatever bookkeeping is needed before it is sent. Link: https://lore.kernel.org/r/20220616224557.115234-10-michael.christie@oracle.com Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Mike Christie authored
We need the back lock when freeing a task, so we hold it when calling __iscsi_put_task() from the completion path to make it easier and to avoid having to retake it in that path. For iscsi_put_task() we just grabbed it while also doing the decrement on the refcount but it's only really needed if the refcount is zero and we free the task. This modifies iscsi_put_task() to just take the lock when needed then has the xmit path use it. Normally we will then not take the back lock from the xmit path. It will only be rare cases where the network is so fast that we get a response right after we send the header/data. Link: https://lore.kernel.org/r/20220616224557.115234-9-michael.christie@oracle.com Reviewed-by:
-
Mike Christie authored
We currently require that the back_lock is held when calling the functions that manipulate the iscsi_task refcount. The only reason for this is to handle races where we are handling SCSI-ml EH callbacks and the cmd is completing at the same time the normal completion path is running, and we can't return from the EH callback until the driver has stopped accessing the cmd. Holding the back_lock while also accessing the task->state made it simple to check that a cmd is completing and also get/put a refcount at the same time, and at the time we were not as concerned about performance. The problem is that we don't want to take the back_lock from the xmit path for normal I/O since it causes contention with the completion path if the user has chosen to try and split those paths on different CPUs (in this case abusing the CPUs and ignoring caching improves perf for some uses). Begins to remove the back_lock requirement for iscsi_get/put_task by removing the requirement for the get path. Instead of always holding the back_lock we detect if something has done the last put and is about to call iscsi_free_task(). A subsequent commit will then allow iSCSI code to do the last put on a task and only grab the back_lock if the refcount is now zero and it's going to call iscsi_free_task(). Link: https://lore.kernel.org/r/20220616224557.115234-8-michael.christie@oracle.com Reviewed-by:
-
Mike Christie authored
Commit 5923d64b ("scsi: libiscsi: Drop taskqueuelock") added an extra task->state because for commit 6f8830f5 ("scsi: libiscsi: add lock around task lists to fix list corruption regression") we didn't know why we ended up with cmds on the list and thought it might have been a bad target sending a response while we were still sending the cmd. We were never able to get a target to send us a response early, because it turns out the bug was just a race in libiscsi/libiscsi_tcp where: 1. iscsi_tcp_r2t_rsp() queues a r2t to tcp_task->r2tqueue. 2. iscsi_tcp_task_xmit() runs iscsi_tcp_get_curr_r2t() and sees we have a r2t. It dequeues it and iscsi_tcp_task_xmit() starts to process it. 3. iscsi_tcp_r2t_rsp() runs iscsi_requeue_task() and puts the task on the requeue list. 4. iscsi_tcp_task_xmit() sends the data for r2t. This is the final chunk of data, so the cmd is done. 5. target sends the response. 6. On a different CPU from #3, iscsi_complete_task() processes the response. Since there was no common lock for the list, the lists/tasks pointers are not fully in sync, so could end up with list corruption. Since it was just a race on our side, remove the extra check and fix up the comments. Link: https://lore.kernel.org/r/20220616224557.115234-7-michael.christie@oracle.com Reviewed-by:
Wu Bo <wubo40@huawei.com> Reviewed-by:
-
Mike Christie authored
For software iSCSI, we do a session per host so there is no need to set the target's can_queue since it's the same as the host one. Setting it just results in extra atomic checks in the main I/O path. Link: https://lore.kernel.org/r/20220616224557.115234-6-michael.christie@oracle.com Reviewed-by:
-
Mike Christie authored
If we have more data, set the MSG_SENDPAGE_NOTLAST in case we go down the sendpage path. Link: https://lore.kernel.org/r/20220616224557.115234-5-michael.christie@oracle.com Reviewed-by:
-
Mike Christie authored
We don't always want to run the recv path from the network softirq because when we have to have multiple sessions sharing the same CPUs, some sessions can eat up the NAPI softirq budget and affect other sessions or users. Allow us to queue the recv handling to the iscsi workqueue so we can have the scheduler/wq code try to balance the work and CPU use across all sessions' worker threads. Note: It wasn't the original intent of the change but a nice side effect is that for some workloads/configs we get a nice performance boost. For a simple read heavy test: fio --direct=1 --filename=/dev/dm-0 --rw=randread --bs=256K --ioengine=libaio --iodepth=128 --numjobs=4 where the iscsi threads, fio jobs, and rps_cpus share CPUs we see a 32% throughput boost. We also see increases for small I/O IOPs tests but it's not as high. Link: https://lore.kernel.org/r/20220616224557.115234-4-michael.christie@oracle.com Reviewed-by: -
Mike Christie authored
Add helpers to allow the drivers to run their recv paths from libiscsi's workqueue. Link: https://lore.kernel.org/r/20220616224557.115234-3-michael.christie@oracle.com Reviewed-by:
-
Mike Christie authored
Rename iscsi_conn_queue_work() to iscsi_conn_queue_xmit() to reflect that it handles queueing of xmits only. Link: https://lore.kernel.org/r/20220616224557.115234-2-michael.christie@oracle.com Reviewed-by:
-
Mike Christie authored
When the system is shutting down, iscsid is not running so we will not get a response to the ISCSI_ERR_INVALID_HOST error event. The system shutdown will then hang waiting on userspace to remove the session. This has libiscsi force the destruction of the session from the kernel when iscsi_host_remove() is called from a driver's shutdown callout. This fixes a regression added in qedi boot with commit d1f2ce77 ("scsi: qedi: Fix host removal with running sessions") which made qedi use the common session removal function that waits on userspace instead of rolling its own kernel based removal. Link: https://lore.kernel.org/r/20220616222738.5722-7-michael.christie@oracle.com Fixes: d1f2ce77 ("scsi: qedi: Fix host removal with running sessions") Tested-by:
Nilesh Javali <njavali@marvell.com> Reviewed-by:
-
Mike Christie authored
When handling errors that lead to host removal use QEDI_MODE_NORMAL. There is currently no difference in behavior between NORMAL and SHUTDOWN, but in a subsequent commit we will want to know when we are called from the pci_driver shutdown callout vs remove/err_handler so we know when userspace is up. Link: https://lore.kernel.org/r/20220616222738.5722-6-michael.christie@oracle.com Tested-by:
-
Mike Christie authored
During qedi shutdown we need to stop the iSCSI layer from sending new nops as pings and from responding to target ones and make sure there is no running connection cleanups. Commit d1f2ce77 ("scsi: qedi: Fix host removal with running sessions") converted the driver to use the libicsi helper to drive session removal, so the above issues could be handled. The problem is that during system shutdown iscsid will not be running so when we try to remove the root session we will hang waiting for userspace to reply. Add a helper that will drive the destruction of sessions like these during system shutdown. Link: https://lore.kernel.org/r/20220616222738.5722-5-michael.christie@oracle.com Tested-by:
-
Mike Christie authored
In the next patch we allow drivers to drive session removal during shutdown. In this case iscsid will not be running, so we need to detect bound endpoints and disconnect them. This moves the bound ep check so we now always check. Link: https://lore.kernel.org/r/20220616222738.5722-4-michael.christie@oracle.com Tested-by:
-
Mike Christie authored
iscsi_if_stop_conn() is only called from the userspace interface but in a subsequent commit we will want to call it from the kernel interface to allow drivers like qedi to remove sessions from inside the kernel during shutdown. This removes the iscsi_uevent code from iscsi_if_stop_conn() so we can call it in a new helper. Link: https://lore.kernel.org/r/20220616222738.5722-3-michael.christie@oracle.com Tested-by:
-
Mike Christie authored
If qla4xxx doesn't remove the connection before the session, the iSCSI class tries to remove the connection for it. We were doing a iscsi_put_conn() in the iter function which is not needed and will result in a use after free because iscsi_remove_conn() will free the connection. Link: https://lore.kernel.org/r/20220616222738.5722-2-michael.christie@oracle.com Tested-by:
-
Ren Zhijie authored
If CONFIG_PM_SLEEP is not set. make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will fail: drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_vreg_fix_vcc’: drivers/ufs/host/ufs-mediatek.c:688:46: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%u", res.a1); ~^ ~~~~~~ %lu drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_suspend’: drivers/ufs/host/ufs-mediatek.c:1371:8: error: implicit declaration of function ‘ufshcd_system_suspend’; did you mean ‘ufs_mtk_system_suspend’? [-Werror=implicit-function-declaration] ret = ufshcd_system_suspend(dev); ^~~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_suspend drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_resume’: drivers/ufs/host/ufs-mediatek.c:1386:9: error: implicit declaration of function ‘ufshcd_system_resume’; did you mean ‘ufs_mtk_system_resume’? [-Werror=implicit-function-declaration] return ufshcd_system_resume(dev); ^~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_resume cc1: some warnings being treated as errors The declaration of func "ufshcd_system_suspend()" depends on CONFIG_PM_SLEEP, so the function wrapper ufs_mtk_system_suspend() should wrapped by CONFIG_PM_SLEEP too. Link: https://lore.kernel.org/r/20220619115432.205504-1-renzhijie2@huawei.com Fixes: 3fd23b8d ("scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators") Reported-by:Hulk Robot <hulkci@huawei.com> Reviewed-by:
Ren Zhijie <renzhijie2@huawei.com> Signed-off-by:
-
