Messages in this thread | | | Date | Tue, 14 Jul 2020 12:17:11 +0800 | From | Can Guo <> | Subject | Re: [PATCH v2 3/4] ufs: ufs-qcom: Fix a few BUGs in func ufs_qcom_dump_dbg_regs() |
| |
Hi Bart,
On 2020-07-14 11:47, Bart Van Assche wrote: > On 2020-07-13 19:28, Can Guo wrote: >> Dumping testbus registers needs to sleep a bit intermittently as there >> are >> too many of them. Skip them for those contexts where sleep is not >> allowed. >> >> Meanwhile, if ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() >> from >> ufshcd_suspend/resume and/or clk gate/ungate context, >> pm_runtime_get_sync() >> and ufshcd_hold() will cause racing problems. Fix it by removing the >> unnecessary calls of pm_runtime_get_sync() and ufshcd_hold(). >> >> Signed-off-by: Can Guo <cang@codeaurora.org> >> --- >> drivers/scsi/ufs/ufs-qcom.c | 17 +++++++---------- >> 1 file changed, 7 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c >> index 2e6ddb5..3743c17 100644 >> --- a/drivers/scsi/ufs/ufs-qcom.c >> +++ b/drivers/scsi/ufs/ufs-qcom.c >> @@ -1604,9 +1604,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host >> *host) >> */ >> } >> mask <<= offset; >> - >> - pm_runtime_get_sync(host->hba->dev); >> - ufshcd_hold(host->hba, false); >> ufshcd_rmwl(host->hba, TEST_BUS_SEL, >> (u32)host->testbus.select_major << 19, >> REG_UFS_CFG1); >> @@ -1619,8 +1616,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host >> *host) >> * committed before returning. >> */ >> mb(); >> - ufshcd_release(host->hba); >> - pm_runtime_put_sync(host->hba->dev); >> >> return 0; >> } >> @@ -1658,11 +1653,13 @@ static void ufs_qcom_dump_dbg_regs(struct >> ufs_hba *hba) >> >> /* sleep a bit intermittently as we are dumping too much data */ >> ufs_qcom_print_hw_debug_reg_all(hba, NULL, >> ufs_qcom_dump_regs_wrapper); >> - udelay(1000); >> - ufs_qcom_testbus_read(hba); >> - udelay(1000); >> - ufs_qcom_print_unipro_testbus(hba); >> - udelay(1000); >> + if (in_task()) { >> + udelay(1000); >> + ufs_qcom_testbus_read(hba); >> + udelay(1000); >> + ufs_qcom_print_unipro_testbus(hba); >> + udelay(1000); >> + } >> } > > It is not clear to me how udelay() calls can help in code that takes > long > since these functions use busy-waiting? Should the udelay() calls > perhaps > be changed into cond_resched() calls? > > Thanks, > > Bart.
Maybe you are right, but this is not the purpose of this change. I am just trying to make sure this func can be invoked from any contexts without making troubles like schedule while atomic and/or race conditions.
Thanks,
Can Guo.
| |