[PATCH AUTOSEL 7.0-6.6] dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply

[PATCH AUTOSEL 7.0-6.6] dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply

[Sasha Levin]

From: Frieder Schrempf <frieder.schrempf@kontron.de>

[ Upstream commit 10663044bee592ba049a2aa37f4431fbdf93b739 ]

In case the VDD supply voltage regulator of the RTC needs to be
specified explicitly, allow to set vdd-supply.

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260309085749.25747-2-frieder@fris.de
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
Backport this **with the companion DTS fix**. By itself it is a schema-
only change, but the mailing-list history verifies it was added because
the runtime DTS fix for Kontron i.MX8MP OSM RTC boot hangs was dropped
due to `dtb_check` warning: `'vdd-supply' is not allowed`. This patch is
a 2-line DT binding addition for existing hardware, reviewed by a DT
maintainer, and has essentially no runtime regression risk.

## Phase Walkthrough
1.1 Record: Subsystem `dt-bindings: rtc: microcrystal,rv3028`; action
verb `Allow`; intent is to permit `vdd-supply` in the RV3028 RTC
binding.

1.2 Record: Tags found: `Signed-off-by: Frieder Schrempf`, `Reviewed-by:
Krzysztof Kozlowski`, `Link:
https://patch.msgid.link/20260309085749.25747-2-frieder@fris.de`,
`Signed-off-by: Alexandre Belloni`. No `Fixes`, `Reported-by`, `Tested-
by`, or `Cc: stable`.

1.3 Record: Commit body says only that explicit VDD regulator
specification should be allowed. The series and v2 discussion verify the
concrete issue: the companion DTS fix adds `vdd-supply` so fw_devlink
orders PMIC before RTC, avoiding sporadic boot hangs.

1.4 Record: Hidden bug-fix context exists, but not in this patch alone.
This patch fixes a DT schema gap that blocked a real DTS boot-hang fix.

2.1 Record: One file changed,
`Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml`; 2
lines added; no functions; single-file schema change.

2.2 Record: Before, `unevaluatedProperties: false` rejected `vdd-
supply`. After, `vdd-supply: true` permits the regulator phandle.

2.3 Record: Bug category is DT schema/build-validation fix and
prerequisite for hardware dependency expression. Not memory safety,
locking, or runtime driver logic.

2.4 Record: Fix is obviously correct and minimal. Regression risk is
very low because it only relaxes schema validation for one standard
supply property.

3.1 Record: Blame shows the binding file was introduced by
`c690048ed59b5` in `v6.3-rc1`; `#clock-cells` was added by
`4015580e983da` in `v6.12-rc1`.

3.2 Record: Candidate has no `Fixes:` tag. Companion DTS patch fixes
`946ab10e3f40f`, introduced in `v6.13-rc1`.

3.3 Record: Recent binding history only shows the file creation and
`#clock-cells` addition. The patch is standalone, but its stable value
is tied to the companion DTS fix.

3.4 Record: Author has multiple Kontron DTS fixes in local history; not
the RTC maintainer, but the patch was reviewed by Krzysztof Kozlowski
and applied by Alexandre Belloni.

3.5 Record: No code dependencies. For meaningful runtime benefit,
backport with `arm64: dts: imx8mp-kontron: Fix boot order for PMIC and
RTC`.

4.1 Record: `b4 dig -c 10663044bee5` found the original v3 patch at the
supplied lore/msgid URL. `b4 dig -a` found v1 and v3 series history; v3
added the missing binding patch.

4.2 Record: `b4 dig -w` showed relevant DT/RTC maintainers and lists
were included.

4.3 Record: v2 discussion verified Frank Li dropped the DTS fix because
it caused `dtb_check` warning: `'vdd-supply' is not allowed`; Frieder
replied that v3 adds the binding patch.

4.4 Record: Series context is 2 patches in v3: this binding patch and
the DTS boot-order fix. Binding was applied by Alexandre Belloni; DTS
fix later applied by Frank Li.

4.5 Record: I found no stable-specific discussion or explicit stable
nomination.

5.1 Record: No functions modified.

5.2 Record: No callers. Semantic impact is DT schema validation.

5.3 Record: Verified runtime relevance through OF supplier parsing:
`drivers/of/property.c` has `DEFINE_SUFFIX_PROP(regulators, "-supply",
NULL)` and includes `parse_regulators` in supplier bindings.

5.4 Record: Companion DTS path is reachable during device probing on
Kontron i.MX8MP OSM. PMIC driver enables the I2C level translator when
`nxp,i2c-lt-enable` is present; RTC node sits on the same I2C bus.

5.5 Record: Similar `vdd-supply: true` properties exist in many
bindings, including another RTC binding, `amlogic,meson6-rtc.yaml`.

6.1 Record: Binding exists from `v6.3+`; Kontron OSM DTS exists from
`v6.13+`. `v6.1` lacks the binding file.

6.2 Record: `git apply --check` succeeded on existing `v6.6` and `v6.12`
worktrees and current `v7.0.1`; `v6.1` fails because the file does not
exist. A separate v6.19 temporary worktree attempt ran out of space
before testing, so direct v6.19 apply was not verified.

6.3 Record: No related stable fix already found in local history.

7.1 Record: Subsystem is DT binding documentation for RTC hardware;
criticality is peripheral, but it supports a board boot-hang fix.

7.2 Record: Subsystem/file is low churn: only binding creation and
`#clock-cells` addition before this patch.

8.1 Record: Affected population is users/builders of RV3028 DTs,
especially Kontron i.MX8MP OSM users when paired with the DTS fix.

8.2 Record: Trigger for the companion bug is boot/probe ordering where
RTC is accessed before PMIC enables the I2C level shifter. Trigger for
this patch alone is DT schema validation with `vdd-supply`.

8.3 Record: Candidate alone fixes a build/validation warning. Companion
failure mode is sporadic boot hang, which is critical for affected
hardware.

8.4 Record: Benefit is high when paired with the companion DTS fix, low
if isolated. Risk is very low: two schema lines, no runtime code.

9.1 Record: For backporting: tiny, reviewed, applies cleanly to relevant
trees, enables a verified hardware boot-hang fix, standard DT supply
property. Against: schema-only and no standalone runtime fix.

9.2 Record: Stable rules: obviously correct yes; real user bug
indirectly yes via companion DTS fix; important issue yes when paired,
boot hang; small yes; no runtime API/new driver yes; applies to
v6.6/v6.12/current, not v6.1.

9.3 Record: Exception category applies: DT binding addition for existing
hardware / build-validation support.

9.4 Record: Decision is YES, but it should be treated as a
prerequisite/companion to the DTS boot-order fix, not as a standalone
runtime fix.

## Verification
- Phase 1: Parsed supplied commit message and local b4 mbox; confirmed
  tags and absence of `Fixes`/stable tags.
- Phase 2: Read diff and current binding file; confirmed only `vdd-
  supply: true` is added.
- Phase 3: Used `git blame`, `git describe --contains`, and file
  history; confirmed binding introduction in `v6.3-rc1`, `#clock-cells`
  in `v6.12-rc1`, board DTS in `v6.13-rc1`.
- Phase 4: Used `b4 am`, `b4 mbox`, `b4 diff`, `b4 dig -a`, and `b4 dig
  -w`; verified v2 rejection due dtb_check warning and v3 addition of
  this binding patch.
- Phase 5: Searched/read OF supplier parsing and PCA9450 code; verified
  `*-supply` creates supplier links and PMIC `nxp,i2c-lt-enable` enables
  the I2C level translator.
- Phase 6: Checked stable tags/worktrees; apply check passes on v6.6,
  v6.12, and current tree; v6.1 lacks the file.
- Phase 7/8: Verified affected paths in Kontron DTS and binding; no
  runtime code touched.
- Unverified: Direct apply check on v6.19 due temporary worktree
  checkout failure, though v6.19 file contents were inspected and match
  the expected context.

**YES**

 Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
index cda8ad7c12037..2ea3b40419530 100644
--- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
+++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
@@ -32,6 +32,8 @@ properties:
       - 9000
       - 15000
 
+  vdd-supply: true
+
 required:
   - compatible
   - reg
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] rtc: max77686: convert to i2c_new_ancillary_device

[Sasha Levin]

From: Svyatoslav Ryhel <clamor95@gmail.com>

[ Upstream commit 0d65a9d93d870ef3d13642f88d0e6d562790c96d ]

Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.

This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20260312085258.11431-6-clamor95@gmail.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:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record 1.1: subsystem `rtc: max77686`; action verb `convert`; intent is
to replace hardcoded RTC I2C client creation with
`i2c_new_ancillary_device()` so DT can specify the RTC address.

Record 1.2: tags found: `Signed-off-by: Svyatoslav Ryhel
<clamor95@gmail.com>`, `Link:
https://patch.msgid.link/20260312085258.11431-6-clamor95@gmail.com`,
`Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or
`Cc: stable`.

Record 1.3: the bug is that MAX77663 RTC can be factory-set at either
`0x48` or `0x68`, but the driver always uses the MAX77620 default
`0x68`. The cover letter states this was tested on LG Optimus Vu P895
with a non-default RTC position and the RTC registered correctly.

Record 1.4: this is a hidden hardware correctness fix, not cleanup. It
lets existing supported MAX77663 hardware describe an otherwise
undetectable factory-set RTC address.

### Phase 2: Diff Analysis
Record 2.1: one file changed: `drivers/rtc/rtc-max77686.c`, `12
insertions`, `2 deletions`. Added `max77686_rtc_release_dev()`, modified
`max77686_init_rtc_regmap()`. Scope is single-file and surgical.

Record 2.2: before, the driver always called
`devm_i2c_new_dummy_device(..., info->drv_data->rtc_i2c_addr)`. After,
it calls `i2c_new_ancillary_device(parent_i2c, "rtc", default_addr)`,
then registers a devm cleanup action with `i2c_unregister_device()`.

Record 2.3: bug category is hardware workaround / logic correctness. The
broken mechanism is hardcoded secondary RTC I2C address selection for a
chip whose RTC address cannot be detected.

Record 2.4: fix quality is good. It preserves default behavior when DT
has no `reg-names = "rtc"` entry, uses an existing I2C helper, and has
low regression risk. The main risk is backport context conflicts in
older trees, not runtime behavior.

### Phase 3: Git History
Record 3.1: blame/history shows the RTC regmap setup dates back to
`f3937549a975` and the currently hardcoded devm dummy path to later
cleanups; MAX77663 support entered via `4c58f7012f15`, first contained
in `v5.2`, creating a `max77620-rtc` child that uses the `0x68` default.

Record 3.2: no `Fixes:` tag, so no Fixes target to follow.

Record 3.3: recent file history includes cleanup commits `6c9405fd2581`
and `e6403ae59ce1`; these explain why the exact patch applies cleanly to
`v7.0` but conflicts on older trees. They are not semantic
prerequisites.

Record 3.4: author has several Tegra/platform commits in history; the
RTC maintainer Alexandre Belloni committed/applied the patch.

Record 3.5: code dependency `i2c_new_ancillary_device()` exists in
checked stable tags `v5.4` through `v7.0`. Related binding commit
`3cef6765b75e` documents the DT form but is not required for the driver
to build or run.

### Phase 4: Mailing List / External Research
Record 4.1: `b4 dig -c 0d65a9d93d870` found the original patch at
`https://patch.msgid.link/20260312085258.11431-6-clamor95@gmail.com`.
`b4 dig -a` showed v1 through v4; committed version is v4 patch `5/5`.

Record 4.2: recipients included RTC, MFD, DT, GPIO, regulator, thermal
maintainers/lists, including Alexandre Belloni, Lee Jones, Rob Herring,
Mark Brown, and relevant lists.

Record 4.3: cover letter says the patch was tested on LG Optimus Vu P895
with non-default MAX77663 RTC address. No separate bugzilla/syzbot
report was found.

Record 4.4: patch was part of a 5-patch series mostly
converting/documenting bindings. Patch 4 documents the optional RTC
address and was reviewed by Rob Herring; patch 5 was applied by
Alexandre Belloni.

Record 4.5: WebFetch lore searches were blocked by Anubis. Local `git
log stable/linux-7.0.y` did not find this target commit already present
in the stable branch checked here.

### Phase 5: Code Semantic Analysis
Record 5.1: modified functions: added `max77686_rtc_release_dev()`,
modified `max77686_init_rtc_regmap()`.

Record 5.2: `max77686_init_rtc_regmap()` is called only by
`max77686_rtc_probe()`. The probe is registered through the
`max77686_rtc_driver` platform driver.

Record 5.3: key callees are `i2c_new_ancillary_device()`,
`devm_add_action_or_reset()`, `devm_regmap_init_i2c()`, and
`regmap_add_irq_chip()`.

Record 5.4: call chain is MFD `max77620_probe()` ->
`devm_mfd_add_devices()` creates `max77620-rtc` -> platform probe
`max77686_rtc_probe()` -> secondary RTC I2C client creation. This is
boot/device-probe reachable, not syscall-triggered.

Record 5.5: similar uses of `i2c_new_ancillary_device()` exist in other
drivers for secondary I2C addresses, and the helper documentation
confirms DT `reg`/`reg-names` lookup with default fallback.

### Phase 6: Stable Tree Analysis
Record 6.1: checked tags `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`,
`v6.12`, and `v7.0`: all contain `i2c_new_ancillary_device()`,
`max77620-rtc`, and the hardcoded `MAX77620_I2C_ADDR_RTC 0x68` path. In-
tree MAX77663 DTS users appear from `v6.6` for Nexus 7 and from
`v6.9`/`v6.12` era for LG P880/P895.

Record 6.2: exact patch applies cleanly to `v7.0`. It conflicts on
`v5.4`, `v6.6`, and `v6.12` because older trees still store the dummy
client in `info->rtc` and lack later `dev_err_probe()`/local-client
cleanups. Expected backport difficulty is minor mechanical rework.

Record 6.3: no related stable commit with the same subject was found in
`stable/linux-7.0.y`.

### Phase 7: Subsystem Context
Record 7.1: subsystem is `drivers/rtc` for a Maxim PMIC RTC, with MFD/DT
interaction. Criticality is peripheral/driver-specific, not core kernel.

Record 7.2: subsystem has moderate activity; recent file history is
mostly cleanups plus MAX77714 support and prior MAX77620 fixes.

### Phase 8: Impact and Risk
Record 8.1: affected users are systems with MAX77663/MAX77620-family
PMICs, especially DT-based Tegra devices or downstream boards whose
MAX77663 RTC is at non-default `0x48`.

Record 8.2: trigger is device probe/boot when the RTC secondary I2C
address differs from the hardcoded default and DT supplies the correct
address. Unprivileged users do not trigger it.

Record 8.3: failure mode is RTC device not registering or not
functioning correctly on affected hardware. Severity is MEDIUM: hardware
functionality loss, not crash/security/data corruption.

Record 8.4: benefit is medium for affected hardware and downstream
stable users; risk is low because fallback preserves existing behavior
and the change is tightly scoped.

### Phase 9: Final Synthesis
Record 9.1: evidence for backporting: real hardware issue, existing
stable code contains the hardcoded path, existing I2C helper supports
exactly this use case, patch is tiny, tested on affected hardware, and
applied by RTC maintainer. Evidence against: not a crash/security/data-
corruption fix, no in-tree DTS currently uses the new two-address form,
older stable trees need a small manual backport.

Record 9.2: stable checklist: obviously correct: yes; fixes real bug:
yes, wrong undetectable hardware address; important issue: moderate
hardware functionality loss; small/contained: yes, 14-line one-file
change; no new kernel API: yes; stable application: clean for `v7.0`,
minor rework for older trees.

Record 9.3: exception category: hardware workaround for existing
supported PMIC variant, close to a DT/hardware quirk.

Record 9.4: decision: backport is justified, especially for `v7.0.y` and
with minor adjusted backports for older stable branches that carry
MAX77663 support.

## Verification
- Phase 1: `git show 0d65a9d93d870` verified subject, body, tags,
  author, committer, and diffstat.
- Phase 2: diff verified `12 insertions`, `2 deletions`, added release
  helper, and replacement of `devm_i2c_new_dummy_device()` with
  `i2c_new_ancillary_device()`.
- Phase 3: `git blame`, `git show 4c58f7012f15`, `git tag --contains`,
  and file history verified MAX77663 support and hardcoded RTC address
  path.
- Phase 4: `b4 dig -c`, `-a`, `-w`, and mbox read verified lore URL,
  v1-v4 series, recipients, cover-letter test statement, Rob Herring
  review on binding patch, and Alexandre Belloni application of RTC
  patch.
- Phase 5: `rg` and file reads verified caller chain through
  `max77686_rtc_probe()` and `max77620` MFD child creation.
- Phase 6: `git grep` across `v5.4` through `v7.0` verified API/code
  presence; temporary worktree `git apply --check` verified clean apply
  on `v7.0` and conflicts on older tested tags.
- Phase 7: `git log` verified recent RTC/MFD activity.
- Phase 8: impact and severity derive from verified commit text, cover-
  letter test statement, and probed call path.
- UNVERIFIED: I could not fetch lore search pages via WebFetch because
  lore returned Anubis challenge pages; stable-specific web discussion
  beyond local git history was not verified.

**YES**

 drivers/rtc/rtc-max77686.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 69ea3ce75b5a5..3cdfd78a07ccc 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -686,6 +686,11 @@ static int max77686_rtc_init_reg(struct max77686_rtc_info *info)
 	return ret;
 }
 
+static void max77686_rtc_release_dev(void *client)
+{
+	i2c_unregister_device(client);
+}
+
 static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
 {
 	struct device *parent = info->dev->parent;
@@ -713,12 +718,17 @@ static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
 		goto add_rtc_irq;
 	}
 
-	client = devm_i2c_new_dummy_device(info->dev, parent_i2c->adapter,
-					   info->drv_data->rtc_i2c_addr);
+	client = i2c_new_ancillary_device(parent_i2c, "rtc",
+					  info->drv_data->rtc_i2c_addr);
 	if (IS_ERR(client))
 		return dev_err_probe(info->dev, PTR_ERR(client),
 				     "Failed to allocate I2C device for RTC\n");
 
+	ret = devm_add_action_or_reset(info->dev, max77686_rtc_release_dev,
+				       client);
+	if (ret)
+		return ret;
+
 	info->rtc_regmap = devm_regmap_init_i2c(client,
 						info->drv_data->regmap_config);
 	if (IS_ERR(info->rtc_regmap))
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] rtc: ti-k3: Add support to resume from IO DDR low power mode

[Sasha Levin]

From: Akashdeep Kaur <a-kaur@ti.com>

[ Upstream commit 0e9b12ee74c57617bb362deb3c82e35fe49694b5 ]

Restore the RTC HW context which may be lost when system enters
certain low power mode (IO+DDR mode).
Check if the RTC registers are locked which would indicate loss of
context (reset) and restore the context as needed.

Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://patch.msgid.link/20260313111740.1492519-1-a-kaur@ti.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:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `rtc: ti-k3`; action verb `Add support`;
claimed intent is to restore TI K3 RTC hardware context after IO+DDR low
power resume.

Step 1.2 Record: Tags found in `git show 0e9b12ee74c5`: `Signed-off-by:
Akashdeep Kaur <a-kaur@ti.com>`, `Reviewed-by: Vignesh Raghavendra
<vigneshr@ti.com>`, `Link:
https://patch.msgid.link/20260313111740.1492519-1-a-kaur@ti.com`,
`Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>`. No
`Fixes:`, no `Reported-by:`, no `Cc: stable`.

Step 1.3 Record: The bug described is loss of RTC register context when
the system enters IO+DDR low power mode. The visible failure mode is not
described as a crash; it is a hardware state loss after resume. Version
info is not stated. Root cause stated by author: RTC registers being
locked indicates context reset/loss.

Step 1.4 Record: This is a hidden bug fix despite “Add support”: it
restores hardware context after a low-power resume reset. It matches the
hardware workaround/resume quirk category, not a general new API.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed, `drivers/rtc/rtc-ti-k3.c`, with `9`
insertions and `1` deletion. Modified function: `ti_k3_rtc_resume()`.
Scope: single-file surgical driver PM fix.

Step 2.2 Record: Before, resume only disabled IRQ wake if wakeup was
enabled, then returned `0`. After, resume first checks
`k3rtc_check_unlocked(priv)`; if the RTC appears locked/reset, it calls
`k3rtc_configure(dev)` and returns any error; then it disables IRQ wake
as before. Affected path: system resume path for this platform RTC
driver.

Step 2.3 Record: Bug category is hardware context loss / PM resume
quirk. Mechanism: locked RTC registers after IO+DDR resume indicate RTC
hardware context was reset; reusing `k3rtc_configure()` restores unlock,
sync, mode, and IRQ register configuration.

Step 2.4 Record: Fix quality is mostly good: small, local, reuses the
probe-time configuration routine. Regression risk is low but not zero:
if `k3rtc_configure()` fails on a wakeup-capable device, the function
returns before `disable_irq_wake(priv->irq)`, which could leave wake IRQ
state unbalanced on that error path. I found no review objection to this
in the lore thread.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows `k3rtc_check_unlocked()`,
`k3rtc_configure()`, and the original resume hook came from
`b09d633575e54` (`rtc: Introduce ti-k3-rtc`), first contained by
`v6.0-rc1`. The wake IRQ error-return context came from `d31d7300ebc0c`
in mainline and `bb0433ae6fa2a` in `p-6.1`.

Step 3.2 Record: No `Fixes:` tag is present, so there was no fixes
target to inspect.

Step 3.3 Record: Recent local file history is limited: `rtc: Explicitly
include correct DT includes`, `rtc: k3: handle errors while enabling
wake irq`, `rtc: k3: Use devm_clk_get_enabled() helper`, erratum
handling changes, and original driver introduction. No prerequisite
series for this patch was found in `drivers/rtc/rtc-ti-k3.c`.

Step 3.4 Record: Local history shows Akashdeep Kaur has TI ARM64 DTS
commits, but no prior local RTC commits in the checked paths. Vignesh
Raghavendra has multiple TI platform commits and reviewed this patch.
Alexandre Belloni is the RTC maintainer/committer for the applied
commit.

Step 3.5 Record: Dependencies are existing symbols already present in
representative stable refs: `k3rtc_check_unlocked()`,
`k3rtc_configure()`, `ti_k3_rtc_resume()`, and `SIMPLE_DEV_PM_OPS`. The
patch appears standalone for `p-6.1`, `p-6.6`, `p-6.12`, and `p-6.19`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 0e9b12ee74c5` found the lore thread by
patch-id. `b4 am -c` confirmed v2 is the latest revision and applies
cleanly to the current tree. Lore web fetch directly was blocked by
Anubis, but `b4` retrieved the mbox.

Step 4.2 Record: `b4 dig -w` showed recipients included TI platform
people, `alexandre.belloni@bootlin.com`, `linux-rtc@vger.kernel.org`,
and `linux-kernel@vger.kernel.org`. `b4 am -c` found `Reviewed-by:
Vignesh Raghavendra`.

Step 4.3 Record: No `Reported-by` or bugzilla/syzbot link exists. Patch
notes say: “Tested deep sleep with rtcwake after IO DDR resume on
AM62P-SK.”

Step 4.4 Record: v1 review by Vignesh asked for commit message
simplification, not code changes. v2 updated the message and was applied
by Alexandre Belloni. No NAKs or technical concerns found in retrieved
thread.

Step 4.5 Record: Web search for stable-list discussion found no usable
stable-specific result; lore stable pages were blocked by Anubis. No
local stable refs contain this patch by subject.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `ti_k3_rtc_resume()`.

Step 5.2 Record: Caller path is via `SIMPLE_DEV_PM_OPS(ti_k3_rtc_pm_ops,
ti_k3_rtc_suspend, ti_k3_rtc_resume)`, assigned to the platform driver’s
`.pm`; `include/linux/pm.h` confirms this sets system sleep PM callbacks
in `struct dev_pm_ops`.

Step 5.3 Record: New callees are `k3rtc_check_unlocked()` and
`k3rtc_configure()`. `k3rtc_check_unlocked()` reads the `K3RTC_UNLOCK`
regmap field. `k3rtc_configure()` handles unlock/erratum checks, enables
32 kHz sync, sets counter freeze mode, clears spurious IRQs, disables
IRQs, and fences writes.

Step 5.4 Record: Reachable during system resume when the TI K3 RTC
platform device is bound and `CONFIG_PM_SLEEP` is enabled. TI
documentation and patch notes both verify `rtcwake`/deep sleep as a real
test path. Unprivileged trigger was not verified; TI docs show root
shell usage.

Step 5.5 Record: Similar local pattern is probe-time
`k3rtc_configure(dev)`. This patch reuses that existing initialization
path on resume when hardware context is lost.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: `v5.15` lacks `drivers/rtc/rtc-ti-k3.c`; `v6.0`,
`v6.1`, `v6.6`, `v6.12`, and `v6.19` have it. Representative `p-6.1`,
`p-6.6`, `p-6.12`, and `p-6.19` refs contain the buggy pre-change resume
path and the helper functions.

Step 6.2 Record: Expected backport difficulty is clean or very minor.
The exact resume context exists in `p-6.1`, `p-6.6`, `p-6.12`, and
`p-6.19`. Raw `v6.0`/`v6.1` release tags differ in the suspend wake-IRQ
line, so older non-updated baselines may need context adjustment or the
earlier wake-IRQ fix.

Step 6.3 Record: No related stable fix for “IO DDR” / “resume from IO
DDR” was found in local `p-*` refs.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is RTC driver under `drivers/rtc`, for TI K3
SoCs. Criticality: peripheral/driver-specific, but important for
affected embedded platforms and low-power resume reliability.

Step 7.2 Record: File activity is low: only a handful of changes since
the driver was introduced. This is not a high-churn refactor area.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are TI K3/AM62-family systems using
`RTC_DRV_TI_K3`, compatible `ti,am62-rtc`, and IO+DDR/deep sleep paths.
`p-6.1` has AM62A DTS files; `p-6.6+` also has AM62P DTS files.

Step 8.2 Record: Trigger is resume from IO+DDR low power mode where RTC
context is reset. Patch testing specifically used deep sleep with
`rtcwake` after IO DDR resume on AM62P-SK. Trigger is platform/power-
mode-specific, not universal.

Step 8.3 Record: Failure severity is medium to high for affected
hardware: not a kernel crash or data corruption based on available
evidence, but a real resume functionality failure due to lost RTC
hardware configuration.

Step 8.4 Record: Benefit is high for affected TI K3 systems using low
power mode because it restores RTC operation after context loss. Risk is
low because the patch is 10 lines, local to one resume callback, and
reuses existing configuration code; main concern is the early-return-
before-`disable_irq_wake()` error path.

## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real hardware context loss,
tested on AM62P-SK with `rtcwake`, reviewed by TI maintainer/reviewer,
applied by RTC maintainer, tiny single-driver patch, existing code in
stable refs, no new ABI/API. Evidence against: commit is framed as “Add
support”, no explicit stable nomination, device-specific impact, no
documented crash/corruption, and minor wake-IRQ cleanup concern on
configuration failure.

Step 9.2 Record: Stable rules checklist: obviously correct and tested:
yes, with `rtcwake` test and review. Fixes real bug: yes, RTC context
loss after IO+DDR resume. Important issue: yes for affected hardware
suspend/resume, though not crash-class. Small and contained: yes, one
function, `9+/1-`. No new features/APIs: yes, no ABI/API change; it is a
hardware PM workaround. Can apply to stable: yes for representative
`p-*` refs, with possible context adjustment for raw older tags.

Step 9.3 Record: Exception category applies: hardware-specific low-power
resume workaround/quirk for an existing driver.

Step 9.4 Record: Decision: backport. The benefit for affected embedded
stable users outweighs the low regression risk, and the change is small,
reviewed, tested, and contained.

## Verification
- Phase 1: `git show --format=fuller --stat --patch 0e9b12ee74c5`
  verified subject, author/committer, tags, and exact diff.
- Phase 2: `git diff --stat` and `git diff --numstat` verified
  `drivers/rtc/rtc-ti-k3.c` changed by `9` insertions and `1` deletion.
- Phase 3: `git blame` verified original helper/resume code from
  `b09d633575e54`; `git describe --contains` verified first containment
  around `v6.0-rc1`; recent file logs verified no hidden prerequisite in
  the RTC file.
- Phase 4: `b4 dig -c 0e9b12ee74c5`, `b4 dig -a`, `b4 dig -w`, `b4 am
  -c`, and `b4 mbox` verified lore thread, v1/v2 review history,
  reviewers, recipients, and test note.
- Phase 5: `rg` and `ReadFile` verified `SIMPLE_DEV_PM_OPS`, `.pm =
  &ti_k3_rtc_pm_ops`, helper bodies, and the probe-time
  `k3rtc_configure()` call.
- Phase 6: `git show <ref>:drivers/rtc/rtc-ti-k3.c` verified
  file/helper/resume presence in `p-6.1`, `p-6.6`, `p-6.12`, and
  `p-6.19`; `v5.15` lacks the driver.
- Phase 7: `drivers/rtc/Kconfig` verified `RTC_DRV_TI_K3` depends on
  `ARCH_K3 || COMPILE_TEST`.
- Phase 8: TI documentation and patch mbox verified `rtcwake`/deep sleep
  relevance; U-Boot IO+DDR public thread verified IO+DDR is a real
  AM62A/AM62P low-power mode.
- Unverified: exact pre-patch user-visible symptom beyond hardware
  context loss and the patch’s `rtcwake` test note; no stable-list
  rationale found due lore Anubis blocking direct stable searches.

**YES**

 drivers/rtc/rtc-ti-k3.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ti-k3.c b/drivers/rtc/rtc-ti-k3.c
index ec759d8f7023c..e801f5b9d7574 100644
--- a/drivers/rtc/rtc-ti-k3.c
+++ b/drivers/rtc/rtc-ti-k3.c
@@ -640,10 +640,18 @@ static int __maybe_unused ti_k3_rtc_suspend(struct device *dev)
 static int __maybe_unused ti_k3_rtc_resume(struct device *dev)
 {
 	struct ti_k3_rtc *priv = dev_get_drvdata(dev);
+	int ret = 0;
+
+	if (k3rtc_check_unlocked(priv)) {
+		/* RTC locked implies low power mode exit where RTC loses context */
+		ret = k3rtc_configure(dev);
+		if (ret)
+			return ret;
+	}
 
 	if (device_may_wakeup(dev))
 		disable_irq_wake(priv->irq);
-	return 0;
+	return ret;
 }
 
 static SIMPLE_DEV_PM_OPS(ti_k3_rtc_pm_ops, ti_k3_rtc_suspend, ti_k3_rtc_resume);
-- 
2.53.0