From: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> [ Upstream commit 2f96afdffad4ef74e3c511207058c41c54a2d014 ] Since the sibling data is filled after the priv->clks[] array entry is populated, the first clock that is probed and has a sibling will temporarily behave as its own sibling until its actual sibling is populated. To avoid any issues, postpone updating priv->clks[] until after the sibling is populated. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> Link: https://lore.kernel.org/20250514090415.4098534-2-claudiu.beznea.uj@xxxxxxxxxxxxxx Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> --- LLM Generated explanations, may be completely bogus: **Backport Status: YES** This commit fixes a legitimate race condition bug in the Renesas RZ/G2L clock driver that affects coupled clock handling. Here's my detailed analysis: ## Bug Description The commit fixes a timing issue where `priv->clks[id]` was being populated BEFORE the sibling relationship was established for coupled clocks. This creates a race condition window where: 1. When the first coupled clock is registered, it gets added to `priv->clks[]` immediately 2. The `rzg2l_mod_clock_get_sibling()` function iterates through registered clocks looking for siblings 3. If the first clock looks for its sibling before the sibling is registered, it will find itself (since it's already in `priv->clks[]`) 4. This causes the clock to temporarily act as its own sibling until the actual sibling is registered ## Impact Analysis - **User-visible bug**: Yes - This can cause incorrect clock behavior for coupled clocks (e.g., AXI and CHI clocks that share control bits) - **Data corruption potential**: Possible - Incorrect clock handling could lead to hardware state inconsistencies - **Security impact**: Low - No direct security implications - **Regression risk**: Minimal - The fix simply reorders operations without changing logic ## Fix Characteristics The fix is: - **Small and contained**: Only 4 lines moved within the same function - **Low risk**: Simply postpones updating `priv->clks[id]` until after sibling setup - **Clear improvement**: Eliminates a race condition window - **No new features**: Pure bugfix - **No architectural changes**: Just reordering of operations ## Stable Kernel Criteria This commit meets stable kernel backporting criteria because it: 1. Fixes a real bug that affects users (coupled clock handling race condition) 2. Is minimal and self-contained (4-line change) 3. Has low regression risk (simple reordering) 4. Fixes incorrect hardware state handling 5. Has been reviewed by subsystem maintainer (Geert Uytterhoeven) The coupled clocks feature was introduced in commit 32897e6fff19 (Sep 2021), so this fix would be relevant for any stable kernel that includes that feature. The bug has existed since the coupled clocks support was added, making this an important fix for stable kernels using RZ/G2L SoCs. drivers/clk/renesas/rzg2l-cpg.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/clk/renesas/rzg2l-cpg.c b/drivers/clk/renesas/rzg2l-cpg.c index a8628f64a03b..c87ad5a972b7 100644 --- a/drivers/clk/renesas/rzg2l-cpg.c +++ b/drivers/clk/renesas/rzg2l-cpg.c @@ -1389,10 +1389,6 @@ rzg2l_cpg_register_mod_clk(const struct rzg2l_mod_clk *mod, goto fail; } - clk = clock->hw.clk; - dev_dbg(dev, "Module clock %pC at %lu Hz\n", clk, clk_get_rate(clk)); - priv->clks[id] = clk; - if (mod->is_coupled) { struct mstp_clock *sibling; @@ -1404,6 +1400,10 @@ rzg2l_cpg_register_mod_clk(const struct rzg2l_mod_clk *mod, } } + clk = clock->hw.clk; + dev_dbg(dev, "Module clock %pC at %lu Hz\n", clk, clk_get_rate(clk)); + priv->clks[id] = clk; + return; fail: -- 2.39.5
