[PATCH AUTOSEL 6.16-6.12] clk: renesas: rzg2l: Postpone updating priv->clks[]

[Sasha Levin <sashal@kernel.org>]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

[ 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@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250514090415.4098534-2-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

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