From: sashiko-bot@kernel.org
To: phucduc.bui@gmail.com
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org,
wsa+renesas@sang-engineering.com, robh@kernel.org
Subject: Re: [PATCH v6 08/11] ASoC: renesas: fsi: refactor clock initialization
Date: Tue, 09 Jun 2026 12:06:21 +0000 [thread overview]
Message-ID: <20260609120622.386C31F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260609113836.45079-9-phucduc.bui@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Unconditional clock initialization during probe breaks the driver on slave-only platforms due to clkdev fallback.
Pre-existing issues:
- [High] Logic error in fsi_clk_enable() prevents concurrent playback and capture streams.
--
commit 83020abc14f73339100e18d0f7451918e1591b37
Author: bui duc phuc <phucduc.bui@gmail.com>
ASoC: renesas: fsi: refactor clock initialization
Move fsi_clk_init() from set_fmt() to the probe path to ensure that clock
resources are acquired only once during device initialization.
> diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
> index e29be2bcf952c..43bc77ebcca39 100644
> --- a/sound/soc/renesas/fsi.c
> +++ b/sound/soc/renesas/fsi.c
[ ... ]
> @@ -970,35 +980,35 @@ static int fsi_clk_set_rate_cpg(struct device *dev,
> return ret;
> }
>
> -static int fsi_clk_init(struct device *dev,
> - struct fsi_priv *fsi,
> - int xck,
> - int ick,
> - int div,
> - int (*set_rate)(struct device *dev,
> - struct fsi_priv *fsi))
> +static int fsi_clk_init(struct device *dev, struct fsi_priv *fsi)
> {
[ ... ]
> /* external clock */
> if (xck) {
> clock->xck = devm_clk_get_optional(dev, is_porta ? "xcka" : "xckb");
> - if (IS_ERR(clock->xck)) {
> - dev_err(dev, "can't get xck clock\n");
> - return -EINVAL;
> - }
> + if (IS_ERR(clock->xck))
> + return dev_err_probe(dev, PTR_ERR(clock->xck), "Can't get xck clock\n");
> if (clock->xck == clock->own) {
> dev_err(dev, "cpu doesn't support xck clock\n");
> return -EINVAL;
> }
[ ... ]
> @@ -1672,15 +1678,6 @@ static int fsi_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> break;
> }
>
> - if (fsi_is_clk_master(fsi)) {
> - if (fsi->clk_cpg)
> - fsi_clk_init(dai->dev, fsi, 0, 1, 1,
> - fsi_clk_set_rate_cpg);
> - else
> - fsi_clk_init(dai->dev, fsi, 1, 1, 0,
> - fsi_clk_set_rate_external);
> - }
> -
> /* set format */
> if (fsi_is_spdif(fsi))
> ret = fsi_set_fmt_spdif(fsi);
[ ... ]
> @@ -1978,6 +1975,11 @@ static int fsi_probe(struct platform_device *pdev)
> fsi->master = master;
> fsi_port_info_init(fsi, &info.port_a);
> fsi_handler_init(fsi, &info.port_a);
> + ret = fsi_clk_init(&pdev->dev, fsi);
> + if (ret) {
> + dev_err(&pdev->dev, "FSIA clk init failed\n");
> + return ret;
> + }
[Severity: High]
By removing the fsi_is_clk_master() check from fsi_dai_set_fmt() and calling
fsi_clk_init() unconditionally here during probe(), does this break the
driver on slave-only platforms?
On older platforms using clkdev, looking up missing optional clocks like
xckb or ickb can trigger a fuzzy-match fallback to the device's main
functional clock. When devm_clk_get_optional() returns this fallback clock
instead of NULL, the check in fsi_clk_init() for (clock->xck == clock->own)
evaluates to true and returns -EINVAL.
Since fsi_clk_init() is now executed unconditionally for all ports, will this
cause legitimately configured slave ports (which lack explicit master clocks)
to fail probe entirely?
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the clock
handling, I noticed a pre-existing issue in fsi_clk_enable() that prevents
concurrent streams:
sound/soc/renesas/fsi.c:fsi_clk_enable() {
int ret = -EINVAL;
if (!fsi_clk_is_valid(fsi))
return ret;
if (0 == clock->count) {
...
}
...
return ret;
}
When a second concurrent stream starts (for example, capture during
playback), the function skips the if (0 == clock->count) block. Because
ret is initialized to -EINVAL, the function incorrectly returns -EINVAL
instead of 0.
Does this cause fsi_hw_startup() to fail and abort the stream trigger,
permanently preventing full-duplex operation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609113836.45079-1-phucduc.bui@gmail.com?part=8
next prev parent reply other threads:[~2026-06-09 12:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 11:38 [PATCH v6 00/11] ASoC: renesas: fsi: Fix system hang by adding SPU clock phucduc.bui
2026-06-09 11:38 ` [PATCH v6 01/11] ASoC: dt-bindings: renesas,fsi: add support multiple clocks phucduc.bui
2026-06-09 11:50 ` sashiko-bot
2026-06-09 16:04 ` Krzysztof Kozlowski
2026-06-09 11:38 ` [PATCH v6 02/11] ARM: dts: renesas: r8a7740: Add clocks for FSI phucduc.bui
2026-06-09 11:38 ` [PATCH v6 03/11] ASoC: renesas: fsi: Fix trigger stop ordering phucduc.bui
2026-06-09 12:01 ` sashiko-bot
2026-06-09 11:38 ` [PATCH v6 04/11] ASoC: renesas: fsi: Move fsi_stream_is_working() phucduc.bui
2026-06-09 11:51 ` sashiko-bot
2026-06-09 11:38 ` [PATCH v6 05/11] ASoC: renesas: fsi: Fix register access from in-flight IRQ after shutdown phucduc.bui
2026-06-09 11:59 ` sashiko-bot
2026-06-09 11:38 ` [PATCH v6 06/11] ASoC: renesas: fsi: Move fsi_clk_init() phucduc.bui
2026-06-09 11:55 ` sashiko-bot
2026-06-09 11:38 ` [PATCH v6 07/11] ASoC: renesas: fsi: Use devm_clk_get_optional() for optional clocks phucduc.bui
2026-06-09 11:56 ` sashiko-bot
2026-06-09 11:38 ` [PATCH v6 08/11] ASoC: renesas: fsi: refactor clock initialization phucduc.bui
2026-06-09 12:06 ` sashiko-bot [this message]
2026-06-09 11:38 ` [PATCH v6 09/11] ASoC: renesas: fsi: Add SPU clock support phucduc.bui
2026-06-09 11:38 ` [PATCH v6 10/11] ASoC: renesas: fsi: add fsi_clk_prepare/unprepare() phucduc.bui
2026-06-09 12:08 ` sashiko-bot
2026-06-09 11:38 ` [PATCH v6 11/11] ASoC: renesas: fsi: Add SPU clock control in hw_startup/shutdown phucduc.bui
2026-06-09 12:10 ` sashiko-bot
2026-06-09 23:24 ` Mark Brown
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=20260609120622.386C31F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=phucduc.bui@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wsa+renesas@sang-engineering.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.