From: sashiko-bot@kernel.org
To: "Bean Huo" <beanhuo@iokpp.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2 4/4] scsi: ufs: core: Report the current clock frequency to devfreq
Date: Mon, 07 Sep 2026 19:35:32 +0000 [thread overview]
Message-ID: <20260907193533.6919B1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260907192140.2701755-5-beanhuo@iokpp.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Lockless read of shared frequency states (target_freq and curr_freq) introduces a data race.
--
commit 33056f7bc209eb72a0cfba73ae939b67d7a4ed81
Author: Bean Huo <beanhuo@micron.com>
scsi: ufs: core: Report the current clock frequency to devfreq
When a driver does not provide a ->get_cur_freq() callback, the cur_freq
sysfs attribute shows devfreq->previous_freq. This commit adds a
->get_cur_freq() callback to report the current clock frequency accurately.
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 351c76094b9ff..bac95e891de5d 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -1711,6 +1711,26 @@ static int ufshcd_devfreq_get_dev_status(struct device *dev,
> return 0;
> }
>
> +static int ufshcd_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
> +{
> + struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> + if (!ufshcd_is_clkscaling_supported(hba))
> + return -EINVAL;
> +
> + if (hba->use_pm_opp) {
> + *freq = hba->clk_scaling.target_freq;
[Severity: Low]
Is it possible for this lockless read of target_freq to race with frequency
scaling updates?
If the devfreq sysfs cur_freq attribute is read concurrently with updates like
ufshcd_clkscale_enable_store() or ufshcd_devfreq_target(), could it trigger a
KCSAN data race warning or result in a stale read? Should this be protected or
use READ_ONCE()?
> + } else {
> + struct ufs_clk_info *clki;
> +
> + clki = list_first_entry(&hba->clk_list_head,
> + struct ufs_clk_info, list);
> + *freq = clki->curr_freq;
[Severity: Low]
Similarly, could this lockless read of curr_freq race with updates in the same
way? Might READ_ONCE() be needed here to formally resolve the race?
> + }
> +
> + return 0;
> +}
> +
> static int ufshcd_devfreq_init(struct ufs_hba *hba)
> {
> struct list_head *clk_list = &hba->clk_list_head;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260907192140.2701755-1-beanhuo@iokpp.de?part=4
next prev parent reply other threads:[~2026-09-07 19:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 19:21 [PATCH v2 0/4] devfreq: check the get_cur_freq() return value and use it in ufshcd Bean Huo
2026-09-07 19:21 ` [PATCH v2 1/4] PM / devfreq: Fall back to previous_freq when get_cur_freq() fails Bean Huo
2026-09-07 19:33 ` sashiko-bot
2026-09-07 20:29 ` Bean Huo
2026-09-07 19:21 ` [PATCH v2 2/4] PM / devfreq: Add more details to the get_cur_freq() comment Bean Huo
2026-09-07 19:21 ` [PATCH v2 3/4] scsi: ufs: core: Record the frequency the controller starts at Bean Huo
2026-09-07 19:41 ` sashiko-bot
2026-09-07 20:50 ` Bean Huo
2026-09-07 19:21 ` [PATCH v2 4/4] scsi: ufs: core: Report the current clock frequency to devfreq Bean Huo
2026-09-07 19:35 ` sashiko-bot [this message]
2026-09-07 20:23 ` Bean Huo
2026-09-08 1:34 ` [PATCH v2 0/4] devfreq: check the get_cur_freq() return value and use it in ufshcd Stanley Jhu
2026-09-10 2:28 ` Martin K. Petersen (Oracle)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260907193533.6919B1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=beanhuo@iokpp.de \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).