[PATCH AUTOSEL 6.19-6.1] rtc: zynqmp: correct frequency value

[PATCH AUTOSEL 6.19-6.1] rtc: zynqmp: correct frequency value

[Sasha Levin]

From: Tomas Melin <tomas.melin@vaisala.com>

[ Upstream commit 2724fb4d429cbb724dcb6fa17953040918ebe3a2 ]

Fix calibration value in case a clock reference is provided.
The actual calibration value written into register is
frequency - 1.

Reviewed-by: Harini T <harini.t@amd.com>
Tested-by: Harini T <harini.t@amd.com>
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260122-zynqmp-rtc-updates-v4-1-d4edb966b499@vaisala.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### What the commit fixes

This commit fixes an off-by-one error in the RTC calibration value when
the frequency is obtained from a clock reference (via `clk_get_rate()`).
The ZynqMP RTC hardware register expects a calibration value of
`frequency - 1`, but the code was writing the raw frequency value
directly.

**Evidence:**
- `RTC_CALIB_DEF` = `0x7FFF` = 32767 = 32768 - 1 (the default is already
  correctly decremented)
- The `"calibration"` DT property presumably provides the register-ready
  value (already freq-1)
- But `clk_get_rate()` returns the raw clock rate (e.g., 32768), so it
  needs the `-1` adjustment
- Without the fix, the RTC counts one extra tick per second, causing
  time drift

### Code change assessment

The fix adds an `else` branch with `xrtcdev->freq--` when the frequency
comes from `clk_get_rate()` (i.e., when `xrtcdev->freq` is non-zero from
the clock). This is a 2-line addition, surgically targeted.

### Dependency analysis

The clock name fix `2a388ff22d2cb` ("rtc: zynqmp: Fix optional clock
name property") was already tagged `Cc: stable@kernel.org` and is
targeted at v6.14-rc1. Before that fix, the driver was looking for clock
name "rtc_clk" instead of "rtc" (matching the DT binding), so the clock-
based frequency path was effectively dead code. With `2a388ff22d2cb`
being backported to stable, the clock can now actually be found, making
this off-by-one bug reachable.

The underlying calibration infrastructure was introduced in
`07dcc6f9c762` (v6.0-rc1), so stable trees v6.1.y and later have the
affected code.

### Stable criteria evaluation

- **Fixes a real bug:** Yes - incorrect RTC calibration causes time
  drift
- **Obviously correct:** Yes - the register needs freq-1, this subtracts
  1
- **Small and contained:** Yes - 2 lines in one file
- **No new features:** Correct - purely fixes calibration logic
- **Tested:** Yes - has Tested-by and Reviewed-by from AMD engineer,
  Acked-by from Michal Simek

### Risk assessment

**Very low risk.** The change only affects the path where a clock
reference provides the frequency. It cannot break the default path
(`RTC_CALIB_DEF`) or the DT `"calibration"` property path. The worst
case if something were wrong would be an RTC running at the wrong rate -
exactly the same as the current bug.

### Verification

- Read the full driver source: confirmed `RTC_CALIB_DEF` = 0x7FFF =
  32767 (line 40)
- Verified `clk_get_rate()` returns raw frequency, not register value,
  per kernel API
- `git show 85cab027d4e31`: confirmed previous calibration fix changed
  default from 0x198233 to 0x7FFF (32768-1)
- `git show 07dcc6f9c762`: confirmed this is the commit that introduced
  clock-based calibration (v6.0-rc1)
- `git describe --contains 2a388ff22d2cb`: confirmed clock name fix is
  in v6.14-rc1, already tagged for stable
- `git describe --contains 07dcc6f9c762`: confirmed calibration support
  is in v6.0-rc1, present in all current stable trees
- The fix directly corresponds to the relationship: `RTC_CALIB_DEF`
  (default) = 0x7FFF = 32768 - 1, confirming the register semantics

This is a small, well-tested fix for incorrect RTC timekeeping. It's a
companion to the already-stable-tagged clock name fix. Without this fix,
any board using the ZynqMP RTC with a clock reference will have
incorrect time calibration.

**YES**

 drivers/rtc/rtc-zynqmp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
index 3baa2b481d9f2..856bc1678e7d3 100644
--- a/drivers/rtc/rtc-zynqmp.c
+++ b/drivers/rtc/rtc-zynqmp.c
@@ -345,7 +345,10 @@ static int xlnx_rtc_probe(struct platform_device *pdev)
 					   &xrtcdev->freq);
 		if (ret)
 			xrtcdev->freq = RTC_CALIB_DEF;
+	} else {
+		xrtcdev->freq--;
 	}
+
 	ret = readl(xrtcdev->reg_base + RTC_CALIB_RD);
 	if (!ret)
 		writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR));
-- 
2.51.0