Messages in this thread | | | Date | Mon, 1 Aug 2022 10:34:51 -0700 | Subject | Re: [PATCH v1] scsi: ufs: Fix ufshcd_scale_clks decision in recovery flow | From | Bart Van Assche <> |
| |
On 7/30/22 00:08, Stanley Chu wrote: > Hi Bart, > > On Sat, Jul 30, 2022 at 4:12 AM Bart Van Assche <bvanassche@acm.org> wrote: >> >> On 7/29/22 00:55, Stanley Chu wrote: >>> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c >>> index 581d88af07ab..dc57a7988023 100644 >>> --- a/drivers/ufs/core/ufshcd.c >>> +++ b/drivers/ufs/core/ufshcd.c >>> @@ -1574,8 +1574,6 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev, >>> ufshcd_rpm_get_sync(hba); >>> ufshcd_hold(hba, false); >>> >>> - hba->clk_scaling.is_enabled = value; >>> - >>> if (value) { >>> ufshcd_resume_clkscaling(hba); >>> } else { >>> @@ -1586,6 +1584,8 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev, >>> __func__, err); >>> } >>> >>> + hba->clk_scaling.is_enabled = value; >>> + >>> ufshcd_release(hba); >>> ufshcd_rpm_put_sync(hba); >>> out: >>> @@ -7259,7 +7259,8 @@ static int ufshcd_host_reset_and_restore(struct ufs_hba *hba) >>> hba->silence_err_logs = false; >>> >>> /* scale up clocks to max frequency before full reinitialization */ >>> - ufshcd_scale_clks(hba, true); >>> + if (ufshcd_is_clkscaling_supported(hba) && hba->clk_scaling.is_enabled) >>> + ufshcd_scale_clks(hba, true); >>> >>> err = ufshcd_hba_enable(hba); >> >> I see a race condition between the hba->clk_scaling.is_enabled check in >> ufshcd_host_reset_and_restore() and the code that sets >> ufshcd_clkscale_enable_store(). Shouldn't the code in >> ufshcd_host_reset_and_restore() that scales up the clocks be serialized >> against ufshcd_clkscale_enable_store()? > > Both check and set paths are serialized by hba->host_sem currently. > > Would I miss any other unserialized paths?
Where in ufshcd_host_reset_and_restore() or in its callers is hba->host_sem obtained? I don't see it. Am I perhaps overlooking something?
Thanks,
Bart.
| |