[PATCH AUTOSEL 6.18-5.10] rtc: aspeed: add AST2700 compatible

[PATCH AUTOSEL 6.18-5.10] rtc: aspeed: add AST2700 compatible

[Sasha Levin]

From: Tommy Huang <tommy_huang@aspeedtech.com>

[ Upstream commit 3319cfeeb8c4047026f84df045c438f7bbd338a6 ]

Add support for matching the RTC controller on ASPEED AST2700 SoCs.

The AST2700 RTC controller is compatible with the existing ASPEED
RTC driver implementation.

Signed-off-by: Tommy Huang <tommy_huang@aspeedtech.com>
Link: https://patch.msgid.link/20260601-ast2700-rtc-v1-2-15d4ca46500a@aspeedtech.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:

The background searches finished and match what the earlier analysis
used.

The `b4 dig` lookup on the real commit (`3319cfeeb8c40`) found the lore
thread and confirmed this is patch 2/2 of the AST2700 RTC series, with
`5e7f746bc106a` as the companion DT-binding patch.

The stable-branch history search shows 6.18.y already has substantial
AST2700/G7 bring-up (gpio, mfd, irqchip, reset, mailbox, clock
bindings), but not the RTC compatible or `ast2700-rtc` binding yet.

Verdict unchanged: **YES** for backport to this 6.18.y tree, ideally
together with the binding patch.

 drivers/rtc/rtc-aspeed.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/rtc/rtc-aspeed.c b/drivers/rtc/rtc-aspeed.c
index 0d0053b52f9b9..8f5b440f8c0a9 100644
--- a/drivers/rtc/rtc-aspeed.c
+++ b/drivers/rtc/rtc-aspeed.c
@@ -111,6 +111,7 @@ static const struct of_device_id aspeed_rtc_match[] = {
 	{ .compatible = "aspeed,ast2400-rtc", },
 	{ .compatible = "aspeed,ast2500-rtc", },
 	{ .compatible = "aspeed,ast2600-rtc", },
+	{ .compatible = "aspeed,ast2700-rtc", },
 	{}
 };
 MODULE_DEVICE_TABLE(of, aspeed_rtc_match);
-- 
2.53.0

[PATCH AUTOSEL 6.18] rtc: renesas-rtca3: Check RADJ poll result during initial setup

[Sasha Levin]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

[ Upstream commit fafb016d081200c7652e84202f8ba5951e659a53 ]

In rtca3_initial_setup(), the driver clears the RTCA3_RADJ register and
waits for it to reach zero using readb_poll_timeout(). Check the return
value of readb_poll_timeout() and propagate the error if the poll fails.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S
Link: https://patch.msgid.link/20260602192559.1791344-3-prabhakar.mahadev-lad.rj@bp.renesas.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: Parse the Subject Line
**Record:** `[rtc: renesas-rtca3]` `[Check]` — Check the return value of
the RADJ register poll during RTC initial setup in
`rtca3_initial_setup()`.

### Step 1.2: Parse All Commit Message Tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** Claudiu Beznea `<claudiu.beznea.uj@bp.renesas.com>` #
  on RZ/G3S
- **Reviewed-by:** Claudiu Beznea `<claudiu.beznea.uj@bp.renesas.com>`
- **Link:**
  https://patch.msgid.link/20260602192559.1791344-3-prabhakar.mahadev-
  lad.rj@bp.renesas.com
- **Signed-off-by:** Lad Prabhakar, Alexandre Belloni (ignore pipeline-
  added SOBs)
- **Cc: stable:** — not present on this individual patch (patch 1/5 in
  the same series did CC stable)
- **Notable:** Part of v2 `[PATCH 2/5]` series; hardware-tested on
  RZ/G3S; no syzbot/fuzzer reports

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug:** After clearing `RTCA3_RADJ` and polling for it to reach zero,
  the driver ignores the `readb_poll_timeout()` return value.
- **Symptom:** If the poll times out (`-ETIMEDOUT`), setup continues and
  may start the RTC with automatic time error adjustment
  (`RTCA3_RCR2_AADJE`) even though RADJ did not clear.
- **Root cause:** Oversight — every other poll in
  `rtca3_initial_setup()` checks `ret`; this one does not.
- **Version info:** None in message; driver landed in this tree via
  `d4488377609e3` (Nov 2024).

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Yes — despite neutral wording (“check the return value”),
this is a real initialization error-handling bug, not cosmetic cleanup.
The same RADJ-clear poll in `rtca3_set_offset()` already checks `ret`.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory the Changes
**Record:**
- **Files:** `drivers/rtc/rtc-renesas-rtca3.c` (+2 lines)
- **Function:** `rtca3_initial_setup()`
- **Scope:** Single-file, surgical fix (2 lines)

### Step 2.2: Code Flow Change
**Record:**
- **Hunk (lines 635–637):** Before: RADJ poll result stored in `ret` but
  ignored; execution proceeds to enable `RTCA3_RCR2_START |
  RTCA3_RCR2_AADJE`. After: on poll failure, return error immediately.
  Affects cold-init path in probe, not hot path.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Error-path / logic correctness fix
- **Mechanism:** Missing timeout handling after hardware register poll.
  If RADJ does not clear within `RTCA3_DEFAULT_TIMEOUT_US` (150 µs), the
  driver continues hardware programming; the subsequent RCR2 poll
  overwrites `ret`, masking the failure and allowing probe to succeed
  with bad RTC adjustment state.

### Step 2.4: Fix Quality
**Record:** Obviously correct — mirrors the pattern used for all other
polls in the same function and for the identical RADJ poll in
`rtca3_set_offset()`. Minimal, no API changes. **Regression risk:** Very
low; on success path `ret == 0` and behavior is unchanged.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame the Changed Lines
**Record:** Buggy code introduced in `d4488377609e3` (“rtc: renesas-
rtca3: Add driver for RTCA-3…”, Oct 30 2024). Present since driver
introduction. Blame confirms lines 634–636 unchanged since
`d4488377609e3`.

### Step 3.2: Follow Fixes Tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: File History / Related Changes
**Record:** Recent `rtc-renesas-rtca3.c` history in this tree:
- `6e21d1253ef13` — PIE clear polling fix (patch 1/5 of same series;
  already in 6.18.y)
- `27b2fcbd6b982` — Disable interrupts only if RTC enabled (probe-
  failure fix)
- `8f315a5c7376b` — RISC-V build fix
- `d4488377609e3` — Driver introduction

Patch 2/5 (this commit) is standalone; patches 3–5 are error-message,
doc typo, and refactor (not prerequisites).

### Step 3.4: Author's Other Commits
**Record:** Lad Prabhakar authored patch 1 (PIE fix, backported here)
and this patch. Claudiu Beznea (co-author/reviewer) introduced the
driver. Both are active Renesas RTC contributors.

### Step 3.5: Dependencies
**Record:** No dependencies. Applies cleanly to current
`drivers/rtc/rtc-renesas-rtca3.c` in this tree. Upstream commit:
`fafb016d08120` on `master`; **not yet in HEAD** (`v6.18.44`).

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:**
- `b4 dig -c 6e21d1253ef13 -a` found series v2 at
  https://patch.msgid.link/20260602192559.1791344-2-prabhakar.mahadev-
  lad.rj@bp.renesas.com
- This commit is `[PATCH v2 2/5]` (message-id `…1791344-3…`)
- Cover letter lists RADJ poll checking as an explicit series goal
- No NAKs found in saved mbox; Claudiu provided RB/TB
- **Stable nomination:** Only patch 1/5 CC'd `stable@vger.kernel.org` in
  the submission; patch 2/5 did not (per instructions, this is not a
  deciding factor)

### Step 4.2: Reviewers
**Record:** `b4 dig -w` recipients include Alexandre Belloni (RTC
maintainer), Claudiu Beznea, Geert Uytterhoeven, `linux-rtc@`, `linux-
renesas-soc@`.

### Step 4.3: Bug Reports
**Record:** No bug reports, syzbot links, or user crash reports. Issue
identified by code review during the same audit that produced the PIE
polling fix.

### Step 4.4: Related Patches
**Record:** 5-patch series; only patches 1–2 are bug fixes. Patches 3–5
(error message, doc typo, year-decoding refactor) are not stable
candidates.

### Step 4.5: Stable Mailing List
**Record:** Not searched separately; patch 1 from this series was
already cherry-picked into `linux-6.18.y` as `6e21d1253ef13` (Signed-
off-by: Greg Kroah-Hartman), confirming stable maintainers accept rtca3
fixes from this series.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `rtca3_initial_setup()` modified.

### Step 5.2: Callers
**Record:** `rtca3_initial_setup()` called once from `rtca3_probe()` at
line 760. `rtca3_probe()` is the `platform_driver` probe for
`module_platform_driver(rtca3_platform_driver)`. Runs at boot during
device enumeration on Renesas RZ/G3S platforms with
`CONFIG_RTC_DRV_RENESAS_RTCA3`.

### Step 5.3: Callees
**Record:** `readb_poll_timeout()`, `writeb()`, `usleep_range()`,
`clk_get_rate()`. Hardware register I/O during init.

### Step 5.4: Reachability
**Record:** Triggered on every boot when the RTCA-3 platform device
probes. Not userspace-triggerable directly, but affects all systems
using this RTC hardware. Failure during init is a boot-time driver probe
issue.

### Step 5.5: Similar Patterns
**Record:** In the same file, `rtca3_set_offset()` lines 538–542 perform
the identical RADJ-clear poll **with** `if (ret) return ret;`. All other
polls in `rtca3_initial_setup()` also check `ret`. This is the sole
missing check in that function.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Does Buggy Code Exist?
**Record:** **Yes.** Local tree is `v6.18.44` (`linux-6.18.y`).
`drivers/rtc/rtc-renesas-rtca3.c` exists; lines 634–636 show the missing
check. Driver present since `d4488377609e3`.

### Step 6.2: Backport Complications
**Record:** Clean apply expected — upstream diff matches current file
context exactly. No conflicts anticipated.

### Step 6.3: Related Fixes Already Present?
**Record:** Patch 1/5 (PIE polling fix) already backported as
`6e21d1253ef13`. This patch 2/5 is **not** yet in HEAD. No alternate fix
for the RADJ poll issue.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** `drivers/rtc/` — IMPORTANT (peripheral driver).
`CONFIG_RTC_DRV_RENESAS_RTCA3` depends on `ARCH_RENESAS`; targets
Renesas RZ/G3S SoC only.

### Step 7.2: Subsystem Activity
**Record:** Driver is new (added late 2024) and actively maintained;
multiple follow-up fixes in mainline and at least one already in this
stable tree.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Config-specific, platform-specific — users building
`CONFIG_RTC_DRV_RENESAS_RTCA3` on Renesas RZ/G3S hardware. Not
universal, but real production embedded users.

### Step 8.2: Trigger Conditions
**Record:** RADJ register fails to clear to zero within 150 µs after
`writeb(0, RTCA3_RADJ)`. Unlikely on healthy hardware; possible on
marginal/broken hardware or timing edge cases. Not unprivileged-
userspace-triggerable; boot-time init only.

### Step 8.3: Failure Mode Severity
**Record:** Without fix: probe succeeds despite failed RADJ init; RTC
may start with `RTCA3_RCR2_AADJE` enabled while adjustment register is
not in expected state → incorrect timekeeping/alarms. **Severity:
MEDIUM** — functional RTC corruption, not kernel oops/UAF/security
issue. With fix: probe fails cleanly with `"Failed to setup the RTC!"`.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Prevents silently registering a mis-initialized RTC;
  consistent error handling; complements already-backported patch 1/5
- **Risk:** Very low — 2 lines, no behavior change when poll succeeds
- **Ratio:** Moderate benefit for a narrow audience, very low risk

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real bug — only missing poll error check in `rtca3_initial_setup()`
- Inconsistent with identical pattern elsewhere in same driver
- Can leave RTC in wrong adjustment state while probe succeeds
- Trivial, obviously correct, hardware-tested on RZ/G3S
- Driver exists in this `6.18.y` tree; patch applies cleanly
- Sister fix (patch 1/5) already backported to this tree
- Reviewed/tested by driver co-maintainer

**AGAINST backport:**
- No user bug reports or reproducible failure described
- Only triggers on 150 µs poll timeout — rare on working hardware
- Not crash/security/deadlock/kernel memory corruption
- Narrow hardware scope (RZ/G3S only)
- Author CC'd stable only on patch 1, not this patch
- Patches 3–5 in series are clearly non-stable material

**Unresolved:** Whether RADJ poll timeout has been observed on real
hardware (no evidence found).

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — 2-line mirror of existing
   pattern; Tested-by on RZ/G3S
2. Fixes a real bug? **PASS** — missing error propagation on hardware
   poll timeout
3. Important issue? **BORDERLINE PASS** — incorrect RTC init/timekeeping
   on affected embedded hardware; not a kernel crash, but functional
   hardware misconfiguration
4. Small and contained? **PASS** — 2 lines, one function
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — driver and buggy code present;
   clean apply

### Step 9.3: Exception Categories
**Record:** None (not device ID, quirk, DT, build fix, or docs fix).

### Step 9.4: Decision Rationale

This is a legitimate initialization bug in a driver that is already
maintained in `linux-6.18.y`, with a sister fix from the same series
already cherry-picked. The omission allows probe to succeed after a
failed hardware register poll, immediately before enabling automatic
time error adjustment — a documented init sequence step. While the
trigger is uncommon and the audience is narrow (Renesas RZ/G3S), the fix
is zero-risk on the success path, obviously correct, hardware-tested,
and prevents silently exposing a mis-initialized RTC to userspace. That
meets the stable bar for a contained driver probe correctness fix in
hardware that this tree already supports.

---

## Verification

- **[Phase 1]** Parsed commit message tags from user-provided content
- **[Phase 2]** Read current `drivers/rtc/rtc-renesas-rtca3.c` lines
  567–660, 538–542; confirmed 2-line diff
- **[Phase 3]** `git describe HEAD` → `v6.18.44`; `make kernelversion`
  equivalent → 6.18.44
- **[Phase 3]** `git blame -L 630,650` → bug from `d4488377609e3`
- **[Phase 3]** `git log --oneline -- drivers/rtc/rtc-renesas-rtca3.c` →
  5 commits, patch 1 backported, RADJ fix absent
- **[Phase 3]** `git show fafb016d08120` on master → upstream commit
  matches provided diff
- **[Phase 3]** `git merge-base --is-ancestor fafb016d08120 HEAD` → RADJ
  fix NOT in HEAD
- **[Phase 4]** `b4 dig -c 6e21d1253ef13 -a` → found v2 5-patch series
- **[Phase 4]** `b4 dig -m /tmp/rtca3-series.mbx` → read cover letter
  and patch 2/5 content
- **[Phase 4]** Confirmed patch 1 CC'd stable; patch 2 did not
- **[Phase 4]** WebFetch of lore/patch.msgid.link blocked by bot
  protection for direct fetch; used b4 mbox instead
- **[Phase 5]** `grep rtca3_initial_setup` → called from `rtca3_probe()`
  line 760
- **[Phase 5]** Counted `if (ret)` checks vs `readb_poll_timeout` calls
  — RADJ poll is sole missing check in `rtca3_initial_setup()`
- **[Phase 6]** Confirmed `CONFIG_RTC_DRV_RENESAS_RTCA3` in Kconfig,
  `depends on ARCH_RENESAS`
- **[Phase 6]** Confirmed buggy code at lines 634–636 without `if (ret)
  return ret;`
- **[Phase 8]** `RTCA3_DEFAULT_TIMEOUT_US` = 150 µs verified at line 87

**YES**The background git searches finished and match the earlier
analysis:

- **RADJ poll fix** (`fafb016d08120` / “Check RADJ poll result during
  initial setup”) is **not** in this `linux-6.18.y` checkout; it’s only
  on `master`.
- **All `rtc-renesas-rtca3` commits in this tree:** driver introduction
  (`d4488377609e3`), RISC-V build fix, wakeup boolean cleanup,
  interrupt-disable probe fix (`27b2fcbd6b982`), and the already-
  backported PIE polling fix (`6e21d1253ef13`).
- **From the v2 5-patch series:** only patch 1 (PIE fix) is present;
  patch 2 (this RADJ check) and patches 3–5 are not.

That supports the **YES** backport recommendation for `linux-6.18.y`:
the bug is present, the fix is absent, and the related patch from the
same series is already here.

 drivers/rtc/rtc-renesas-rtca3.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/rtc/rtc-renesas-rtca3.c b/drivers/rtc/rtc-renesas-rtca3.c
index 47b4827979344..c41f2089cbb2b 100644
--- a/drivers/rtc/rtc-renesas-rtca3.c
+++ b/drivers/rtc/rtc-renesas-rtca3.c
@@ -634,6 +634,8 @@ static int rtca3_initial_setup(struct clk *clk, struct rtca3_priv *priv)
 	writeb(0, priv->base + RTCA3_RADJ);
 	ret = readb_poll_timeout(priv->base + RTCA3_RADJ, tmp, !tmp, 10,
 				 RTCA3_DEFAULT_TIMEOUT_US);
+	if (ret)
+		return ret;
 
 	/* Start the RTC and enable automatic time error adjustment. */
 	mask = RTCA3_RCR2_START | RTCA3_RCR2_AADJE;
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] rtc: bq32000: add delay between RTC reads

[Sasha Levin]

From: Adriana Stancu <adriana@arista.com>

[ Upstream commit d4992b7050a10079bc760bdc5b8688e05a09dfc2 ]

When the RTC is used on systems without a interrupt line, userspace
tools like `hwclock` fall back to a frequent polling loop to synchronize
with the edge of the next second.

On the BQ32000, this aggressive polling can temporarly lock the register
refresh cycle, because the continuous transfers prevent the hardware from
updating the buffer. This results in stale data reads or select() timeouts
in userspace.

This patch introduces a delay before reading the RTC registers in order to
provide a sufficient idle time for the hardware to sync with the register
buffer.

Signed-off-by: Adriana Stancu <adriana@arista.com>
Link: https://patch.msgid.link/20260416142151.3385827-1-adriana@arista.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: Parse the Subject Line
**Record:** `[rtc: bq32000]` `[add]` — add a delay between RTC register
reads in the BQ32000 driver.

### Step 1.2: Parse All Commit Message Tags
**Record:**
- **Link:**
  `https://patch.msgid.link/20260416142151.3385827-1-adriana@arista.com`
- **Signed-off-by:** Adriana Stancu `<adriana@arista.com>` (author)
- **Signed-off-by:** Alexandre Belloni `<alexandre.belloni@bootlin.com>`
  (RTC maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable@vger.kernel.org`
- Notable: maintainer sign-off; no syzbot or external bug-report tags

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug:** On BQ32000 systems without an interrupt line, userspace tools
  (`hwclock`) poll aggressively waiting for the second rollover.
  Continuous I2C reads block the chip’s internal register-buffer
  refresh, yielding stale time data.
- **Symptom:** Stale RTC reads; `select()` timeouts in userspace during
  `hwclock` synchronization.
- **Root cause:** Hardware needs idle time between reads for the
  register buffer to sync; aggressive polling prevents that.
- **Version info:** None stated.

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Not disguised as cleanup — explicitly a hardware timing
workaround. Functionally fixes incorrect RTC reads on affected hardware
(hardware quirk category).

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory the Changes
**Record:**
- **Files:** `drivers/rtc/rtc-bq32k.c` only (+9 lines net, including
  `#include <linux/delay.h>`)
- **Functions modified:** `bq32k_rtc_read_time()`
- **Scope:** Single-file surgical fix

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (include):** Adds `<linux/delay.h>` for `usleep_range()`.
- **Hunk 2 (`bq32k_rtc_read_time`):**
  - **Before:** Read registers immediately via `bq32k_read()`.
  - **After:** If `client->irq <= 0`, sleep 2000–2500 µs, then read
    registers.
  - **Path affected:** Every `.read_time` call on devices without a
    connected IRQ.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Hardware quirk / timing workaround
- **Mechanism:** BQ32000 needs idle time between I2C accesses for its
  internal buffer to refresh. Polling (common when no IRQ is available)
  starves that refresh. A fixed settle delay gives the hardware time to
  update before each read.

### Step 2.4: Fix Quality Assessment
**Record:**
- Small, obviously motivated fix aligned with similar RTC driver
  patterns (`rtc-isl1208`, `rtc-rv3028`, `rtc-max8998`).
- **Regression risk:** Low. Adds ~2 ms latency only when `client->irq <=
  0`. `usleep_range()` is safe on the process-context paths that reach
  `.read_time`.
- **Concern:** Delay applies to every read without IRQ, not only
  aggressive polling — acceptable trade-off for correctness.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame Changed Lines
**Record:** `bq32k_rtc_read_time()` core logic dates to `1ce7c83fa91d2`
(2009, “rtc: add driver for BQ32000 I2C RTC”). The immediate-read path
without delay has been present since driver introduction.

### Step 3.2: Follow Fixes Tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: File History for Related Changes
**Record:** Recent `rtc-bq32k.c` history is maintenance (i2c probe
conversion, SPDX, HTTPS links). No prior fix for this polling issue.
Patch evolved v1→v2 (DT property `ti,read-settle-us`) → v3 (hardcoded
delay when `irq <= 0`); committed form matches v3.

### Step 3.4: Author's Other Commits
**Record:** No prior commits from Adriana Stancu in this tree. Arista-
reported hardware issue.

### Step 3.5: Prerequisites
**Record:** Standalone. No series dependency. Uses existing
`client->irq` from I2C core; no new APIs or structures.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:**
- **URL:** https://yhbt.net/lore/linux-
  rtc/20260416142151.3385827-1-adriana@arista.com/T/
- **Series:** v1 (DT property) → v2 → v3 (final, hardcoded delay); v3 is
  the applied version
- **Review:** 0 replies in thread; Alexandre Belloni sign-off in commit
- **Stable nomination:** None found in thread

### Step 4.2: Reviewers
**Record:** CC’d: `alexandre.belloni`, `linux-rtc`, `devicetree`,
`linux-kernel`, `robh`, `krzk+dt`, `conor+dt`. RTC maintainer included.

### Step 4.3: Bug Report
**Record:** No external bug tracker or syzbot link. Issue described in
patch and commit message (Arista hardware, `hwclock` polling failure).

### Step 4.4: Related Patches
**Record:** v1/v2 added DT binding for `ti,read-settle-us`; v3 dropped
that in favor of `if (client->irq <= 0) usleep_range(2000, 2500)`. No
other patches required.

### Step 4.5: Stable Mailing List
**Record:** Not searched exhaustively; no stable nomination found in
available thread data.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `bq32k_rtc_read_time()` (modified)

### Step 5.2: Callers
**Record:** Via `rtc_class_ops.read_time` → `__rtc_read_time()` in
`drivers/rtc/interface.c` → callers include:
- `RTC_RD_TIME` ioctl in `drivers/rtc/dev.c` (userspace `hwclock`, etc.)
- `rtc_uie_task` workqueue (update-interrupt emulation polling)
- sysfs `date`/`time` attributes in `drivers/rtc/sysfs.c`
- Other in-kernel RTC consumers

### Step 5.3: Callees
**Record:** `to_i2c_client()`, `usleep_range()`, `bq32k_read()` (I2C
transfer)

### Step 5.4: Call Chain / Reachability
**Record:** Userspace → `/dev/rtc*` ioctl or sysfs → `rtc_read_time()` →
`bq32k_rtc_read_time()`. Reachable from unprivileged userspace with RTC
device access. Polling path (`rtc_uie_task`) is the scenario described
in the commit message.

### Step 5.5: Similar Patterns
**Record:** Multiple RTC drivers use read delays for hardware timing:
- `rtc-isl1208.c`: `msleep(250)` for alarm clearing
- `rtc-rv3028.c` / `rtc-rv3032.c`: `usleep_range()` for busy-wait
- `rtc-max8998.c`: `msleep(2000)` for LP3974 workaround
- `rtc-renesas-rtca3.c`, `rtc-ti-k3.c`, others: similar settle delays

---

## Phase 6: Cross-Referencing Against the Local Tree

### Step 6.1: Does the Buggy Code Exist?
**Record:** **Yes.** Local tree is **6.18.44**
(`v6.18.44-1-g2736c32da98b9`). `drivers/rtc/rtc-bq32k.c` exists;
`bq32k_rtc_read_time()` reads immediately with no delay (lines 90–116).
Driver present since 2009; bug present for the full lifetime of the
driver in this tree. Fix is **not** yet applied.

### Step 6.2: Backport Complications
**Record:** Clean apply expected — add one include, a few lines in one
function. No structural conflicts with recent `rtc-bq32k.c` changes.

### Step 6.3: Related Fixes Already Present?
**Record:** None found for BQ32000 read-settle delay.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** **drivers/rtc** — IMPORTANT. RTC correctness affects system
time, logging, TLS, and boot synchronization.

### Step 7.2: Subsystem Activity
**Record:** Actively maintained; recent stable-worthy fixes (NULL deref,
refcount, alarm races) in this tree.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Systems with TI BQ32000 (`ti,bq32000`) and **no interrupt
line** (`client->irq <= 0`). DT example in binding shows RTC without
`interrupts`. Affects embedded/enterprise platforms using this chip
without IRQ wiring.

### Step 8.2: Trigger Conditions
**Record:** Userspace polling for second rollover (e.g. `hwclock
--systohc` without RTC update IRQ). Common on no-IRQ configurations.
Triggerable from userspace via RTC device node.

### Step 8.3: Failure Mode Severity
**Record:** Stale RTC data and `hwclock` `select()` timeouts —
**MEDIUM** severity. Not a kernel oops/UAF, but can leave system time
wrong or prevent time synchronization at boot. Operational impact on
affected hardware is real.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** MEDIUM-HIGH for affected BQ32000 users — restores
  reliable time reads and `hwclock` behavior
- **Risk:** LOW — ~12 lines, well-understood pattern, delay only when
  `irq <= 0`
- **Ratio:** Favorable; fits the hardware-quirk exception for stable

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real hardware bug on BQ32000 without IRQ
- Hardware quirk / timing workaround (explicit stable exception)
- Small, surgical, maintainer-reviewed fix
- Buggy code present in 6.18.44 since driver introduction (2009)
- Precedent in RTC subsystem (isl1208, rv3028, max8998 delays)
- Userspace-reachable via RTC ioctl/polling paths
- No new APIs, DT bindings, or feature additions in final form

**AGAINST backport:**
- No kernel crash, UAF, or security issue
- Niche hardware (BQ32000 without IRQ)
- No syzbot or multi-user bug reports
- Adds ~2 ms to every read on no-IRQ systems (minor latency)
- `client->irq <= 0` is a heuristic; IRQ in DT but unused by this driver
  would skip the delay

**Unresolved:**
- No independent test reports beyond author/maintainer
- b4 dig unavailable (commit not in local history)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — clear hardware rationale;
   maintainer sign-off; matches established RTC delay patterns
2. Fixes a real bug affecting users? **PASS** — stale RTC reads and
   `hwclock` failures on affected hardware
3. Important issue? **PASS (MEDIUM)** — not a crash, but broken RTC/time
   sync on real hardware; hardware-quirk category
4. Small and contained? **PASS** — single file, ~12 lines
5. No new features or APIs? **PASS** — no DT property, no new
   sysfs/module params
6. Can apply to local tree? **PASS** — driver and buggy code present;
   clean apply expected

### Step 9.3: Exception Categories
**Record:** **Hardware quirk/workaround** — BQ32000 requires idle time
between reads for register-buffer refresh. Same class as USB/PCI quirks
and other RTC settle-delay fixes.

### Step 9.4: Decision Rationale

For **linux 6.18.y** (this checkout): the BQ32000 driver has read the
RTC immediately since 2009. On systems without an interrupt line,
userspace polling can prevent the chip from refreshing its register
buffer, producing stale reads and `hwclock` timeouts. The fix is a
small, well-precedented hardware timing workaround that only affects no-
IRQ configurations. It does not add features or APIs, applies cleanly,
and addresses a real operational bug on affected hardware.

---

## Verification

- **[Phase 1]** Parsed subject, tags, and body from provided commit
  message
- **[Phase 1]** Confirmed no `Fixes:`, `Reported-by:`, or syzbot tags
- **[Phase 2]** Diff analysis: 1 file, `bq32k_rtc_read_time()` only,
  adds `usleep_range(2000, 2500)` when `client->irq <= 0`
- **[Phase 3]** `git blame -L 90,116 drivers/rtc/rtc-bq32k.c`: core read
  path from `1ce7c83fa91d2` (2009)
- **[Phase 3]** `git log --oneline -20 -- drivers/rtc/rtc-bq32k.c`: no
  prior settle-delay fix
- **[Phase 3]** `git log --grep='add delay between RTC reads'`: commit
  not in local tree
- **[Phase 4]** Web search: found v1→v3 series; v3 URL on yhbt.net/lore;
  0 thread replies
- **[Phase 4]** `b4 dig -c HEAD`: failed (commit not in tree); `b4 dig`
  requires `-c COMMITISH`
- **[Phase 4]** lore.kernel.org direct fetch blocked (Anubis bot
  protection)
- **[Phase 5]** Read `drivers/rtc/interface.c`: `__rtc_read_time()`
  calls `rtc->ops->read_time()`
- **[Phase 5]** Read `drivers/rtc/dev.c`: `RTC_RD_TIME` ioctl and
  `rtc_uie_task` call `rtc_read_time()`
- **[Phase 5]** `grep usleep_range/msleep` in `drivers/rtc/*.c`:
  multiple similar delay patterns confirmed
- **[Phase 6]** `git describe HEAD`: `v6.18.44-1-g2736c32da98b9`;
  Makefile confirms 6.18.44
- **[Phase 6]** Read `drivers/rtc/rtc-bq32k.c`: fix not present; no
  `linux/delay.h`, no `usleep_range`
- **[Phase 6]** Read
  `Documentation/devicetree/bindings/rtc/ti,bq32000.yaml`: `interrupts`
  optional; example has no IRQ
- **[Phase 7]** `git log --oneline -20 -- drivers/rtc/`: active
  subsystem with recent bug fixes
- **[Phase 8]** Read `drivers/i2c/i2c-core-base.c` lines 503–532:
  `client->irq` set to 0 when no IRQ from DT/ACPI
- **[Phase 8]** `grep irq` in `rtc-bq32k.c`: driver does not implement
  IRQ handling
- **[Phase 3]** `git show 0dbd610c426ed`: isl1208 delay fix precedent
  (13 lines, maintainer sign-off)

**YES**

 drivers/rtc/rtc-bq32k.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/rtc/rtc-bq32k.c b/drivers/rtc/rtc-bq32k.c
index 7ad34539be4d2..245e5e45d6a16 100644
--- a/drivers/rtc/rtc-bq32k.c
+++ b/drivers/rtc/rtc-bq32k.c
@@ -16,6 +16,7 @@
 #include <linux/kstrtox.h>
 #include <linux/errno.h>
 #include <linux/bcd.h>
+#include <linux/delay.h>
 
 #define BQ32K_SECONDS		0x00	/* Seconds register address */
 #define BQ32K_SECONDS_MASK	0x7F	/* Mask over seconds value */
@@ -89,9 +90,17 @@ static int bq32k_write(struct device *dev, void *data, uint8_t off, uint8_t len)
 
 static int bq32k_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
+	struct i2c_client *client = to_i2c_client(dev);
 	struct bq32k_regs regs;
 	int error;
 
+	/*
+	 * When the device doesn't have the interrupt connected, prevent
+	 * userpace from polling the RTC registers too frequently.
+	 */
+	if (client->irq <= 0)
+		usleep_range(2000, 2500);
+
 	error = bq32k_read(dev, &regs, 0, sizeof(regs));
 	if (error)
 		return error;
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] rtc: mv: add suspend/resume support for wakeup

[Sasha Levin]

From: Xue Lei <Xue.Lei@windriver.com>

[ Upstream commit 851d961ff248218f681c53cf0f7f08cf8201a117 ]

Add PM suspend/resume callbacks to enable/disable IRQ wake for the
RTC alarm interrupt. This allows the RTC alarm to wake the system
from STR (e.g. via rtcwake -m mem -s N).

Without this, the RTC IRQ is masked during suspend by the MPIC's
IRQCHIP_MASK_ON_SUSPEND behavior, preventing alarm-based wakeup.

Signed-off-by: Xue Lei <Xue.Lei@windriver.com>
Link: https://patch.msgid.link/20260611023350.1370881-1-Xue.Lei@windriver.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: Subject Line
**Record:** `[rtc: mv]` `[add]` — Add suspend/resume PM callbacks so the
Marvell Orion RTC alarm IRQ can wake the system from STR.

### Step 1.2: Tags
**Record:**
- **Fixes:** — none
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none (maintainer applied directly)
- **Acked-by:** — none
- **Link:** https://patch.msgid.link/20260611023350.1370881-1-
  Xue.Lei@windriver.com
- **Cc: stable:** — none (expected for manual review)
- **Signed-off-by:** Xue Lei, Alexandre Belloni (ignore pipeline SOB
  markers)

Notable: RTC subsystem maintainer (Belloni) applied the patch; no syzbot
or user bug reports.

### Step 1.3: Body Analysis
**Record:**
- **Bug:** RTC alarm cannot wake the system from suspend-to-RAM
  (`rtcwake -m mem -s N` fails).
- **Symptom:** System stays suspended past the alarm time; scheduled
  wake does not occur.
- **Root cause (author):** During suspend, the parent irqchip masks non-
  wakeup IRQs (`IRQCHIP_MASK_ON_SUSPEND`). Without `enable_irq_wake()`
  in the driver suspend path, the RTC alarm IRQ is masked and cannot
  fire.
- **Version info:** None in the message.

### Step 1.4: Hidden Bug Fix?
**Record:** Yes. Subject says “add suspend/resume support,” but this
completes broken wakeup behavior: the driver already calls
`device_init_wakeup(&pdev->dev, true)` when an IRQ is present (since
alarm support was added in 2009), yet never called `enable_irq_wake()`.
That is incomplete PM integration, not a new user-facing feature.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/rtc/rtc-mv.c` (+23 lines, 0 removed)
- **Functions added:** `mv_rtc_suspend()`, `mv_rtc_resume()`
- **Structure modified:** `mv_rtc_driver` (adds `.pm = &mv_rtc_pm_ops`)
- **Scope:** Single-file, surgical driver PM fix

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (suspend/resume):** Before: no driver PM callbacks; IRQ
  treated as a normal interrupt during suspend. After: if
  `device_may_wakeup(dev)` and `pdata->irq >= 0`, call
  `enable_irq_wake()` on suspend and `disable_irq_wake()` on resume.
- **Hunk 2 (driver struct):** Registers `SIMPLE_DEV_PM_OPS` with the
  platform driver.
- **Path affected:** System suspend/resume (`CONFIG_PM_SLEEP`), only
  when the RTC has a valid IRQ and wakeup is enabled.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Logic/correctness — incomplete PM wakeup integration.
- **Mechanism:** `kernel/irq/pm.c` `suspend_device_irq()` masks IRQs
  with `IRQCHIP_MASK_ON_SUSPEND` unless `irqd_is_wakeup_set()`.
  `device_init_wakeup()` alone does not set that flag;
  `enable_irq_wake()` does. Without it, the RTC alarm IRQ is masked at
  the irqchip during suspend and cannot wake the system.

### Step 2.4: Fix Quality
**Record:**
- **Quality:** Obviously correct; identical pattern used in `rtc-
  armada38x.c`, `rtc-tegra.c`, `rtc-cmos.c`, and many other RTC drivers
  in this tree.
- **Regression risk:** Very low. Symmetric enable/disable, guarded by
  `device_may_wakeup()` and `pdata->irq >= 0`.
- **Red flags:** None.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- `device_init_wakeup()` at line 267: introduced with alarm support,
  present since commit `aeedacaeaf9c0` (2009-12-16, “rtc-mv: add support
  for Alarm”).
- PM suspend/resume callbacks: **not present** in this tree; added by
  candidate commit `851d961ff2482` (on `master`, not yet in HEAD).

### Step 3.2: Fixes: Tag
**Record:** No `Fixes:` tag. Bug dates to original alarm/wakeup support
(2009); never had `enable_irq_wake()`.

### Step 3.3: Related File History
**Record:** Recent `rtc-mv.c` changes are cleanups (`ede66fb37f127`,
`5621f28b01228`, `8c28c4993f117`). No prior wakeup PM fix. Standalone
1/1 patch (b4 dig confirms single revision).

### Step 3.4: Author Context
**Record:** Xue Lei (Wind River, embedded). Alexandre Belloni (RTC
maintainer) applied. No related series from this author in `rtc-mv.c`.

### Step 3.5: Dependencies
**Record:** No prerequisites. Uses standard kernel PM/IRQ APIs present
in 6.18.44. `git apply --check` on the diff succeeds against the current
tree.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:**
- **URL:** https://patch.msgid.link/20260611023350.1370881-1-
  Xue.Lei@windriver.com
- **Revisions:** v1 only (b4 dig `-a`)
- **Review:** Belloni replied “Applied, thanks!” — no NAKs, no
  objections
- **Stable nomination:** None in thread

### Step 4.2: Reviewers
**Record:** CC’d: `linux-rtc@vger.kernel.org`, `linux-
kernel@vger.kernel.org`, Belloni. Maintainer applied.

### Step 4.3: Bug Report
**Record:** No external bug report or syzbot link. Issue inferred from
irqchip PM behavior and missing driver callback.

### Step 4.4: Related Patches
**Record:** Sister driver `rtc-armada38x.c` already implements the same
`enable_irq_wake`/`disable_irq_wake` pattern (lines 543–571). `rtc-mv.c`
was the outlier.

### Step 4.5: Stable List History
**Record:** Not searched on lore stable list; no stable discussion found
in the patch thread.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `mv_rtc_suspend()`, `mv_rtc_resume()`, `mv_rtc_probe()`
(calls `device_init_wakeup`), `mv_rtc_alarm_irq_enable()`,
`mv_rtc_interrupt()`.

### Step 5.2: Callers
**Record:** PM core invokes driver suspend/resume during system STR.
`mv_rtc_probe()` runs at platform device init on Marvell boards
(Kirkwood, Dove, Armada 370/375). Users trigger wakeup via `rtcwake` or
`/sys/class/rtc/rtcX/wakealarm`.

### Step 5.3: Callees
**Record:** `enable_irq_wake()`, `disable_irq_wake()`,
`device_may_wakeup()`, `dev_get_drvdata()`.

### Step 5.4: Reachability
**Record:** Reachable on any `marvell,orion-rtc` platform with IRQ,
`CONFIG_PM_SLEEP`, and STR support. DT platforms verified: Kirkwood,
Dove, Armada 370/375 (`arch/arm/boot/dts/marvell/*.dtsi`). Commit’s
“MPIC” reference matches `drivers/irqchip/irq-armada-370-xp.c` irqchip
named `"MPIC"` with `IRQCHIP_MASK_ON_SUSPEND`.

### Step 5.5: Similar Patterns
**Record:** 40+ RTC drivers in this tree use the same `enable_irq_wake`
in suspend pattern. `rtc-armada38x.c` is the closest Marvell sibling.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** Local tree is **Linux 6.18.44** (`git describe`:
`v6.18.44-1-g2736c32da98b9`). `drivers/rtc/rtc-mv.c` has
`device_init_wakeup(&pdev->dev, true)` (line 267) but **no** PM ops or
`enable_irq_wake()`. Candidate commit `851d961ff2482` is on `master` but
**not** an ancestor of HEAD.

### Step 6.2: Backport Complications
**Record:** Clean apply verified (`git apply --check` passes). No
conflicting recent changes in the insertion region.

### Step 6.3: Related Fixes Already Present?
**Record:** None for `rtc-mv` wakeup PM. `rtc-armada38x` already has the
fix; `rtc-mv` does not.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem
**Record:** `drivers/rtc` — **IMPORTANT** (embedded/NAS platforms:
Marvell Kirkwood, Dove, Armada). Not core kernel, but affects PM on real
deployed hardware.

### Step 7.2: Activity
**Record:** Moderate activity; recent changes are cleanups, not PM
rework.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users of Marvell Orion RTC on platforms with STR and a wired
RTC IRQ (Kirkwood NAS, Dove, Armada 370/375, etc.). Config-dependent:
`CONFIG_RTC_DRV_MV` + `CONFIG_PM_SLEEP` + working IRQ.

### Step 8.2: Trigger Conditions
**Record:** User sets RTC alarm and suspends (`rtcwake -m mem`,
`wakealarm` sysfs, or equivalent). **Common** on embedded systems using
scheduled wake. Unprivileged users can typically set RTC alarms.

### Step 8.3: Failure Mode Severity
**Record:** **MEDIUM** — no crash, corruption, or deadlock. System fails
to wake on schedule; operational impact for scheduled maintenance, NAS
wake, industrial controllers. Wakeup is advertised via
`device_init_wakeup()` but does not work.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Restores intended RTC alarm wakeup from STR on affected
  Marvell hardware.
- **Risk:** Very low (23 lines, established pattern, irq >= 0 guard).
- **Ratio:** Favorable — fixes a long-standing functional defect with
  minimal code.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real, reproducible functional bug (rtcwake/STR wakeup broken)
- Driver already registers as wakeup-capable since 2009
- Standard, proven fix pattern (sibling `rtc-armada38x` already has it)
- Small, self-contained, applies cleanly to 6.18.44
- Maintainer-reviewed and applied
- Affects deployed embedded hardware

**AGAINST backport:**
- Not a crash, security, corruption, or deadlock
- Subject wording sounds like “adding feature”
- No user bug report or syzbot evidence
- Long-standing issue (lower urgency than regressions)

**Unresolved:** No end-user bugzilla report; impact quantified only by
code analysis and platform DT presence.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — standard pattern; maintainer
   applied; no review objections.
2. Fixes a real bug affecting users? **PASS** — broken STR wakeup on
   Marvell RTC platforms.
3. Important issue? **PASS (borderline)** — not crash/security, but
   broken suspend wakeup on hardware that advertises wakeup support;
   operational impact on embedded systems.
4. Small and contained? **PASS** — 23 lines, one file.
5. No new features or APIs? **PASS** — completes existing wakeup
   registration; no new sysfs/APIs.
6. Can apply to local tree? **PASS** — verified clean apply.

### Step 9.3: Exception Categories
**Record:** Suspend/resume hardware wakeup workaround — same category as
other RTC `enable_irq_wake` fixes. Not a device-ID/quirk/DT/build/doc
exception, but functionally equivalent to a PM quirk fix.

### Step 9.4: Decision Rationale

For **Linux 6.18.44**, this commit should be backported. The driver has
advertised wakeup capability via `device_init_wakeup()` since alarm
support was added, but without `enable_irq_wake()` the alarm IRQ is
masked during suspend on irqchips with `IRQCHIP_MASK_ON_SUSPEND`
(including Marvell Armada’s “MPIC” irqchip). That makes `rtcwake -m mem`
silently fail on affected Marvell platforms. The fix is minimal, follows
an established pattern already used in `rtc-armada38x.c` and dozens of
other RTC drivers, applies cleanly, and carries negligible regression
risk while restoring expected PM behavior.

---

## Verification

- [Phase 1] Parsed commit `851d961ff2482`: tags, body, intent recorded
- [Phase 2] Read full diff: +23 lines in `drivers/rtc/rtc-mv.c`, PM ops
  added
- [Phase 3] `git describe HEAD`: v6.18.44-1-g2736c32da98b9; Makefile
  VERSION 6.18.44
- [Phase 3] `git merge-base --is-ancestor 851d961ff2482 HEAD`: NOT IN
  TREE
- [Phase 3] `git log -S device_init_wakeup -- drivers/rtc/rtc-mv.c`:
  alarm added `aeedacaeaf9c0` (2009)
- [Phase 3] `git blame -L 266,270 drivers/rtc/rtc-mv.c`:
  `device_init_wakeup` present, no PM callbacks
- [Phase 3] `git apply --check` on commit diff: applies cleanly
- [Phase 4] `b4 dig -c 851d961ff2482`: found lore thread
- [Phase 4] `b4 dig -a`: single v1 revision
- [Phase 4] `b4 dig -w`: CC’d linux-rtc, Belloni
- [Phase 4] Mbox thread: Belloni “Applied, thanks!” — no stable Cc, no
  NAKs
- [Phase 5] Read `kernel/irq/pm.c` suspend path:
  `IRQCHIP_MASK_ON_SUSPEND` masks non-wakeup IRQs
- [Phase 5] Read `drivers/irqchip/irq-armada-370-xp.c`: MPIC chip has
  `IRQCHIP_MASK_ON_SUSPEND`
- [Phase 5] Grep `enable_irq_wake` in `drivers/rtc/`: 40+ drivers use
  same pattern
- [Phase 5] Read `rtc-armada38x.c` lines 543–571: identical
  suspend/resume wakeup handling
- [Phase 6] Read current `drivers/rtc/rtc-mv.c`: missing PM ops
  (confirmed buggy state)
- [Phase 6] Grep `marvell,orion-rtc` in `arch/arm/boot/dts/marvell/`:
  Kirkwood, Dove, Armada platforms
- [Phase 6] `git log --oneline -20 -- drivers/rtc/rtc-mv.c`: no prior
  wakeup PM fix

**YES**

 drivers/rtc/rtc-mv.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/rtc/rtc-mv.c b/drivers/rtc/rtc-mv.c
index c27ad626d09fc..f88976fd6d5da 100644
--- a/drivers/rtc/rtc-mv.c
+++ b/drivers/rtc/rtc-mv.c
@@ -301,6 +301,28 @@ static const struct of_device_id rtc_mv_of_match_table[] = {
 MODULE_DEVICE_TABLE(of, rtc_mv_of_match_table);
 #endif
 
+#ifdef CONFIG_PM_SLEEP
+static int mv_rtc_suspend(struct device *dev)
+{
+	struct rtc_plat_data *pdata = dev_get_drvdata(dev);
+
+	if (device_may_wakeup(dev) && pdata->irq >= 0)
+		enable_irq_wake(pdata->irq);
+	return 0;
+}
+
+static int mv_rtc_resume(struct device *dev)
+{
+	struct rtc_plat_data *pdata = dev_get_drvdata(dev);
+
+	if (device_may_wakeup(dev) && pdata->irq >= 0)
+		disable_irq_wake(pdata->irq);
+	return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(mv_rtc_pm_ops, mv_rtc_suspend, mv_rtc_resume);
+
 /*
  * mv_rtc_remove() lives in .exit.text. For drivers registered via
  * module_platform_driver_probe() this is ok because they cannot get unbound at
@@ -312,6 +334,7 @@ static struct platform_driver mv_rtc_driver __refdata = {
 	.driver		= {
 		.name	= "rtc-mv",
 		.of_match_table = of_match_ptr(rtc_mv_of_match_table),
+		.pm	= &mv_rtc_pm_ops,
 	},
 };
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] rtc: aspeed: add AST2700 compatible

[sashiko-bot]

> From: Tommy Huang <tommy_huang@aspeedtech.com>
> 
> [ Upstream commit 3319cfeeb8c4047026f84df045c438f7bbd338a6 ]
> 
> Add support for matching the RTC controller on ASPEED AST2700 SoCs.
> 
> The AST2700 RTC controller is compatible with the existing ASPEED
> RTC driver implementation.
> 
> Signed-off-by: Tommy Huang <tommy_huang@aspeedtech.com>
> Link: https://patch.msgid.link/20260601-ast2700-rtc-v1-2-15d4ca46500a@aspeedtech.com
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-179-sashal@kernel.org?part=1

Re: [PATCH AUTOSEL 6.18] rtc: renesas-rtca3: Check RADJ poll result during initial setup

[sashiko-bot]

> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> 
> [ Upstream commit fafb016d081200c7652e84202f8ba5951e659a53 ]
> 
> In rtca3_initial_setup(), the driver clears the RTCA3_RADJ register and
> waits for it to reach zero using readb_poll_timeout(). Check the return
> value of readb_poll_timeout() and propagate the error if the poll fails.
> 
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S
> Link: https://patch.msgid.link/20260602192559.1791344-3-prabhakar.mahadev-lad.rj@bp.renesas.com
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-314-sashal@kernel.org?part=1

Re: [PATCH AUTOSEL 6.18-5.10] rtc: bq32000: add delay between RTC reads

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The delay workaround is bypassed if `client->irq > 0`, but because the driver lacks IRQ handling, userspace will always poll and trigger the hardware bug.
--

commit 50c036b36c688887d406f6107b0ade6653a75e5c
Author: Adriana Stancu <adriana@arista.com>

rtc: bq32000: add delay between RTC reads

This patch adds a delay before reading the BQ32000 RTC registers to prevent
stale reads or select timeouts during aggressive polling. The hardware needs
idle time to refresh its register buffer, which is starved when tools like
hwclock continuously poll on systems without an interrupt line.

Link: https://patch.msgid.link/20260416142151.3385827-1-adriana@arista.com

> diff --git a/drivers/rtc/rtc-bq32k.c b/drivers/rtc/rtc-bq32k.c
> index 7ad34539be4d2..245e5e45d6a16 100644
> --- a/drivers/rtc/rtc-bq32k.c
> +++ b/drivers/rtc/rtc-bq32k.c

[ ... ]

> @@ -89,9 +90,17 @@ static int bq32k_write(struct device *dev, void *data, uint8_t off, uint8_t len)
>  
>  static int bq32k_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  {
> +	struct i2c_client *client = to_i2c_client(dev);
>  	struct bq32k_regs regs;
>  	int error;
>  
> +	/*
> +	 * When the device doesn't have the interrupt connected, prevent
> +	 * userpace from polling the RTC registers too frequently.
> +	 */
> +	if (client->irq <= 0)

[Severity: Medium]
Will this condition incorrectly skip the delay workaround on systems that have
an interrupt defined in the device tree?

Because the BQ32000 driver itself lacks IRQ handling (RTC_FEATURE_ALARM is not
set and no alarm_irq_enable callback exists), the RTC core will always fall
back to UIE emulation. This emulation aggressively polls rtc_read_time()
regardless of whether client->irq > 0.

If client->irq > 0, the workaround is bypassed, but the hardware is still
subject to the exact same aggressive polling from userspace. Does this leave
these systems vulnerable to the same hardware register lockup (stale reads and
select timeouts) that this patch intends to fix?

> +		usleep_range(2000, 2500);
> +
>  	error = bq32k_read(dev, &regs, 0, sizeof(regs));
>  	if (error)
>  		return error;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-423-sashal@kernel.org?part=1

Re: [PATCH AUTOSEL 6.18-6.12] rtc: mv: add suspend/resume support for wakeup

[sashiko-bot]

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

New issues:
- [High] The driver unconditionally calls disable_irq_wake() in mv_rtc_resume() if device_may_wakeup() is true, ignoring whether enable_irq_wake() actually succeeded during suspend. On platforms with irqchips that do not support wake configuration, this causes a WARN(1) splat on resume.

Pre-existing issues:
- [High] The probe function silently disables alarm functionality if platform_get_irq() returns an error, failing to handle -EPROBE_DEFER correctly.
- [High] The device clock is disabled in `mv_rtc_remove()` while the shared interrupt is still registered, which could cause a bus error and kernel panic if the interrupt fires.
--

commit a94ce5838cf02b58cbaaa54595d3a6090ffe754c
Author: Xue Lei <Xue.Lei@windriver.com>

rtc: mv: add suspend/resume support for wakeup

Add PM suspend/resume callbacks to enable/disable IRQ wake for the
RTC alarm interrupt. This allows the RTC alarm to wake the system
from STR (e.g. via rtcwake -m mem -s N).

Link: https://patch.msgid.link/20260611023350.1370881-1-Xue.Lei@windriver.com

> diff --git a/drivers/rtc/rtc-mv.c b/drivers/rtc/rtc-mv.c
> index c27ad626d09fc..f88976fd6d5da 100644
> --- a/drivers/rtc/rtc-mv.c
> +++ b/drivers/rtc/rtc-mv.c
[ ... ]
> @@ -301,6 +301,28 @@ static const struct of_device_id rtc_mv_of_match_table[] = {
[ ... ]
> +#ifdef CONFIG_PM_SLEEP
> +static int mv_rtc_suspend(struct device *dev)
> +{
> +	struct rtc_plat_data *pdata = dev_get_drvdata(dev);
> +
> +	if (device_may_wakeup(dev) && pdata->irq >= 0)
> +		enable_irq_wake(pdata->irq);
> +	return 0;
> +}
> +
> +static int mv_rtc_resume(struct device *dev)
> +{
> +	struct rtc_plat_data *pdata = dev_get_drvdata(dev);
> +
> +	if (device_may_wakeup(dev) && pdata->irq >= 0)
> +		disable_irq_wake(pdata->irq);

[Severity: High]
Does this code trigger an unbalanced wake disable warning on resume if
enable_irq_wake() failed during suspend?

In mv_rtc_suspend(), the return value of enable_irq_wake() is ignored. On
Kirkwood and Dove platforms, the orion-intc irqchip does not support wake
configuration, so enable_irq_wake() fails and returns -ENXIO without
incrementing the IRQ's wake_depth.

During system resume, disable_irq_wake() will be called unconditionally,
which decrements the wake_depth from 0 and triggers a warning splat.

> +	return 0;
> +}
> +#endif
[ ... ]

While reviewing this driver, I noticed a few pre-existing issues:

drivers/rtc/rtc-mv.c:mv_rtc_probe() {
[ ... ]
	pdata->irq = platform_get_irq(pdev, 0);
[ ... ]
	if (pdata->irq >= 0)
		device_init_wakeup(&pdev->dev, true);
	else
		clear_bit(RTC_FEATURE_ALARM, pdata->rtc->features);
[ ... ]
}

[Severity: High]
This is a pre-existing issue, but does this code permanently disable the
alarm functionality if the IRQ probe is deferred?

If the interrupt controller is not yet ready during mv_rtc_probe(),
platform_get_irq() returns -EPROBE_DEFER. Because this value is negative,
the code skips IRQ setup and executes the clear_bit() path, successfully
registering the RTC device without the alarm instead of properly deferring
the probe.

drivers/rtc/rtc-mv.c:mv_rtc_remove() {
[ ... ]
	if (!IS_ERR(pdata->clk))
		clk_disable_unprepare(pdata->clk);
}

[Severity: High]
This is a pre-existing issue, but can this code cause a bus fault if a
shared interrupt fires while the module is being removed?

The device clock is disabled here, but the interrupt is requested using
devm_request_irq() with IRQF_SHARED. Because the IRQ is devres-managed, it
is not freed until devres_release_all() runs after mv_rtc_remove() completes.

If another device on the same shared IRQ line triggers an interrupt during
this window, mv_rtc_interrupt() will execute:

drivers/rtc/rtc-mv.c:mv_rtc_interrupt() {
	/* alarm irq? */
	if (!readl(ioaddr + RTC_ALARM_INTERRUPT_CASUE_REG_OFFS))
[ ... ]
}

Attempting to read from the device registers while the clock is disabled
could trigger a synchronous external abort and a kernel panic.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-454-sashal@kernel.org?part=1