- 07 Dec, 2020 13 commits
-
-
Can Guo authored
Serialize eh_work with system PM events and async scan to make sure eh_work does not run in parallel with them. Link: https://lore.kernel.org/r/1606910644-21185-2-git-send-email-cang@codeaurora.orgReviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Asutosh Das <asutoshd@codeaurora.org> Reviewed-by:
Hongwu Su <hongwus@codeaurora.org> Signed-off-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Stanley Chu authored
UFS specficication allows different VCC configurations for UFS devices, for example: (1). 2.70V - 3.60V (Activated by default in UFS core driver) (2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in device tree) (3). 2.40V - 2.70V (Supported since UFS 3.x) With the introduction of UFS 3.x products, an issue is happening that UFS driver will use wrong "min_uV-max_uV" values to configure the voltage of VCC regulator on UFU 3.x products with the configuration (3) used. To solve this issue, we simply remove pre-defined initial VCC voltage values in UFS core driver with below reasons, 1. UFS specifications do not define how to detect the VCC configuration supported by attached device. 2. Device tree already supports standard regulator properties. Therefore VCC voltage shall be defined correctly in device tree, and shall not changed by UFS driver. What UFS driver needs to do is simply enable or disable the VCC regulator only. Similar change is applied to VCCQ and VCCQ2 as well. Note that we keep struct ufs_vreg unchanged. This allows vendors to configure proper min_uV and max_uV of any regulators to make regulator_set_voltage() works during regulator toggling flow in the future. Without specific vendor configurations, min_uV and max_uV will be NULL by default and UFS core driver will enable or disable the regulator only without adjusting its voltage. Link: https://lore.kernel.org/r/20201202091819.22363-1-stanley.chu@mediatek.comReviewed-by:Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
Stanley Chu authored
Use phy_initialization helper instead of direct invocation. Link: https://lore.kernel.org/r/20201205120041.26869-5-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Use phy_initialization helper instead of direct function invocation. Link: https://lore.kernel.org/r/20201205120041.26869-4-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Introduce phy_initialization helper since this is the only one variant function without helper. Link: https://lore.kernel.org/r/20201205120041.26869-3-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Since setup_regulators variant function is not used by any vendors, simply remove it. Link: https://lore.kernel.org/r/20201205120041.26869-2-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Introduce event_notify implementation on MediaTek UFS platform. A vendor-specific tracepoint is added that can be used for debugging purposes. Link: https://lore.kernel.org/r/20201205115901.26815-5-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Introduce event_notify variant function to allow vendor to get notification of important events and connect to any proprietary debugging facilities. Link: https://lore.kernel.org/r/20201205115901.26815-4-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
The UFS error history does not only have "history of errors" but also a log of some other events which are not defined as errors. This patch fixes the confused naming of related functions and changes the approach for updating and printing history in preparation of next patch. This patch does not change any functionality. Link: https://lore.kernel.org/r/20201205115901.26815-3-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Add error history for abort event in UFS Device W-LUN. Use specified value as parameter of ufshcd_update_reg_hist() to identify the aborted tag or LUNs. Link: https://lore.kernel.org/r/20201205115901.26815-2-stanley.chu@mediatek.comReviewed-by:
-
Qinglang Miao authored
kfree(conn) is called inside put_device(&conn->dev) which could lead to use-after-free. In addition, device_unregister() should be used here rather than put_deviceO(). Link: https://lore.kernel.org/r/20201120074852.31658-1-miaoqinglang@huawei.com Fixes: f3c893e3 ("scsi: iscsi: Fail session and connection on transport registration failure") Reported-by:
Hulk Robot <hulkci@huawei.com> Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
Zhang Qilong authored
The driver did not return an error in the case where pm8001_configure_phy_settings() failed. Use rc to store the return value of pm8001_configure_phy_settings(). Link: https://lore.kernel.org/r/20201205115551.2079471-1-zhangqilong3@huawei.com Fixes: 27909407 ("[SCSI] pm80xx: Phy settings support for motherboard controller.") Acked-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by:
-
Qinglang Miao authored
Add the missing destroy_workqueue() before return from __qedi_probe in the error handling case when fails to create workqueue qedi->offload_thread. Link: https://lore.kernel.org/r/20201109091518.55941-1-miaoqinglang@huawei.com Fixes: ace7f46b ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Reviewed-by:
-
- 02 Dec, 2020 9 commits
-
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple of warnings by explicitly adding a break statement and a fallthrough pseudo-keyword instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/761d6f755e8a6f8a6daebd1e5c1394167e5c780a.1605896059.git.gustavoars@kernel.orgSigned-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/20a7bcc10af2b762325c7078a4f472121a4fabc7.1605896060.git.gustavoars@kernel.orgSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/fff8d6f1d33b9e2c94dbe024a4f8df22866d3bf8.1605896060.git.gustavoars@kernel.orgSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/b77ee091548f16b52056c3b9ee8c76dc6691f868.1605896060.git.gustavoars@kernel.orgSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/e9fc10eb7d843e6f31e50400d428bd7a217684ac.1605896060.git.gustavoars@kernel.orgSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/e4e25e57964a69f7173f868ff93df9d6d08f360f.1605896060.git.gustavoars@kernel.orgSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding a couple break statements and replacing /* fall through */ comments with the new pseudo-keyword macro fallthrough; instead of just letting the code fall through to the next case. Notice that Clang doesn't recognize /* fall through */ comments as implicit fall-through markings. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/2ae1cafd858238b85fc5e7fe5cc183843e21ec9f.1605896059.git.gustavoars@kernel.orgSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding a couple of break and fallthrough statements instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/9b58459045d303bbea0160f2e349f5799402a2bf.1605896059.git.gustavoars@kernel.orgSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of just letting the code fall through to the next case, and by adding fallthrough statements in places where the code is intended to fall through, and finally by replacing /* FALLTHROUGH */ comments with the new pseudo-keyword macro fallthrough. Link: https://github.com/KSPP/linux/issues/115 Link: https://lore.kernel.org/r/1a7cd2f77623e6ab46bbec0b6103b18491419206.1605896059.git.gustavoars@kernel.orgSigned-off-by:
-
- 01 Dec, 2020 18 commits
-
-
James Smart authored
smatch correctly called out a logic error with accessing a pointer after checking it for null: drivers/scsi/lpfc/lpfc_els.c:2043 lpfc_cmpl_els_plogi() error: we previously assumed 'ndlp' could be null (see line 1942) Adjust the exit point to avoid the trace printf ndlp reference. A trace entry was already generated when the ndlp was checked for null. Link: https://lore.kernel.org/r/20201130181226.16675-1-james.smart@broadcom.com Fixes: 4430f7fd ("scsi: lpfc: Rework locations of ndlp reference taking") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Can Guo authored
Instead of hardcoding the scale down gear, make it a member of the ufs_clk_scaling struct. Link: https://lore.kernel.org/r/1606442334-22641-1-git-send-email-cang@codeaurora.orgReviewed-by:
Bean Huo <beanhuo@micron.com> Reviewed-by:
-
Can Guo authored
If we want to disable clocks to save power but still keep the link active, core_clk_unipro, like ref_clk, should not be the one being disabled. Link: https://lore.kernel.org/r/1606356063-38380-3-git-send-email-cang@codeaurora.orgReviewed-by:
-
Can Guo authored
Remove the param skip_ref_clk from __ufshcd_setup_clocks(), but keep a flag in struct ufs_clk_info to tell whether a clock can be disabled or not while the link is active. Link: https://lore.kernel.org/r/1606356063-38380-2-git-send-email-cang@codeaurora.orgReviewed-by:
-
Sebastian Andrzej Siewior authored
mptsas_cleanup_fw_event_q() uses in_interrupt() to determine if it is safe to cancel a worker item. Aside of that in_interrupt() is deprecated as it does not provide what the name suggests. It covers more than hard/soft interrupt servicing context and is semantically ill defined. Looking closer there are a few problems with the current construct: - It could be invoked from an interrupt handler / non-blocking context because cancel_delayed_work() has no such restriction. Also, mptsas_free_fw_event() has no such restriction. - The list is accessed unlocked. It may dequeue a valid work-item but at the time of invoking cancel_delayed_work() the memory may be released or reused because the worker has already run. mptsas_cleanup_fw_event_q() is invoked via mptsas_shutdown() which is always invoked from preemtible context on device shutdown. It is also invoked via mptsas_ioc_reset(, MPT_IOC_POST_RESET) which is a MptResetHandlers callback. The only caller here are mpt_SoftResetHandler(), mpt_HardResetHandler() and mpt_Soft_Hard_ResetHandler(). All these functions have a `sleepFlag' argument and each caller uses caller uses `CAN_SLEEP' here and according to current documentation: | @sleepFlag: Indicates if sleep or schedule must be called So it is safe to sleep. Add mptsas_hotplug_event::users member. Initialize it to one by default so mptsas_free_fw_event() will free the memory. mptsas_cleanup_fw_event_q() will increment its value for items it dequeues and then it may keep a pointer after dropping the lock. Invoke cancel_delayed_work_sync() to cancel the work item and wait if the worker is currently busy. Free the memory afterwards since it owns the last reference to it. Link: https://lore.kernel.org/r/20201126132952.2287996-15-bigeasy@linutronix.de Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: MPT-FusionLinux.pdl@broadcom.com Reviewed-by:
Daniel Wagner <dwagner@suse.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Thomas Gleixner authored
in_interrupt() is referenced all over the place in these drivers. Most of these references are comments which are outdated and wrong. Aside of that in_interrupt() is deprecated as it does not provide what the name suggests. It covers more than hard/soft interrupt servicing context and is semantically ill defined. >From reading the mpt_config() code and the history this is clearly a debug mechanism and should probably be replaced by might_sleep() or completely removed because such checks are already in the subsequent functions. Remove the in_interrupt() references and replace the usage in mpt_config() with might_sleep(). Link: https://lore.kernel.org/r/20201126132952.2287996-14-bigeasy@linutronix.de Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: MPT-FusionLinux.pdl@broadcom.com Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Ahmed S. Darwish authored
The in_interrupt() macro is ill-defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree-wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As wait_for_completion() already contains a broad variety of checks (always enabled or debug option dependent) which cover all invalid conditions already, there is no point in having extra inconsistent warnings in drivers. Just remove it. Link: https://lore.kernel.org/r/20201126132952.2287996-12-bigeasy@linutronix.de Cc: Hannes Reinecke <hare@kernel.org> Reviewed-by:
Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by:
-
Ahmed S. Darwish authored
The in_interrupt() macro is ill-defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree-wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As wait_for_completion() already contains a broad variety of checks (always enabled or debug option dependent) which cover all invalid conditions already, there is no point in having extra inconsistent warnings in drivers. Just remove it. Link: https://lore.kernel.org/r/20201126132952.2287996-11-bigeasy@linutronix.de Cc: Hannes Reinecke <hare@kernel.org> Reviewed-by:
-
Ahmed S. Darwish authored
_scsih_fw_event_cleanup_queue() waits for all outstanding firmware events wokrqueue handlers to finish. If in_interrupt() is true, it cancels itself and return early. That in_interrupt() check is ill-defined and does not provide what the name suggests: it does not cover all states in which it is safe to block and call functions like cancel_work_sync(). That check is also not needed: _scsih_fw_event_cleanup_queue() is always invoked from process context. Below is an analysis of its callers: - scsih_remove(), bound to PCI ->remove(), process context - scsih_shutdown(), bound to PCI ->shutdown(), process context - mpt3sas_scsih_clear_outstanding_scsi_tm_commands(), called by => _base_clear_outstanding_commands(), called by =>_base_fault_reset_work(), workqueue => mpt3sas_base_hard_reset_handler(), locks mutex Remove the in_interrupt() check. Change _scsih_fw_event_cleanup_queue() specification to a purely process-context function and mark it with "Context: task, can sleep". Link: https://lore.kernel.org/r/20201126132952.2287996-10-bigeasy@linutronix.de Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Cc: <MPT-FusionLinux.pdl@broadcom.com> Reviewed-by: -
Ahmed S. Darwish authored
qla4_82xx_rom_lock() spins on a certain hardware state until it is updated. At the end of each spin, if in_interrupt() is true, it does 20 loops of cpu_relax(). Otherwise, it yields the CPU. While in_interrupt() is ill-defined and does not provide what the name suggests, it is not needed here: qla4_82xx_rom_lock() is always called from process context. Below is an analysis of its callers: - ql4_nx.c: qla4_82xx_rom_fast_read(), all process context callers: => ql4_nx.c: qla4_82xx_pinit_from_rom(), GFP_KERNEL allocation => ql4_nx.c: qla4_82xx_load_from_flash(), msleep() in a loop - ql4_nx.c: qla4_82xx_pinit_from_rom(), earlier discussed - ql4_nx.c: qla4_82xx_rom_lock_recovery(), bound to "isp_operations" ->rom_lock_recovery() hook, which has one process context caller, qla4_8xxx_device_bootstrap(), with callers: => ql4_83xx.c: qla4_83xx_need_reset_handler(), process, msleep() => ql4_nx.c: qla4_8xxx_device_state_handler(), multiple msleep()s - ql4_nx.c: qla4_82xx_read_flash_data(), has cond_resched() Remove the in_interrupt() check. Mark, qla4_82xx_rom_lock(), and the ->rom_lock_recovery() hook, with "Context: task, can sleep". Change qla4_82xx_rom_lock() implementation to sleep 20ms, instead of a schedule(), for each spin. This is more deterministic, and it matches the other implementations bound to ->rom_lock_recovery(). Link: https://lore.kernel.org/r/20201126132952.2287996-9-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: Manish Rangankar <mrangankar@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by: -
Ahmed S. Darwish authored
qla4_82xx_idc_lock() spins on a certain hardware state until it is updated. At the end of each spin, if in_interrupt() is true, it does 20 loops of cpu_relax(). Otherwise, it yields the CPU. While in_interrupt() is ill-defined and does not provide what the name suggests, it is not needed here: qla4_82xx_idc_lock() is always called from process context. Below is an analysis of its callers: - ql4_nx.c: qla4_82xx_need_reset_handler(), 1-second msleep() in a loop. - ql4_nx.c: qla4_82xx_isp_reset(), calls qla4_8xxx_device_state_handler(), which has multiple msleep()s. Beside direct calls, qla4_82xx_idc_lock() is also bound to isp_operations ->idc_lock() hook. Other functions which are bound to the same hook, e.g. qla4_83xx_drv_lock(), also have an msleep(). For completeness, below is an analysis of all callers of that hook: - ql4_83xx.c: qla4_83xx_need_reset_handler(), has an msleep() - ql4_83xx.c: qla4_83xx_isp_reset(), calls qla4_8xxx_device_state_handler(), which has multiple msleep()s. - ql4_83xx.c: qla4_83xx_disable_pause(), all process context callers: => ql4_mbx.c: qla4xxx_mailbox_command(), msleep(), mutex_lock() => ql4_os.c: qla4xxx_recover_adapter(), schedule_timeout() in loop => ql4_os.c: qla4xxx_do_dpc(), workqueue context - ql4_attr.c: qla4_8xxx_sysfs_write_fw_dump(), sysfs bin_attribute ->write() hook, process context - ql4_mbx.c: qla4xxx_mailbox_command(), earlier discussed - ql4_nx.c: qla4_8xxx_device_bootstrap(), callers: => ql4_83xx.c: qla4_83xx_need_reset_handler(), process, msleep() => ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed - ql4_nx.c: qla4_8xxx_need_qsnt_handler(), callers: => ql4_nx.c: qla4_8xxx_device_state_handler(), multiple msleep()s => ql4_os.c: qla4xxx_do_dpc(), workqueue context - ql4_nx.c: qla4_8xxx_update_idc_reg(), callers: => ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed => ql4_os.c: qla4_8xxx_error_recovery(), only called by qla4xxx_pci_slot_reset(), which is bound to PCI ->slot_reset() process-context hook - ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed - ql4_os.c: qla4xxx_recover_adapter(), earlier discussed - ql4_os.c: qla4xxx_do_dpc(), earlier discussed Remove the in_interrupt() check. Mark, qla4_82xx_idc_lock(), and the ->idc_lock() hook itself, with "Context: task, can sleep". Change qla4_82xx_idc_lock() implementation to sleep 100ms, instead of a schedule(), for each spin. This is more deterministic, and it matches other PCI HW locking functions in the driver. Link: https://lore.kernel.org/r/20201126132952.2287996-8-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: Manish Rangankar <mrangankar@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by: -
Ahmed S. Darwish authored
qla83xx_wait_logic() is used to control the frequency of device IDC lock retries. If in_interrupt() is true, it does 20 loops of cpu_relax(). Otherwise, it sleeps for 100ms and yields the CPU. While in_interrupt() is ill-defined and does not provide what the name suggests, it is not needed here: that qla83xx_wait_logic() is exclusively called by qla83xx_idc_lock() / unlock(), and they always run from process context. Below is an analysis of all the idc lock/unlock callers, in order of appearance: - qla_os.c: qla83xx_nic_core_unrecoverable_work(), qla83xx_idc_state_handler_work(), qla83xx_nic_core_reset_work(), qla83xx_service_idc_aen(), all workqueue context - qla_os.c: qla83xx_check_nic_core_fw_alive(), has msleep() - qla_os.c: qla83xx_set_drv_presence(), called once from qla2x00_abort_isp(), which is bound to process-context ->abort_isp() hook. It also invokes wait_for_completion_timeout() through the chain qla2x00_configure_hba() => qla24xx_link_initialize() => qla2x00_mailbox_command(). - qla_os.c: qla83xx_clear_drv_presence(), which is called from qla2x00_abort_isp() discussed above, and from qla2x00_remove_one() which is PCI process-context ->remove() hook. - qla_os.c: qla83xx_need_reset_handler(), has a one second msleep() in a loop. - qla_os.c: qla83xx_device_bootstrap(), called only by qla83xx_idc_state_handler(), which has multiple msleep() invocations. - qla_os.c: qla83xx_idc_state_handler(), multiple msleep() invocations. - qla_attr.c: qla2x00_sysfs_write_reset(), sysfs bin_attribute ->write() hook, process context - qla_init.c: qla83xx_nic_core_fw_load() => qla_init.c: qla2x00_initialize_adapter() => bound to isp_operations ->initialize_adapter() hook ** => qla_os.c: qla2x00_probe_one(), PCI ->probe() process ctx - qla_init.c: qla83xx_initiating_reset(), msleep() in a loop. - qla_init.c: qla83xx_nic_core_reset(), called by qla83xx_nic_core_reset_work(), workqueue context. Remove the in_interrupt() check, and thus replace the entirety of qla83xx_wait_logic() with an msleep(QLA83XX_WAIT_LOGIC_MS). Mark qla83xx_idc_lock() / unlock() with "Context: task, can sleep". Link: https://lore.kernel.org/r/20201126132952.2287996-7-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: GR-QLogic-Storage-Upstream@marvell.com Reviewed-by:Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by:
-
Ahmed S. Darwish authored
tcm_qla2xxx_free_session() has a BUG_ON(in_interrupt()). While in_interrupt() is ill-defined and does not provide what the name suggests, it is not needed here: the function is always invoked from workqueue context through "struct qla_tgt_func_tmpl" ->free_session() hook it is bound to. The function also calls wait_event_timeout() down the chain, which already has a might_sleep(). Remove the in_interrupt() check. Link: https://lore.kernel.org/r/20201126132952.2287996-6-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by:
-
Ahmed S. Darwish authored
qla82xx_idc_lock() spins on a certain hardware state until it's updated. At the end of each spin, if in_interrupt() is true, it does 20 loops of cpu_relax(). Otherwise, it yields the CPU. While in_interrupt() is ill-defined and does not provide what the name suggests, it is not needed here: qla82xx_idc_lock() is always called from process context. Below is an analysis of its callers, in order of appearance: - qla_nx.c: qla82xx_device_bootstrap(), only called by qla82xx_device_state_handler(), has multiple msleep()s. - qla_nx.c: qla82xx_need_qsnt_handler(), has one second msleep() - qla_nx.c: qla82xx_wait_for_state_change(), one second msleep() - qla_nx.c: qla82xx_need_reset_handler(), can sleep up to 10 seconds - qla_nx.c: qla82xx_device_state_handler(), has multiple msleep()s - qla_nx.c: qla82xx_abort_isp(), if it's a qla82xx controller, calls qla82xx_device_state_handler(), which sleeps. It's also bound to isp_operations ->abort_isp() hook, where all the callers are in process context. - qla_nx.c: qla82xx_beacon_on(), bound to isp_operations ->beacon_on() hook. That hook is only called once, in a mutex locked context, from qla2x00_beacon_store(). - qla_nx.c: qla82xx_beacon_off(), bound to isp_operations ->beacon_off() hook. Like ->beacon_on(), it's only called once, in a mutex locked context, from qla2x00_beacon_store(). - qla_nx.c: qla82xx_fw_dump(), calls qla2x00_wait_for_chip_reset(), which has msleep() in a loop. It is bound to isp_operations ->fw_dump() hook. That hook *is* called from atomic context at qla_isr.c by multiple interrupt handlers. Nonetheless, it's other controllers interrupt handlers, and not the qla82xx. - qla82xx_msix_default() and qla82xx_msix_rsp_q() call qla24xx_process_response_queue() which doesn't implement the firmware dumping. - qla_attr.c: qla2x00_sysfs_write_fw_dump(), and qla2x00_sysfs_write_reset(), process-context sysfs ->write() hooks. - qla_os.c: qla2x00_probe_one(). PCI ->probe(), process context. - qla_os.c: qla2x00_clear_drv_active(), called solely from qla2x00_remove_one(), which is PCI ->remove() hook, process context. - qla_os.c: qla2x00_do_dpc(), kthread function, process context. Remove the in_interrupt() check. Change qla82xx_idc_lock() specification to a purely process-context function. Mark it with "Context: task, might sleep". Change qla82xx_idc_lock() implementation to sleep 100ms, instead of a schedule(), for each spin. This is more deterministic, and it matches the other qla models idc_lock() functions. Link: https://lore.kernel.org/r/20201126132952.2287996-5-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by: -
Ahmed S. Darwish authored
qla4_82xx_crb_win_lock() spins on a certain hardware state until it's updated. At the end of each spin, if in_interrupt() is true, it does 20 loops of cpu_relax(). Otherwise, it yields the CPU. The in_interrupt() macro is ill-defined as it does not provide what the name suggests, and it does not catch the intended use-case here. qla4_82xx_crb_win_lock() is always invoked with scsi_qla_host::hw_lock acquired, with disabled interrupts. If the caller is in process context, as in qla4_82xx_need_reset_handler(), then in_interrupt() will return false even though it is not allowed to call schedule(). Remove the in_interrupt() check. Change qla4_82xx_crb_win_lock() specification to a purely atomic function. Mark it as static, remove its forward declaration, and move it above its callers. To avoid hammering the PCI bus while spinning, use a 10 micro-second delay instead of cpu_relax(). Link: https://lore.kernel.org/r/20201126132952.2287996-4-bigeasy@linutronix.de Fixes: f4f5df23 ("[SCSI] qla4xxx: Added support for ISP82XX") Cc: Nilesh Javali <njavali@marvell.com> Cc: Manish Rangankar <mrangankar@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by:
-
Ahmed S. Darwish authored
hisi_sas_task_exec() uses preemptible() to see if it's safe to block. This does not work for CONFIG_PREEMPT_COUNT=n kernels in which preemptible() always returns 0. The problem is masked when enabling some of the common Kconfig.debug options (like CONFIG_DEBUG_ATOMIC_SLEEP), as they implicitly enable the preemption counter. In general, driver leaf functions should not make logic decisions based on the context they're called from. The caller should be the entity responsible for explicitly indicating context. Since hisi_sas_task_exec() already has a gfp_t flags parameter, use it as the explicit context marker. Link: https://lore.kernel.org/r/20201126132952.2287996-3-bigeasy@linutronix.de Fixes: 214e702d ("scsi: hisi_sas: Adjust task reject period during host reset") Fixes: 550c0d89 ("scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec()") Cc: Xiaofei Tan <tanxiaofei@huawei.com> Cc: Xiang Chen <chenxiang66@hisilicon.com> Cc: John Garry <john.garry@huawei.com> Acked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Ahmed S. Darwish authored
hw_event_sas_phy_up() is used in hardirq/softirq context: pm8001_interrupt_handler_msix() || pm8001_interrupt_handler_intx() || pm8001_tasklet => PM8001_CHIP_DISP->isr() = pm80xx_chip_isr() => process_oq() [spin_lock_irqsave(&pm8001_ha->lock,)] => process_one_iomb() => mpi_hw_event() => hw_event_sas_phy_up() => msleep(200) Revert the msleep() back to an mdelay() to avoid sleeping in atomic context. Link: https://lore.kernel.org/r/20201126132952.2287996-2-bigeasy@linutronix.de Fixes: 4daf1ef3 ("scsi: pm80xx: Convert 'long' mdelay to msleep") Cc: Vikram Auradkar <auradkar@google.com> Cc: Jack Wang <jinpu.wang@cloud.ionos.com> Acked-by: -
Bean Huo authored
In the case that auto_bkops_enable is false, which means auto bkops has been disabled, there is no need to call ufshcd_disable_auto_bkops(). Link: https://lore.kernel.org/r/20201125185300.3394-1-huobean@gmail.comReviewed-by:
-
