* [PATCH AUTOSEL 6.18-5.10] rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode
[not found] <20261019135441.1420968-1-sashal@kernel.org>
@ 2026-10-19 13:45 ` Sasha Levin
2026-10-19 14:04 ` sashiko-bot
2026-10-19 13:51 ` [PATCH AUTOSEL 6.18-5.10] rtc: brcmstb-waketimer: add missing MODULE_DEVICE_TABLE() Sasha Levin
2026-10-19 13:51 ` [PATCH AUTOSEL 6.18-5.10] rtc: ab-eoz9: " Sasha Levin
2 siblings, 1 reply; 6+ messages in thread
From: Sasha Levin @ 2026-10-19 13:45 UTC (permalink / raw)
To: patches, stable
Cc: Robert Leussler, Alexandre Belloni, Sasha Levin, linux-rtc,
linux-kernel
From: Robert Leussler <robert.leussler@leica-geosystems.com>
[ Upstream commit 878d93aaa596a861dbc8d71f7c38e62a2e805f01 ]
The RX8130 wakeup alarm never fired when set via
/sys/class/rtc/rtc0/wakealarm. The root cause is that the WADA bit
(bit 3) in the Extension register (0x1c) was never set before
programming the alarm registers.
Per the RX8130 datasheet:
WADA=0 - Week alarm: register 0x19 is compared against day-of-week
WADA=1 - Day alarm: register 0x19 is compared against day-of-month
rx8130_set_alarm() always writes a BCD day-of-month value to alarm
register 0x19, so WADA must be 1. With WADA=0 the hardware matched the
day-of-month value (e.g. 15) as a day-of-week index, which is always
out of range (valid weekdays are 0-6), so the alarm interrupt was never
asserted.
Fix by setting the WADA bit in rx8130_set_alarm() before writing the
Extension register back to the device.
This is consistent with rx8130_read_alarm(), which decodes the same
register under the same assumption (24-hour and day-of-month mode).
Signed-off-by: Robert Leussler <robert.leussler@leica-geosystems.com>
Link: https://patch.msgid.link/20260721081907.3518648-1-robert.leussler@leica-geosystems.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:
This is a one-line RX8130 wakeup-alarm fix. The buggy `&=` is present in
this 6.12.111 tree, the datasheet matches the new polarity, and the
patch applies cleanly.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: PARSE THE SUBJECT LINE
Record: **[rtc/ds1307] [fix] RX8130 wakeup alarm never fires because
WADA is not set for day-of-month mode**
### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- **Fixes:** none (expected for this review)
- **Reported-by:** none
- **Tested-by:** none (author is from Leica Geosystems; they hit this on
hardware)
- **Reviewed-by:** none
- **Acked-by:** none
- **Link:** `https://patch.msgid.link/20260721081907.3518648-1-
robert.leussler@leica-geosystems.com`
- **Cc: stable:** none (expected)
- **Signed-off-by:** Robert Leussler (author); Alexandre Belloni (RTC
maintainer). Ignore any Sasha Levin SOB if later added by the
pipeline.
### Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- **Bug:** RX8130 wakeup alarm never fires when set via
`/sys/class/rtc/rtc0/wakealarm`.
- **Symptom:** scheduled RTC wakeup does not occur; `/IRQ` is never
asserted.
- **Root cause:** `rx8130_set_alarm()` writes BCD day-of-month to alarm
register 0x19 but never sets WADA (Extension 0x1c bit 3). With WADA=0
the chip compares 0x19 as a week alarm.
- **Version info:** none in the message. Code has been in-tree since
RX8130 support (v4.13); the current `&=` form dates to 2019.
- **Author’s fix:** `ctl[0] &= WADA` → `ctl[0] |= WADA` so WADA=1 (day-
of-month), matching `rx8130_read_alarm()`.
### Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not hidden. Explicit hardware-logic fix. The `&=` → `|=` change
also stops wiping other Extension bits (FSEL/USEL/TE/TSEL), which is
extra correctness, not a drive-by refactor.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/rtc/rtc-ds1307.c` — **1 line changed** (`&=` → `|=`)
- Function: `rx8130_set_alarm()`
- Scope: single-file surgical fix
### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- **Before:** after reading Extension/Flag/Control0, `ctl[0] &= BIT(3)`
keeps only the current WADA bit (typically 0 from POR) and **clears
every other Extension bit**, then writes it back, then programs
min/hour/**mday**.
- **After:** `ctl[0] |= BIT(3)` **sets WADA=1** and **preserves**
FSEL/USEL/TE/TSEL, then programs the same mday alarm.
### Step 2.3: IDENTIFY THE BUG MECHANISM
Record:
- **Category:** logic / hardware-programming correctness (wrong alarm
mode bit).
- **Mechanism:** RX8130 WADA selects week vs day comparison for register
0x19. Driver always writes `bin2bcd(tm_mday)` to 0x19, so WADA must be
1. WADA=0 makes the chip treat that BCD value as a week-alarm bitmap,
so the alarm either never matches or matches the wrong weekdays.
Verified from Epson RX8130CE application manual (Table 23):
- WADA=0 → WEEK is the alarm target
- WADA=1 → DAY (day-of-month) is the alarm target
- Example “Day” settings explicitly use WADA=1
### Step 2.4: ASSESS THE FIX QUALITY
Record:
- **Quality:** obviously correct. One operator change; polarity matches
the datasheet and the existing read path (`tm_mday`, comment “day-of-
month modes”).
- **Regression risk:** very low. Only RX8130 `set_alarm`. `|=` is the
correct RMW (old `&= BIT(3)` was also clobbering FSEL/TE/TSEL). No
API/lock/struct change.
- The author’s “valid weekdays are 0-6, so mday 15 never matches” is
slightly imprecise: week mode is a **bitmap**, so some BCD mday values
can match the wrong weekdays. Failure mode is still “alarm broken,”
possibly worse than “never fires.”
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: BLAME THE CHANGED LINES
Record:
- Buggy line `ctl[0] &= RX8130_REG_EXTENSION_WADA` introduced by
**3f929cad94338** (“rtc: ds1307: rx8130: Fix alarm handling”, Uwe
Kleine-König, 2019-01-25).
- First appeared: **v5.1-rc1**. Present in this tree (`git merge-base
--is-ancestor` succeeded).
- RX8130 support itself: **ee0981be77045** (v4.13-rc1), which used
`ctl[0] &= ~WADA` (explicitly **cleared** WADA).
### Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. Historical introducer is 3f929cad94338, which is
in this tree.
That 2019 commit **intended** to “clear WADA for day-of-month,” but:
1. Its datasheet polarity was inverted vs Epson (it treated WADA=1 as
weekdays).
2. Its diff changed `&= ~WADA` to `&= WADA` (dropped `~`), which does
**not** clear WADA; it preserves WADA and zeros other Extension bits.
Original 2017 code already chose the wrong polarity for mday. The 2019
change left WADA at POR 0 and made Extension clobber worse.
### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record (recent on this file in this tree):
- `e0e6ddc431177` rtc: ds1307: Fix off-by-one issue with wday for rx8130
— **time** wday encoding, not alarm WADA. Independent; already here.
- `204756f016726` rtc: ds1307: Fix wday settings for rx8130 — also time,
not alarm.
- `3f929cad94338` — the buggy alarm handling change.
Standalone one-line fix; not patch X/Y.
### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Robert Leussler has no other rtc commits in this tree. Alexandre
Belloni (RTC maintainer) signed off and applied it. Weight comes from
maintainer application + hardware report, not from a regular-contributor
history.
### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: None. Diff only needs `rx8130_set_alarm()` and
`RX8130_REG_EXTENSION_WADA`, both present. `git show 878d93aaa596 | git
apply --check` **succeeded** on this tree.
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- `b4 dig -c 878d93aaa596` → https://patch.msgid.link/20260721081907.351
8648-1-robert.leussler@leica-geosystems.com
- `b4 dig -a`: **v1 only** (no v2/v3)
- Thread: submission (2026-07-21) → Sashiko AI note on pre-existing FLAG
RMW → author reply (2026-08-10): FLAG issue is pre-existing and out of
scope → **Alexandre Belloni: “Applied, thanks!”** (2026-08-20), no NAK
- lore.kernel.org WebFetch returned 403; thread recovered via `b4 dig
-m` and openwall/spinics
### Step 4.2: CHECK WHO REVIEWED THE PATCH
Record (`b4 dig -w`): To/Cc were Alexandre Belloni, linux-rtc, linux-
kernel. Maintainer applied it. No other human Reviewed-by.
### Step 4.3: SEARCH FOR THE BUG REPORT
Record: No bugzilla/syzbot. Concrete userspace trigger in the message
(`/sys/class/rtc/rtc0/wakealarm`). Author is an RX8130 user (Leica
Geosystems). Sashiko flagged a **pre-existing** write-0-to-clear FLAG
RMW (VLF); author correctly kept that separate. That does not weaken
this WADA fix.
### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Standalone 1/1. Not part of a multi-patch series.
### Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: lore.kernel.org/stable WebFetch 403. No other evidence of a
stable NAK. Absence of prior stable discussion is not a negative.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: IDENTIFY KEY FUNCTIONS
Record: `rx8130_set_alarm()` only.
### Step 5.2: TRACE CALLERS
Record:
- Wired as `rx8130_rtc_ops.set_alarm` in `drivers/rtc/rtc-ds1307.c`
- RTC core: `rtc_set_alarm()` / `__rtc_set_alarm()` in
`drivers/rtc/interface.c`
- Userspace: `drivers/rtc/sysfs.c` (`wakealarm`), plus `RTC_WKALM_SET` /
`RTC_ALM_SET` ioctls
- Reachable whenever RX8130 alarm IRQ or `wakeup-source` is enabled
(chip desc has `.alarm = 1`)
### Step 5.3: TRACE CALLEES
Record: `regmap_bulk_read/write` of Extension+Flag+Control0 and alarm
min/hour/day, then optional Control0 AIE write. No alloc/locking in this
function.
### Step 5.4: FOLLOW THE CALL CHAIN
Record: `echo T > /sys/class/rtc/rtc0/wakealarm` or `rtcwake` →
`rtc_set_alarm` → `rx8130_set_alarm`. Unprivileged access depends on rtc
device node permissions; typical embedded images use this for suspend
wakeup. **Yes, userspace-reachable.**
### Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Sibling Epson/MicroCrystal chips also program WADA, with **chip-
specific polarity** (RX8010 clears WADA while writing mday;
RV8803/RV3028/RV3032 set WADA). Not a copy-paste of those; RX8130
datasheet is the authority. No second broken copy in `rtc-ds1307.c`.
---
## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record:
- Tree: **`git describe HEAD` = `p-6.12-3-gc504cf0baa3d8`**, **`make
kernelversion` = 6.12.111**
- Buggy code is here at `drivers/rtc/rtc-ds1307.c:665`: `ctl[0] &=
RX8130_REG_EXTENSION_WADA;`
- `git merge-base --is-ancestor 878d93aaa596 HEAD` → **not an ancestor**
(fix not in this tree)
- `git merge-base --is-ancestor 3f929cad94338 HEAD` → **yes** (bug is in
this tree)
- Bug introduced v5.1 (wrong `&=` form); wrong polarity since v4.13
### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: **Clean apply** (`git apply --check` exit 0). Surrounding
`rx8130_set_alarm()` matches the mainline hunk. No rework needed.
### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: wday off-by-one (`e0e6ddc431177`) is already here and is a
different bug. No existing WADA `|=` fix.
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: **drivers/rtc** (Epson RX8130 in rtc-ds1307). Criticality:
**PERIPHERAL** for the kernel as a whole, **IMPORTANT** for boards that
use this RTC as the wake source.
### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: rtc-ds1307 still gets real fixes in this tree (OSF, max clock
rate, wday). Mature driver; this is a long-standing programming error,
not churn from new code.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: DETERMINE WHO IS AFFECTED
Record: **Driver-specific / config-specific** — `CONFIG_RTC_DRV_DS1307`
+ Epson RX8130 (`epson,rx8130` / `rx8130`) with alarm/wakeup wired.
### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: Any `set_alarm` / `wakealarm` / `rtcwake` on RX8130. Common on
embedded systems that sleep and wake on RTC. Not a rare error path.
### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record:
- Failure: RTC alarm IRQ/`/IRQ` does not fire as intended → **system
fails to wake from suspend** at the scheduled time (or wakes on the
wrong weekday if the BCD mday happens to look like a week bitmap).
- Severity: **HIGH** for those devices (lost wakeup; device can stay
asleep). Not a KASAN/UAF/panic.
### Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- **Benefit:** high for RX8130 users — restores the documented
alarm/wakeup path.
- **Risk:** very low — 1 line, polarity confirmed by datasheet,
maintainer applied, no locking/API change.
- **Ratio:** strongly favors backport.
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: COMPILE THE EVIDENCE
**FOR:**
- Real user-visible bug: RX8130 `wakealarm` does not work
- Datasheet-confirmed WADA polarity (0=week, 1=day)
- Driver always writes `tm_mday`; WADA must be 1
- Buggy `&=` is in this 6.12.111 tree; fix is not
- 1-line, obviously correct; apply-check clean
- RTC maintainer applied after review window; no NAK
- Also stops Extension-register clobber of FSEL/TE/TSEL
- Standalone; no prerequisites missing here
**AGAINST:**
- Not a crash/security/corruption issue
- Only RX8130, not all rtc-ds1307 chips
- No Fixes:/Cc:stable (expected; not a negative)
- No second independent reporter beyond the author
**UNRESOLVED:**
- Could not fetch lore.kernel.org or lore.kernel.org/stable (403);
thread recovered via b4/openwall
- Did not re-test on hardware (author did; commit describes
`/sys/class/rtc/rtc0/wakealarm`)
### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — datasheet + maintainer apply
+ hardware report
2. Fixes a real bug that affects users? **PASS** — wakeup alarm broken
on RX8130
3. Important issue? **PASS** — failed RTC wakeup / wrong-day match; HIGH
for this hardware
4. Small and contained? **PASS** — 1 line, one function
5. No new features or APIs? **PASS**
6. Can apply to the local tree? **PASS** — clean apply; buggy code
present
### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: Not a device-ID/quirk/DT/build/docs exception. Ordinary
contained driver bugfix.
### Step 9.4: MAKE YOUR DECISION
This 6.12.111 tree has the 2019 `&= WADA` bug. The fix is the smallest
possible correction so the chip compares day-of-month the way the driver
already programs it. That is exactly the kind of hardware bug stable
users of this RTC need.
Verification:
- [Phase 1] Parsed tags: Link to patch.msgid.link; SOBs Leussler +
Belloni; no Fixes/Reported-by/Cc:stable
- [Phase 2] Diff: 1 line in `rx8130_set_alarm()`, `&=` → `|=` on
`RX8130_REG_EXTENSION_WADA`
- [Phase 2] Datasheet (Epson RX8130CE app manual Table 23): WADA=0 week,
WADA=1 day — matches the patch
- [Phase 3] git blame: line from 3f929cad94338 (v5.1-rc1); original
support ee0981be77045 (v4.13) used `&= ~WADA`
- [Phase 3] git show 3f929cad94338: dropped `~`, inverted polarity vs
datasheet
- [Phase 3] git merge-base --is-ancestor 3f929cad94338 HEAD: yes;
878d93aaa596 HEAD: no
- [Phase 4] b4 dig -c 878d93aaa596: lore msgid 20260721081907.3518648-1
- [Phase 4] b4 dig -a: v1 only
- [Phase 4] b4 dig -w: Belloni + linux-rtc + linux-kernel
- [Phase 4] b4 mbox: Belloni “Applied, thanks!”; Sashiko FLAG note pre-
existing, not a NAK
- [Phase 5] `rx8130_set_alarm` is `rtc_class_ops.set_alarm`; sysfs
`wakealarm` calls `rtc_set_alarm()`
- [Phase 6] git describe HEAD: p-6.12-3-gc504cf0baa3d8; kernelversion
6.12.111; line 665 still `&=`
- [Phase 6] `git apply --check` of 878d93aaa596: clean
- [Phase 8] Failure mode: RTC wakeup does not fire (or fires on wrong
weekdays); HIGH for RX8130 boards
- UNVERIFIED: live lore.kernel.org/stable HTML (HTTP 403); hardware
retest in this environment
**YES**
drivers/rtc/rtc-ds1307.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 9ba5958ca7a6e..d9a8e5045e37d 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -662,7 +662,7 @@ static int rx8130_set_alarm(struct device *dev, struct rtc_wkalrm *t)
if (ret < 0)
return ret;
- ctl[0] &= RX8130_REG_EXTENSION_WADA;
+ ctl[0] |= RX8130_REG_EXTENSION_WADA;
ctl[1] &= ~RX8130_REG_FLAG_AF;
ctl[2] &= ~RX8130_REG_CONTROL0_AIE;
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH AUTOSEL 6.18-5.10] rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode
2026-10-19 13:45 ` [PATCH AUTOSEL 6.18-5.10] rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode Sasha Levin
@ 2026-10-19 14:04 ` sashiko-bot
0 siblings, 0 replies; 6+ messages in thread
From: sashiko-bot @ 2026-10-19 14:04 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-rtc, Alexandre Belloni
> From: Robert Leussler <robert.leussler@leica-geosystems.com>
>
> [ Upstream commit 878d93aaa596a861dbc8d71f7c38e62a2e805f01 ]
>
> The RX8130 wakeup alarm never fired when set via
> /sys/class/rtc/rtc0/wakealarm. The root cause is that the WADA bit
> (bit 3) in the Extension register (0x1c) was never set before
> programming the alarm registers.
>
> Per the RX8130 datasheet:
> WADA=0 - Week alarm: register 0x19 is compared against day-of-week
> WADA=1 - Day alarm: register 0x19 is compared against day-of-month
>
> rx8130_set_alarm() always writes a BCD day-of-month value to alarm
> register 0x19, so WADA must be 1. With WADA=0 the hardware matched the
> day-of-month value (e.g. 15) as a day-of-week index, which is always
> out of range (valid weekdays are 0-6), so the alarm interrupt was never
> asserted.
>
> Fix by setting the WADA bit in rx8130_set_alarm() before writing the
> Extension register back to the device.
>
> This is consistent with rx8130_read_alarm(), which decodes the same
> register under the same assumption (24-hour and day-of-month mode).
>
> Signed-off-by: Robert Leussler <robert.leussler@leica-geosystems.com>
> Link: https://patch.msgid.link/20260721081907.3518648-1-robert.leussler@leica-geosystems.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.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-36-sashal@kernel.org?part=1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH AUTOSEL 6.18-5.10] rtc: brcmstb-waketimer: add missing MODULE_DEVICE_TABLE()
[not found] <20261019135441.1420968-1-sashal@kernel.org>
2026-10-19 13:45 ` [PATCH AUTOSEL 6.18-5.10] rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode Sasha Levin
@ 2026-10-19 13:51 ` Sasha Levin
2026-10-19 15:02 ` sashiko-bot
2026-10-19 13:51 ` [PATCH AUTOSEL 6.18-5.10] rtc: ab-eoz9: " Sasha Levin
2 siblings, 1 reply; 6+ messages in thread
From: Sasha Levin @ 2026-10-19 13:51 UTC (permalink / raw)
To: patches, stable
Cc: Pengpeng Hou, Alexandre Belloni, Sasha Levin, florian.fainelli,
linux-rtc, linux-arm-kernel, linux-kernel
From: Pengpeng Hou <pengpeng@iscas.ac.cn>
[ Upstream commit 402c89d28fecd28652a4bfe997f08f6544836381 ]
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260704121734.54941-1-pengpeng@iscas.ac.cn
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 local tree is **6.12.111** (`pending-6.12`). The one-line OF alias
publication is missing here, the match table is present, and the
original mailed hunk applies cleanly.
===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
Step 1.1: PARSE THE SUBJECT LINE
Record: **[rtc / brcmstb-waketimer] [add] [publish missing OF
MODULE_DEVICE_TABLE so the module can autoload]**
Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- **Link:**
https://patch.msgid.link/20260704121734.54941-1-pengpeng@iscas.ac.cn
- **Signed-off-by:** Pengpeng Hou (author)
- **Signed-off-by:** Alexandre Belloni (RTC maintainer; applied)
- **No Fixes:** (expected for this review)
- **No Cc: stable** (expected)
- **No Reported-by / Tested-by / Reviewed-by / Acked-by / syzbot**
- Pipeline markers (`[Upstream commit ...]`, Sasha Levin SOB) ignored
per instructions
Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- **Bug:** OF match table is wired to `.of_match_table` but not exported
with `MODULE_DEVICE_TABLE()`, so modpost never emits
`of:N*T*Cbrcm,brcmstb-waketimer` aliases.
- **Symptom:** When `CONFIG_RTC_DRV_BRCMSTB=m`, udev/kmod cannot
autoload `rtc-brcmstb-waketimer.ko` from the DT compatible string. The
wake-timer/RTC does not bind unless the module is loaded by hand.
- **Version info:** none in the message. Driver has been in tree since
v4.13.
- **Root cause (author):** missing module-alias publication, evidenced
by the driver-owned table and its use by the platform driver.
Explicitly a source-level finding, not a live hardware repro.
Step 1.4: DETECT HIDDEN BUG FIXES
Record: **Not disguised.** It is a real autoload bug, same class as
adding/publishing a device ID. Not style-only.
===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================
Step 2.1: INVENTORY THE CHANGES
Record:
- **File:** `drivers/rtc/rtc-brcmstb-waketimer.c` (+1 / −0)
- **Function/site:** after `brcmstb_waketmr_of_match[]` (not inside a
function)
- **Scope:** single-file, one-line surgical change
- **Upstream SHA (verified):**
`402c89d28fecd28652a4bfe997f08f6544836381`
Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- **Before:** table exists and is assigned to `.of_match_table` via
`of_match_ptr()`. Built-in matching still works. Modular autoload does
not, because file2alias never sees the table.
- **After:** `MODULE_DEVICE_TABLE(of, brcmstb_waketmr_of_match)` creates
`__mod_of__brcmstb_waketmr_of_match_device_table` as an alias when
`MODULE` is set (`include/linux/module.h`). `scripts/mod/file2alias.c`
`do_of_entry_multi()` then emits `MODULE_ALIAS("of:N*T*Cbrcm,brcmstb-
waketimer")`.
- **Path affected:** module install / depmod / udev autoload only.
Probe, PM, and built-in bind paths are unchanged. When `!MODULE`, the
macro is empty.
Step 2.3: IDENTIFY THE BUG MECHANISM
Record: **[Hardware enablement / missing device ID publication]**
- Category (h): OF alias not published, so modular bind fails.
- Not UAF, leak, race, NULL deref, or crash.
Step 2.4: ASSESS THE FIX QUALITY
Record:
- **Quality:** obviously correct; this is the standard pattern (dozens
of RTC drivers already have `MODULE_DEVICE_TABLE(of, ...)` in this
tree).
- **Regression risk:** very low. Compile-time alias only.
`__maybe_unused` on the table remains valid: built-in + `!CONFIG_OF`
still has no C reference; as a module the alias references the table,
which is intended.
- **No API, locking, or data-structure changes.**
===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
Step 3.1: BLAME THE CHANGED LINES
Record:
- Match table and `.of_match_table` introduced in **`c4f07ecee22ec7`**
(“rtc: brcmstb-waketimer: Add Broadcom STB wake-timer”, Brian Norris,
2017) — first appears **v4.13-rc1**. Present in this tree (`git merge-
base --is-ancestor` succeeded).
- `__maybe_unused` added in **`ae1247f79ddf8`** (v5.12 era) for
`!CONFIG_OF` compile-test. That did not add `MODULE_DEVICE_TABLE`.
- Bug has been present for the entire life of the driver.
Step 3.2: FOLLOW THE FIXES: TAG
Record: **No Fixes: tag.** The introducing commit is `c4f07ecee22ec7`,
which is in this tree. No later intermediate autoload fix on this file.
Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record (this tree, path-limited):
- `e005a9b35b464` level alarm_irq
- `d64906b320ce6` `.remove` → `.remove_new`
- `24304a87158aa` non-wake alarm
- None of these publish OF aliases.
- **Standalone** one-line patch; not “X/Y” of a series that this file
depends on. Parent of upstream `402c89d28fec` is a sibling RTC
autoload fix (`rtc: s32g`), not a prerequisite for this driver.
Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Pengpeng Hou is not the RTC maintainer. In this tree the only
other `drivers/rtc/` commit from that author is unrelated (`rtc: zynqmp:
Return optional clock lookup errors`). Alexandre Belloni (RTC
maintainer) applied the patch. Florian Fainelli / Broadcom were on
To/Cc.
Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: **None.** Needs only `MODULE_DEVICE_TABLE` and the existing
`of_device_id` table, both present since the driver was added. **Can
apply standalone.**
===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================
Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- **b4 dig -c 402c89d28fec:**
https://patch.msgid.link/20260704121734.54941-1-pengpeng@iscas.ac.cn
- **b4 dig -a:** single **v1**, 2026-07-04; no v2/v3.
- Thread (3 messages): original patch; Sashiko bot “no issues”;
Alexandre Belloni **“Applied, thanks!”** pointing at
`https://git.kernel.org/abelloni/c/402c89d28fec`.
- **No NAK, no stable nomination, no reviewer risk flags.** WebFetch to
lore returned 403; thread recovered via `b4 mbox`.
Step 4.2: CHECK WHO REVIEWED THE PATCH
Record (b4 dig -w): To/Cc included Alexandre Belloni (RTC maintainer),
Florian Fainelli, bcm-kernel-feedback-list, linux-rtc, linux-arm-kernel,
linux-kernel. Maintainer applied it. No human Reviewed-by.
Step 4.3: SEARCH FOR THE BUG REPORT
Record: **No user/syzbot/bugzilla report.** Author states it is source-
level. Severity from reporters: N/A. Users affected: anyone building
this driver as a module on DT platforms with `brcm,brcmstb-waketimer`.
Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Wave of the same one-line OF-alias pattern. This 6.12 tree
already contains:
- `330fdd1fb7d09` drm/tve200: add OF module alias for autoloading
- `2260191fbf7c6` crypto: keembay - publish OF module alias for OCS
AES/SM4
Those are the same bug class, already accepted here. This brcmstb patch
does not depend on them.
Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: lore.kernel.org/stable search via WebFetch returned 403.
**UNVERIFIED** whether this exact patch was discussed on stable@. No
local evidence it was rejected.
===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: **No function body changed.** Site is `brcmstb_waketmr_of_match`
/ `brcmstb_waketmr_driver`. Related runtime function:
`brcmstb_waketmr_probe`.
Step 5.2: TRACE CALLERS
Record: `brcmstb_waketmr_probe` is only referenced as `.probe` on
`brcmstb_waketmr_driver`, registered via `module_platform_driver()`.
Called from platform/OF device bind (kernel boot or module load), not
from a syscall directly. Userspace trigger is: DT node present + module
autoload (or manual `modprobe`).
Step 5.3: TRACE CALLEES
Record: Probe ioremaps, allocates an RTC device, requests IRQs,
`device_init_wakeup()`. The new line calls nothing at runtime.
Step 5.4: FOLLOW THE CALL CHAIN
Record: DT `compatible = "brcm,brcmstb-waketimer"` (in-tree on several
BMIPS boards, e.g. `arch/mips/boot/dts/brcm/bcm7435.dtsi`) → OF match →
probe. **Reachable on real STB hardware.** Autoload is the broken hop
when `=m`.
Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Many RTC drivers already export OF tables (`rtc-zynqmp.c`, `rtc-
mt7622.c`, …). Historical RTC fixes of the same kind: `206e04ec7539e`
(mxc_v2), `3fc990a5dbfff` (mt7622). Systematic missing-alias class, not
a one-off.
===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================
Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: **Yes.** `drivers/rtc/rtc-brcmstb-waketimer.c:413-424` has the
table and `.of_match_table` and **no** `MODULE_DEVICE_TABLE`. `git
merge-base --is-ancestor 402c89d28fec HEAD` failed (fix not here).
Introduced v4.13, long before 6.12.
Kconfig in this tree (`drivers/rtc/Kconfig`):
```
config RTC_DRV_BRCMSTB
tristate "Broadcom STB wake-timer"
depends on ARCH_BRCMSTB || BMIPS_GENERIC || COMPILE_TEST
default ARCH_BRCMSTB || BMIPS_GENERIC
```
Explicitly modular. Default `y` on the SoCs that have the IP, so the
common defconfig path is built-in; `=m` is still a supported and
documented config.
Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: **Clean apply.** Original mailed hunk (3 lines of context
through `.probe`) — `git apply --check` **rc 0** on this tree. `.remove`
vs `.remove_new` is later in the struct and is not in the original hunk.
No rework needed.
Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: **No** commit on this file adds `MODULE_DEVICE_TABLE`. Sibling
OF-alias backports exist for other drivers (tve200, keembay), not a
substitute for this one.
===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================
Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: **[drivers/rtc — Broadcom STB wake-timer] [PERIPHERAL]** for
most 6.12 users; **IMPORTANT** on BCM7xxx set-top boxes (alarm/S2/S3/S5
wake). Not mm/net/block core.
Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Driver is mature (2017). Recent local commits are PM/IRQ and
platform-remove conversion, not a rewrite. Low churn around the match
table.
===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
Step 8.1: DETERMINE WHO IS AFFECTED
Record: **Driver-specific / config-specific.** Users of Broadcom STB
wake-timer with `CONFIG_RTC_DRV_BRCMSTB=m`. In-tree DT nodes are on
BMIPS boards (`bcm7346/7358/7360/7362/7425/7435`). `ARCH_BRCMSTB` also
exists on ARM and arm64; this tree’s ARM/arm64 dtsi files do not contain
the compatible string (vendor DTs may). Built-in (`=y`, the Kconfig
default on those arches) is unaffected.
Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record:
- Trigger: modular driver + OF device present + reliance on autoload
(normal distro/udev path).
- Commonness: uncommon vs default `=y`; real whenever someone chooses
`=m` (help text documents that).
- Unprivileged userspace cannot exploit this; it is bind/enablement, not
a crash primitive.
Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: **[RTC/wake-timer never binds when built as a module] [MEDIUM]**
- Not oops/deadlock/corruption/CVE.
- On affected boxes, RTC alarm and suspend wake from this block can fail
to be available until a manual `modprobe`.
- Fits stable-rules “device ID” / “oh, that’s not good” more than
“oops”.
Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- **Benefit:** medium for modular STB configs (hardware actually gets
its driver); low for default `=y` defconfigs.
- **Risk:** very low (1 line, modpost alias, no runtime behavior change
for built-in).
- **Ratio:** favorable. Same class already merged in this 6.12.y tree.
===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================
Step 9.1: COMPILE THE EVIDENCE
**FOR:**
- Real autoload bug: OF table used, aliases never generated.
- One line, obviously correct, maintainer-applied.
- Driver and buggy code exist in 6.12.111 since v4.13.
- Original patch applies cleanly here.
- Device-ID / hardware-enablement exception; wake-timer matters for STB
suspend/resume.
- Identical OF-alias one-liners already in this tree (tve200, keembay).
- Zero runtime regression path for the default built-in config.
**AGAINST:**
- Not a crash, UAF, deadlock, or security hole.
- No user report; source-level scan.
- Kconfig default is built-in on the SoCs that have the hardware, so
many production images never hit autoload.
- Peripheral driver, not core.
**UNRESOLVED:**
- Whether this SHA was already discussed on stable@ (lore 403).
- Whether vendor ARM/arm64 brcmstb DTs (not in this tree) also use this
compatible.
Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — standard macro; RTC
maintainer applied v1 with no objections.
2. Fixes a real bug that affects users? **PASS** — modular OF autoload
does not work; Kconfig allows `=m`.
3. Important issue? **PASS** (device-ID / hardware-enablement class;
functional miss for modular STB RTC/wake). Severity MEDIUM, not
CRITICAL.
4. Small and contained? **PASS** — +1 line, one file.
5. No new features or APIs? **PASS** — publishes an alias for an
existing match table.
6. Can apply to the local tree? **PASS** — `git apply --check`
succeeded; code present; no missing prereqs.
Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: **Device ID / OF module alias publication for an existing
driver** (stable-rules: “or just add a device ID”). Closest match to the
documented ID-addition exception.
Step 9.4: MAKE YOUR DECISION
Backport. The bug is in this tree, the fix is the usual one-line alias
export, it applies cleanly, and it matches both the written device-ID
exception and OF-alias fixes already on 6.12.y. Default-y only reduces
how often it bites; it does not make the modular path fictional.
------------------------------------------------
What the commit solves for this tree
The 6.12 `rtc-brcmstb-waketimer` driver matches `brcm,brcmstb-waketimer`
but never asks modpost to emit that alias. Built as a module, the wake-
timer will not autoload. Adding `MODULE_DEVICE_TABLE(of, ...)` is the
complete fix.
Risk vs benefit
Benefit is restoring bind on modular STB configs; risk is essentially
nil. Context around `.remove_new` does not affect the original hunk.
------------------------------------------------
Verification:
- [Phase 1] Parsed tags: Link to msgid, SOB Pengpeng Hou + Alexandre
Belloni; no Fixes/Cc stable/Reported-by
- [Phase 1] Body: missing OF alias; source-level, no hardware repro
claimed
- [Phase 2] Diff: +1 line `MODULE_DEVICE_TABLE(of,
brcmstb_waketmr_of_match)` after the match table
- [Phase 2] `include/linux/module.h`: macro is alias-for-modpost if
`MODULE`, empty otherwise
- [Phase 2] `scripts/mod/file2alias.c` `do_of_entry_multi()`: emits
`of:N*T*C<compatible>`
- [Phase 3] `git blame`: table from `c4f07ecee22ec7` (v4.13-rc1);
`__maybe_unused` from `ae1247f79ddf8`
- [Phase 3] `git merge-base --is-ancestor c4f07ecee22ec HEAD`: intro
commit is in this tree
- [Phase 3] `git merge-base --is-ancestor 402c89d28fec HEAD`: fix is
**not** in this tree
- [Phase 3] `git show 402c89d28fec`: confirmed same +1 line,
author/date/message
- [Phase 3] `git log --oneline -20 -- drivers/rtc/rtc-brcmstb-
waketimer.c`: no prior MODULE_DEVICE_TABLE on this file
- [Phase 4] `b4 dig -c 402c89d28fec`: lore URL + v1-only series
- [Phase 4] `b4 dig -a`: only v1, 2026-07-04
- [Phase 4] `b4 dig -w`: Belloni, Fainelli, bcm-kernel-feedback-list,
linux-rtc CC’d
- [Phase 4] `b4 mbox`: Belloni “Applied, thanks!”; Sashiko no issues; no
NAK
- [Phase 4] WebFetch lore: 403; used b4 instead
- [Phase 4] UNVERIFIED: stable@ thread for this exact subject
- [Phase 5] Probe only used as platform `.probe`; DT compatible present
in `arch/mips/boot/dts/brcm/*.dtsi`
- [Phase 6] `make kernelversion` / Makefile: **6.12.111**; `git describe
HEAD`: p-6.12-3-gc504cf0baa3d8
- [Phase 6] Local file lines 413–424: table present, MODULE_DEVICE_TABLE
absent
- [Phase 6] `git apply --check` of original hunk: **success (rc 0)**
- [Phase 6] Same-class already in tree: `330fdd1fb7d09`, `2260191fbf7c6`
- [Phase 7] MAINTAINERS: RTC subsystem maintained by Alexandre Belloni
- [Phase 8] Kconfig tristate + `default y` on ARCH_BRCMSTB/BMIPS_GENERIC
verified via blame
- [Phase 8] Failure mode: missing modular bind, not a crash
**YES**
drivers/rtc/rtc-brcmstb-waketimer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-brcmstb-waketimer.c b/drivers/rtc/rtc-brcmstb-waketimer.c
index fb47c32ab5ff4..55c15aad42cff 100644
--- a/drivers/rtc/rtc-brcmstb-waketimer.c
+++ b/drivers/rtc/rtc-brcmstb-waketimer.c
@@ -413,6 +413,7 @@ static const __maybe_unused struct of_device_id brcmstb_waketmr_of_match[] = {
{ .compatible = "brcm,brcmstb-waketimer" },
{ /* sentinel */ },
};
+MODULE_DEVICE_TABLE(of, brcmstb_waketmr_of_match);
static struct platform_driver brcmstb_waketmr_driver = {
.probe = brcmstb_waketmr_probe,
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH AUTOSEL 6.18-5.10] rtc: ab-eoz9: add missing MODULE_DEVICE_TABLE()
[not found] <20261019135441.1420968-1-sashal@kernel.org>
2026-10-19 13:45 ` [PATCH AUTOSEL 6.18-5.10] rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode Sasha Levin
2026-10-19 13:51 ` [PATCH AUTOSEL 6.18-5.10] rtc: brcmstb-waketimer: add missing MODULE_DEVICE_TABLE() Sasha Levin
@ 2026-10-19 13:51 ` Sasha Levin
2026-10-19 15:04 ` sashiko-bot
2 siblings, 1 reply; 6+ messages in thread
From: Sasha Levin @ 2026-10-19 13:51 UTC (permalink / raw)
To: patches, stable
Cc: Pengpeng Hou, Alexandre Belloni, Sasha Levin, linux-rtc,
linux-kernel
From: Pengpeng Hou <pengpeng@iscas.ac.cn>
[ Upstream commit 7490b8356e52e09c196645912f2c054f79aa5f3a ]
The driver has a match table for the i2c bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260704152528.53258-1-pengpeng@iscas.ac.cn
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
This is a one-line `MODULE_DEVICE_TABLE(i2c, ...)` addition on a driver
that already exists in this 6.12 tree. The I2C ID table is wired up but
never exported, so i2c-style module autoload is broken.
===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
Step 1.1: PARSE THE SUBJECT LINE
Record: [rtc: ab-eoz9] [add] [export the existing I2C match table via
MODULE_DEVICE_TABLE so aliases are generated for autoload]
Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> (author)
- Link:
https://patch.msgid.link/20260704152528.53258-1-pengpeng@iscas.ac.cn
- Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (RTC
maintainer)
- No Fixes: tag (expected for this review queue)
- No Cc: stable (expected)
- No Reported-by / Tested-by / Reviewed-by / Acked-by
- Ignore pipeline SOBs if present
Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: `abeoz9_id[]` is used as `id_table` but never published with
`MODULE_DEVICE_TABLE(i2c, ...)`, so file2alias does not emit
`i2c:abeoz9` aliases.
- Symptom: when `RTC_DRV_ABEOZ9=m`, udev/modprobe will not autoload the
module for a non-DT I2C instantiation (`new_device`, board info,
etc.).
- Failure mode: driver stays unloaded; RTC does not appear until a
manual `modprobe rtc-ab-eoz9`.
- Version info: none in the message.
- Root cause: missing alias publication, not a match-table or probe-
logic error.
- Author explicitly calls this a source-level fix with no dynamic
hardware repro.
Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not hidden. It is a missing-autoload bug. The “source-level”
wording does not change that `MODULE_DEVICE_TABLE` is the documented way
I2C drivers publish aliases (`Documentation/i2c/writing-clients.rst`).
===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================
Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/rtc/rtc-ab-eoz9.c` (+1 / -0)
- One line after `abeoz9_id[]`: `MODULE_DEVICE_TABLE(i2c, abeoz9_id);`
- No functions changed; table/registration data only
- Scope: single-file surgical fix
Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Before: OF table already has `MODULE_DEVICE_TABLE(of,
abeoz9_dt_match)`. I2C table exists and is assigned to `.id_table` but
is not exported.
- After: I2C table is also exported. Built-in builds are unchanged
(`MODULE_DEVICE_TABLE` is empty when `!MODULE` in
`include/linux/module.h`).
- Path affected: module-alias generation at build time, not
probe/runtime.
Step 2.3: IDENTIFY THE BUG MECHANISM
Record:
- Category: hardware enablement / missing device-ID alias (same class as
adding IDs)
- Mechanism: without the export, `i2c:abeoz9` never appears in module
info. `i2c_device_uevent()` uses `MODALIAS=i2c:<name>` when OF/ACPI
modalias is unavailable (`drivers/i2c/i2c-core-base.c`). Autoload then
fails.
Step 2.4: ASSESS THE FIX QUALITY
Record:
- Obviously correct: one standard macro, same pattern as `rtc-
ab-b5ze-s3.c` and most other I2C RTC drivers.
- Minimal: one line, no unrelated edits.
- Regression risk: very low. No locking, no probe/remove change, no ABI.
Built-in is a no-op.
===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
Step 3.1: BLAME THE CHANGED LINES
Record:
- Driver added in `67075b63cce26` (“rtc: add AB-RTCMC-32.768kHz-EOZ9 RTC
support”, Artem Panfilov, 2019-02-17).
- Present in v5.2. OF `MODULE_DEVICE_TABLE` was there from day one; I2C
export was never added.
- `abeoz9_id` line `{ "abeoz9" }` last touched by `a47d377e22c4a` (drop
explicit `driver_data = 0`).
Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. Buggy pattern dates to the introducing commit
`67075b63cce26`, which is an ancestor of this HEAD.
Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record:
- Recent file history is unrelated (temperature/undervoltage, probe
style, IRQ flags).
- Not part of a numbered series. Standalone one-liner.
- Sibling Abracon driver `rtc-ab-b5ze-s3.c` already has both OF and I2C
`MODULE_DEVICE_TABLE`.
Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record:
- Pengpeng Hou is not the RTC maintainer. Same-day pattern: `can:
ctucanfd: add missing MODULE_DEVICE_TABLE()` is already in this tree
as `877e99535dfb9` (upstream `d937bdb244a7`, with Cc: stable).
- RTC maintainer Alexandre Belloni applied the rtc patch (SOB +
“Applied, thanks!”).
Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: None. Uses existing `abeoz9_id` and the existing
`MODULE_DEVICE_TABLE` macro. Standalone.
===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================
Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- lore fetch via WebFetch returned 403; retrieved with `b4 mbox` msgid
`20260704152528.53258-1-pengpeng@iscas.ac.cn`.
- Thread: original patch + Sashiko bot “no issues” + Alexandre Belloni
apply mail.
- Single revision (PATCH, not v2/v3). Applied as `7490b8356e52` in the
RTC tree.
- Submitted context uses `{ "abeoz9" }`, which matches this 6.12 file
(the candidate blob with `{ .name = "abeoz9" }` is a later-mainline
context difference only).
- No NAK. No reviewer-requested Cc: stable.
Step 4.2: CHECK WHO REVIEWED THE PATCH
Record: To: Alexandre Belloni; Cc: linux-rtc, linux-kernel. Maintainer
applied it. No other human review comments.
Step 4.3: SEARCH FOR THE BUG REPORT
Record: No user/syzbot/bugzilla report. Author states source-level
evidence only. No in-tree `.dts` user of `abracon,abeoz9` besides
`trivial-rtc.yaml`.
Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Batch of missing-`MODULE_DEVICE_TABLE` scans the same day (at
least CAN PCI + this RTC). CAN one already backported here. This RTC
patch is self-contained.
Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: No stable-list discussion found for this subject. Absence is
expected; that is why it is in this review queue.
===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: No functions modified. Data: `abeoz9_id[]`. Consumers:
`abeoz9_driver.id_table`. Macro: `MODULE_DEVICE_TABLE`.
Step 5.2: TRACE CALLERS
Record:
- `abeoz9_probe` is only referenced from `abeoz9_driver.probe`.
- I2C core calls it on match. Autoload is the gap before probe.
- `i2c_device_uevent()`: OF alias if of_node, else ACPI, else `i2c:` +
`client->name`.
Step 5.3: TRACE CALLEES
Record: The new line does not call anything at runtime. file2alias
consumes `__mod_i2c__abeoz9_id_device_table`.
Step 5.4: FOLLOW THE CALL CHAIN
Record:
- Userspace-reachable: instantiating `abeoz9` on an I2C adapter (sysfs
`new_device`, board info) with the driver as a module.
- DT path already autoloads via existing OF table.
- `!CONFIG_OF` / no of_node: I2C alias is the only autoload path, and it
is missing.
- Driver does not require DT to probe (`abeoz9_trickle_parse_dt` returns
0 if the property is absent).
Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Most I2C RTC drivers already have `MODULE_DEVICE_TABLE(i2c,
...)`. This driver is the incomplete sibling of `rtc-ab-b5ze-s3`. Same-
day CAN PCI fix already landed in this tree.
===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================
Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record:
- Tree: `p-6.12-3-gc504cf0baa3d8`, `make kernelversion` = 6.12.111
(VERSION 6 / PATCHLEVEL 12 / SUBLEVEL 111).
- File present. `MODULE_DEVICE_TABLE(of, ...)` at line 567; `abeoz9_id`
at 570–573; no `MODULE_DEVICE_TABLE(i2c, ...)`.
- `7490b8356e52` is not an ancestor of HEAD (`git merge-base --is-
ancestor` exit 1).
- Bug present since v5.2.
Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: Original mailed patch context is `{ "abeoz9" }`, which is
exactly this tree. Clean apply. No refactor blocking it.
Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: No equivalent fix on `rtc-ab-eoz9.c`. OF alias only.
===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================
Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: `drivers/rtc/` I2C RTC. Criticality: PERIPHERAL / driver-
specific. RTC still matters for wall-clock and wake on boards that use
this Abracon part.
Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: RTC is mature and still getting stable-worthy fixes in this
tree. This file itself is low-churn.
===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
Step 8.1: DETERMINE WHO IS AFFECTED
Record: Users of Abracon AB-RTCMC-32.768kHz-EOZ9 with
`RTC_DRV_ABEOZ9=m`. DT boards already autoload. Affected: non-DT I2C
instantiation, or any path that emits `i2c:abeoz9` rather than the OF
modalias. Config-specific (`=m` only).
Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record:
- Trigger: I2C client named `abeoz9` appears while the driver is a
module and no OF/ACPI modalias is used.
- Not every boot on DT systems.
- Unprivileged users cannot typically create I2C clients; this is not a
security trigger.
Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record:
- Failure: module not loaded; RTC absent until manual modprobe. No oops,
UAF, or corruption.
- Severity: MEDIUM for affected hardware (device does not work
automatically). LOW globally (niche chip, DT already covered).
- Still a real user-visible bug, same class as missing device IDs.
Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: medium-low population, high for anyone on the broken autoload
path; restores hardware probe without manual load.
- Risk: very low (one line, no runtime code).
- Ratio: favorable. Same class already accepted here for ctucanfd.
===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================
Step 9.1: COMPILE THE EVIDENCE
FOR:
- Real autoload bug: I2C ID table is used but not exported.
- One line, obviously correct, maintainer-applied.
- Driver and bug have been in this 6.12 tree since the v5.2
introduction.
- Original patch applies cleanly here.
- Zero runtime change for built-in; aliases only when `=m`.
- Stable rules allow device-ID additions; this publishes an existing ID.
- Sibling Abracon RTC already has the I2C export.
- Same-day CAN `MODULE_DEVICE_TABLE` fix is already in this tree.
AGAINST:
- No user report or syzbot; author says source-level only.
- Not a crash/security/deadlock.
- DT autoload already works; chip is mainly DT/embedded.
- No in-tree board DTS users of `abracon,abeoz9`.
UNRESOLVED:
- Could not fetch lore.kernel.org via WebFetch (403); thread recovered
via `b4 mbox`.
- No stable-list thread found.
Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? PASS — one standard macro; maintainer
applied; matches documented I2C driver pattern.
2. Fixes a real bug that affects users? PASS — missing `i2c:abeoz9`
alias; module does not autoload on the I2C path.
3. Important issue? PASS under the device-ID / hardware-enablement
exception. User-visible: RTC module does not load. Not a panic.
4. Small and contained? PASS — +1 line, one file.
5. No new features or APIs? PASS — existing table, existing macro.
6. Can apply to the local tree? PASS — buggy code present; mailed
context matches 6.12.
Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: Device ID / module-alias publication for an existing driver. Not
a new driver, API, or module parameter.
Step 9.4: MAKE YOUR DECISION
YES. The bug exists in this 6.12.111 tree, the fix is a one-line alias
export with no runtime risk, and it is the same class of hardware-
enablement stable already takes (including this author’s CAN patch
already on this branch).
What the commit solves for stable users: if `rtc-ab-eoz9` is built as a
module, I2C instantiation that emits `i2c:abeoz9` (non-DT) never
autoloads the driver. DT boards already work via the OF table. The extra
line closes the I2C alias gap.
Risk vs benefit: benefit is autoload for this RTC on the I2C path; risk
is essentially nil. No prerequisites. Original mailed hunk matches this
tree’s `{ "abeoz9" }` initializer.
Verification:
- [Phase 1] Parsed tags: author SOB Pengpeng Hou; Link msgid; RTC
maintainer SOB Alexandre Belloni; no Fixes/Cc:stable/Reported-by
- [Phase 1] Body: missing I2C MODULE_DEVICE_TABLE; source-level, no
hardware repro claimed
- [Phase 2] Diff: +1 line `MODULE_DEVICE_TABLE(i2c, abeoz9_id)` after
`abeoz9_id[]` in `drivers/rtc/rtc-ab-eoz9.c`
- [Phase 2] `include/linux/module.h`: macro is alias-only when `MODULE`,
empty when built-in
- [Phase 3] blame: table from `67075b63cce26` (2019); OF export present
then; I2C export never added
- [Phase 3] `git merge-base --is-ancestor 67075b63cce26 HEAD`:
introducing commit is in this tree; in v5.2
- [Phase 3] `git log --oneline --grep='MODULE_DEVICE_TABLE' --
drivers/rtc/rtc-ab-eoz9.c`: empty (fix not here)
- [Phase 3] Same-author `877e99535dfb9` can/ctucanfd MODULE_DEVICE_TABLE
already in this tree
- [Phase 4] `b4 mbox` msgid
`20260704152528.53258-1-pengpeng@iscas.ac.cn`: 3 messages; maintainer
applied as `7490b8356e52`; mailed hunk uses `{ "abeoz9" }`
- [Phase 4] WebFetch lore/msgid.link: 403; discussion recovered from
mbox and openwall/lkml mirrors
- [Phase 5] `i2c_device_uevent`: OF first, then ACPI, then
`MODALIAS=i2c:` + client name
- [Phase 5] grep: `abeoz9_probe` only from this driver; no in-tree DTS
users besides `trivial-rtc.yaml`
- [Phase 5] `rtc-ab-b5ze-s3.c` already has both OF and I2C
MODULE_DEVICE_TABLE
- [Phase 6] `git describe HEAD`: `p-6.12-3-gc504cf0baa3d8`; `make
kernelversion`: 6.12.111
- [Phase 6] Local file lines 562–582: OF table exported; I2C table not;
`{ "abeoz9" }`
- [Phase 6] `git merge-base --is-ancestor 7490b8356e52 HEAD`: exit 1
(not in this tree)
- [Phase 7] Kconfig `RTC_DRV_ABEOZ9` is tristate; not set in defconfigs
searched
- [Phase 8] Failure mode: missing module autoload for I2C path, severity
MEDIUM for that hardware, not a crash
- UNVERIFIED: live lore.kernel.org HTML (403); no stable-list hit for
this subject
**YES**
drivers/rtc/rtc-ab-eoz9.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-ab-eoz9.c b/drivers/rtc/rtc-ab-eoz9.c
index de002f7a39bf4..8dc656bb78bfb 100644
--- a/drivers/rtc/rtc-ab-eoz9.c
+++ b/drivers/rtc/rtc-ab-eoz9.c
@@ -549,6 +549,7 @@ static const struct i2c_device_id abeoz9_id[] = {
{ "abeoz9" },
{ }
};
+MODULE_DEVICE_TABLE(i2c, abeoz9_id);
static struct i2c_driver abeoz9_driver = {
.driver = {
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread