From: sashiko-bot@kernel.org
To: phucduc.bui@gmail.com
Cc: wsa+renesas@sang-engineering.com, krzk+dt@kernel.org,
devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 07/10] ASoC: renesas: fsi: refactor clock initialization
Date: Mon, 11 May 2026 23:47:57 +0000 [thread overview]
Message-ID: <20260511234758.6C022C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260510084303.122426-8-phucduc.bui@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The return value of `fsi_clk_init()` is ignored in `fsi_probe()`, which breaks probe deferral and leads to a kernel panic from dereferencing error pointers.
--
commit 055b3b167e655ece1592450b8baaea9abe771d10
Author: bui duc phuc <phucduc.bui@gmail.com>
ASoC: renesas: fsi: refactor clock initialization
This commit moves fsi_clk_init() to probe and uses devm_clk_get_optional()
for optional clocks. It allows probe to succeed when optional clocks are
missing, while set_rate() validates clock availability.
> diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
> index 55a11f1fe8aa1..8c46d68069581 100644
> --- a/sound/soc/renesas/fsi.c
> +++ b/sound/soc/renesas/fsi.c
[ ... ]
> @@ -973,35 +983,42 @@ 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)
> {
[ ... ]
> clock->own = devm_clk_get(dev, NULL);
> if (IS_ERR(clock->own))
> return -EINVAL;
Does returning -EINVAL here mask probe deferral? If devm_clk_get() returns
-EPROBE_DEFER, returning -EINVAL will permanently fail the driver probe
rather than deferring it.
[ ... ]
> @@ -1997,6 +2001,7 @@ static int fsi_probe(struct platform_device *pdev)
> fsi->running_streams = 0;
> fsi_port_info_init(fsi, &info.port_a);
> fsi_handler_init(fsi, &info.port_a);
> + fsi_clk_init(&pdev->dev, fsi);
Is it safe to ignore the return value of fsi_clk_init() here?
If devm_clk_get_optional() fails and returns an error pointer like
-EPROBE_DEFER, those error pointers will be stored in the clock fields
instead of NULL.
Later, when fsi_clk_set_rate_external() checks if the clocks are missing:
if (!xck || !ick) {
This check will pass because the error pointers are not NULL. The error
pointers will then be passed to common clock framework APIs like
clk_get_rate(), which will dereference them and cause a crash.
Should the return value of fsi_clk_init() be checked and propagated?
> ret = fsi_stream_probe(fsi, &pdev->dev);
> if (ret < 0) {
> dev_err(&pdev->dev, "FSIA stream probe failed\n");
> @@ -2011,6 +2016,7 @@ static int fsi_probe(struct platform_device *pdev)
> fsi->running_streams = 0;
> fsi_port_info_init(fsi, &info.port_b);
> fsi_handler_init(fsi, &info.port_b);
> + fsi_clk_init(&pdev->dev, fsi);
Would the same return value check be needed here as well?
> ret = fsi_stream_probe(fsi, &pdev->dev);
> if (ret < 0) {
> dev_err(&pdev->dev, "FSIB stream probe failed\n");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510084303.122426-1-phucduc.bui@gmail.com?part=7
next prev parent reply other threads:[~2026-05-11 23:47 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 8:42 [PATCH v3 00/10] ASoC: renesas: fsi: Fix system hang by adding SPU clock phucduc.bui
2026-05-10 8:42 ` [PATCH v3 01/10] ASoC: dt-bindings: renesas,fsi: add support multiple clocks phucduc.bui
2026-05-11 7:30 ` Geert Uytterhoeven
2026-05-11 10:25 ` Bui Duc Phuc
2026-05-11 20:45 ` sashiko-bot
2026-05-12 6:42 ` Bui Duc Phuc
2026-05-14 15:17 ` Rob Herring
2026-05-15 7:21 ` Geert Uytterhoeven
2026-05-15 6:46 ` Krzysztof Kozlowski
2026-05-15 10:20 ` Bui Duc Phuc
2026-05-15 10:41 ` Bui Duc Phuc
2026-05-15 11:15 ` Krzysztof Kozlowski
2026-05-10 8:42 ` [PATCH v3 02/10] arm: dts: renesas: r8a7740: Add clocks for FSI phucduc.bui
2026-05-11 22:03 ` sashiko-bot
2026-05-15 6:58 ` Bui Duc Phuc
2026-05-10 8:42 ` [PATCH v3 03/10] ASoC: renesas: fsi: Fix trigger stop ordering phucduc.bui
2026-05-11 22:44 ` sashiko-bot
2026-05-10 8:42 ` [PATCH v3 04/10] ASoC: renesas: fsi: Fix register access from in-flight IRQ after shutdown phucduc.bui
2026-05-11 1:52 ` Kuninori Morimoto
2026-05-11 23:22 ` sashiko-bot
2026-05-10 8:42 ` [PATCH v3 05/10] ASoC: renesas: fsi: Move fsi_clk_init() phucduc.bui
2026-05-10 8:42 ` [PATCH v3 06/10] ASoC: renesas: fsi: Add shared SPU clock support phucduc.bui
2026-05-11 1:56 ` Kuninori Morimoto
2026-05-12 3:09 ` Bui Duc Phuc
2026-05-10 8:43 ` [PATCH v3 07/10] ASoC: renesas: fsi: refactor clock initialization phucduc.bui
2026-05-10 12:30 ` Mark Brown
2026-05-11 1:59 ` Kuninori Morimoto
2026-05-11 10:21 ` Bui Duc Phuc
2026-05-11 23:47 ` sashiko-bot [this message]
2026-05-10 8:43 ` [PATCH v3 08/10] ASoC: renesas: fsi: add fsi_clk_prepare/unprepare() phucduc.bui
2026-05-11 2:03 ` Kuninori Morimoto
2026-05-11 23:44 ` sashiko-bot
2026-05-10 8:43 ` [PATCH v3 09/10] ASoC: renesas: fsi: Use clock prepare handling in startup/shutdown phucduc.bui
2026-05-11 2:04 ` Kuninori Morimoto
2026-05-11 10:22 ` Bui Duc Phuc
2026-05-12 0:09 ` sashiko-bot
2026-05-10 8:43 ` [PATCH v3 10/10] ASoC: renesas: fsi: Add SPU clock control in hw_startup/shutdown phucduc.bui
2026-05-11 23:58 ` sashiko-bot
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=20260511234758.6C022C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=phucduc.bui@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko@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.