| Message ID | 20220729075519.4665-1-stanley.chu@mediatek.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [v1] scsi: ufs: Fix ufshcd_scale_clks decision in recovery flow | expand |
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()? Thanks, Bart.
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? Thanks, Stanley > > Thanks, > > Bart.
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.
Hi Bart, On Tue, Aug 2, 2022 at 1:34 AM Bart Van Assche <bvanassche@acm.org> wrote: > > 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? It looks like that some callers do not obtain hba->host_sem. I will fix this in the next version. The direct callers of ufshcd_host_reset_and_restore() are, - ufshcd_link_recovery(), host_sem is obtained by its callers: ufshcd_err_handler() and ufshcd_wl_resume() - ufshcd_reset_and_restore(): the same as above - __ufshcd_wl_suspend(): host_sem is obtained by the caller ufshcd_wl_suspend() but not obtained by other callers. Thanks, Stanley
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);
When someone toggles clk-scaling feature via sysfs interface, the flag "hba->clk_scaling.is_enabled" shall be changed after ufshcd_devfreq_scale() is finished. By this change, we can use this flag to make right decision for invoking ufshcd_scale_clks() in host recovery flow, i.e., in ufshcd_host_reset_and_restore(). ufshcd_scale_clks() shall be invoked only if both conditions are satisfied, 1. Clk-scaling is supported, and 2. Clk-scaling is enabled Otherwise, the clk and gear which would be scaled by ufshcd_scale_clks() shall be already in the default state so the scaling is not required anymore. Signed-off-by: Stanley Chu <stanley.chu@mediatek.com> --- drivers/ufs/core/ufshcd.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)