Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Geert Uytterhoeven" <geert+renesas@glider.be>
Cc: neil.armstrong@linaro.org, linux-clk@vger.kernel.org,
	linux-phy@lists.infradead.org, olteanv@gmail.com,
	vkoul@kernel.org
Subject: Re: [PATCH 1/2] phy: freescale: fsl-samsung-hdmi: Make sure clk_init_data is fully initialized
Date: Fri, 21 Aug 2026 10:19:31 +0000	[thread overview]
Message-ID: <20260821101931.B162B1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <3c3be1c676eea5d32102864c57643b1573bc0db0.1787240165.git.geert+renesas@glider.be>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] A global static variable is mutated during clock rate queries, causing data races and state corruption with PM resume operations.
--

--- Patch [1]: [PATCH 1/2] phy: freescale: fsl-samsung-hdmi: Make sure clk_init_data is fully initialized ---
commit eace776c1e0b617b09367e8f7566adff67211a9f
Author: Geert Uytterhoeven <geert+renesas@glider.be>

phy: freescale: fsl-samsung-hdmi: Make sure clk_init_data is fully initialized

The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need.  However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.

> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> index d010fec15671d..76c0d571e3155 100644
> --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -610,7 +610,7 @@ static int phy_clk_register(struct fsl_samsung_hdmi_phy *phy)
>  {
>  	struct device *dev = phy->dev;
>  	struct device_node *np = dev->of_node;
> -	struct clk_init_data init;
> +	struct clk_init_data init = {};
>  	const char *parent_name;
>  	struct clk *phyclk;
>  	int ret;

[Severity: High]
This is a pre-existing issue, but does mutating the global static variable
calculated_phy_pll_cfg during side-effect-free clock queries cause state
corruption?

In fsl_samsung_hdmi_phy_find_settings(), the global variable is modified
unconditionally:

drivers/phy/freescale/phy-fsl-samsung-hdmi.c:fsl_samsung_hdmi_phy_find_settings() {
    ...
	/* Calculate the integer divider */
	int_div_clk = fsl_samsung_hdmi_phy_find_pms(rate, &p, &m, &s);
	fsl_samsung_hdmi_calculate_phy(&calculated_phy_pll_cfg, int_div_clk, p, m, s);
    ...
}

Then in fsl_samsung_hdmi_phy_configure(), a pointer to this global is saved:

drivers/phy/freescale/phy-fsl-samsung-hdmi.c:fsl_samsung_hdmi_phy_configure() {
    ...
	phy->cur_cfg = cfg;
    ...
}

If a clock driver sets a rate (saving the pointer) and later performs a
clk_round_rate() query, the query will overwrite calculated_phy_pll_cfg.

When the device resumes, it restores the hardware using this potentially
corrupted pointer:

drivers/phy/freescale/phy-fsl-samsung-hdmi.c:fsl_samsung_hdmi_phy_resume() {
    ...
	if (phy->cur_cfg)
		ret = fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
    ...
}

Can this lead to the hardware being restored to an incorrect frequency
upon PM resume?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787240165.git.geert+renesas@glider.be?part=1

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-08-21 10:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 10:08 [PATCH 0/2] phy: Make sure clk_init_data is fully initialized Geert Uytterhoeven
2026-08-21 10:08 ` [PATCH 1/2] phy: freescale: fsl-samsung-hdmi: " Geert Uytterhoeven
2026-08-21 10:19   ` sashiko-bot [this message]
2026-08-21 10:08 ` [PATCH 2/2] phy: rockchip: " Geert Uytterhoeven
2026-08-21 10:29   ` 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=20260821101931.B162B1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /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