[openipc-ai]

On a hi3516ev300 camera whose CR927 backup cell had gone flat, a power cut of about 5 minutes brought the clock back at 1970:

hibvt_rtc 120e0000.rtc: setting system clock to 1970-01-01 00:00:06 UTC (6)

The counter restarts from zero when it loses every supply. The driver returns it as a real time, and hctosys applies it. A warm reboot keeps the time, so nothing in U-Boot or the driver resets the RTC.

Change

• read_time() returns -EINVAL for a counter before 2000-01-01, so hctosys leaves the clock alone. set_time() refuses the same range, so every time it accepts can be read back (Qodo's review point).
• The low-voltage flag (RTC_INT_RAW bit 1) is cleared with LV_INT_MASK. The driver wrote 1 to RTC_INT_CLR, which is AIE_INT_MASK, so the flag never cleared and a pending alarm interrupt was acknowledged instead.

The low-voltage flag is not used to judge the time, or reported. The first revision of this PR printed a "backup supply low" warning from it. The flag turned out not to mean that. On this board it stays set, and returns about 0.5 s after each clear, both with the flat cell and with a fresh CR927 that keeps the time through a 5-minute power cut. So the vendor's commented-out date/time is not reliable message stays out, and the counter decides.

OpenIPC's fake-hwclock already handles an unreadable RTC: it restores its checkpoint, and NTP corrects the clock.

Ports: #80 (hisilicon-hi3516cv500, same code) and #81 (hisilicon-hi3536dv100, which still had the vendor's return -EINVAL on the flag).

Verification

Board: hi3516ev300, hi3516ev300_ultimate_rostelecom-ipc8232swc-we, USB powered through a switchable relay. I built the kernel with this driver from the same build tree as the camera's shipped fitImage, with only rtc-hibvt.c changed; the DTB is identical. U-Boot loaded it through an extra bootcmd step, so the shipped kernel was never touched. The camera is back on its own kernel and bootcmd.

Fresh cell, warm reboot. The time is applied, with no message about the flag:

Linux version 4.9.37 (ai@rtc-test-v2) (buildroot-gcc-13.3.0) #3 Tue Oct 20 11:11:00 UTC 2026
hibvt_rtc 120e0000.rtc: rtc core: registered 120e0000.rtc as rtc0
hibvt_rtc 120e0000.rtc: RTC driver for hibvt enabled
hibvt_rtc 120e0000.rtc: setting system clock to 2026-10-20 11:12:20 UTC (1792494740)

Fresh cell, 60 s power cut. The cut started at 11:12:37 and the camera stopped answering ping during it. Power returned at 11:13:39:

hibvt_rtc 120e0000.rtc: setting system clock to 2026-10-20 11:13:44 UTC (1792494824)

Counter that lost its time. I zeroed the counter through the RTC load registers and ran reboot -f, so no shutdown script could write the time back. The counter is refused, and the clock is not stepped to 1970:

counter now: cat: read error: Invalid argument        # /sys/class/rtc/rtc0/since_epoch
hibvt_rtc 120e0000.rtc: hctosys: unable to read the hardware clock
fake-hwclock: clock restored to 2026-10-20 11:13:59 UTC

The same boot path with the flat cell, on the first revision of this change, gave hctosys: unable to read the hardware clock after a real ~1-minute power cut, where the shipped kernel had given setting system clock to 1970-01-01 00:00:06 UTC.

set_time() and read_time() agree:

hwclock: RTC_SET_TIME: Invalid argument      # system clock 1999-12-31 23:59:59, hwclock -w
rtc still 2026-10-20 11:14:10                 # RTC untouched
hwclock -w (2000-01-01 00:00:00) rc=0
Sat Jan  1 00:00:00 2000  0.000000 seconds    # hwclock -r reads it back

With the shipped driver and the fresh cell, a 5-minute power cut booted with setting system clock to 2026-10-20 11:05:41 UTC, about 7 s after power returned. The cell was the cause of the 1970 clock, and this change keeps that working.

[openipc-ai]

/review

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Users cannot read dates they set before 2000 ✓ Resolved

Description

hibvt_rtc_read_time() returns -EINVAL for dates before 2000, although hibvt_rtc_set_time()
accepts and stores them. Setting a valid date such as 1999-12-31 succeeds, but subsequent clock
reads fail, including the read used for boot-time clock synchronization.

Code

drivers/rtc/rtc-hibvt.c[R273-274]

+	if (seconds < RTC_MIN_VALID_SEC)
+		return -EINVAL;

Evidence

The RTC core accepts dates from 1970 onward; this driver's set path converts an accepted date to a
day count and writes it. Its new read path reconstructs that count but rejects every value before
2000, and hctosys aborts on the resulting read error.

drivers/rtc/rtc-lib.c[99-110]
drivers/rtc/rtc-hibvt.c[285-294]
drivers/rtc/rtc-hibvt.c[266-277]
drivers/rtc/hctosys.c[35-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new read-time cutoff rejects valid pre-2000 dates that the RTC driver accepts through set-time, so a successfully written date cannot be read back.
## Fix Focus Areas
- drivers/rtc/rtc-hibvt.c[117-121]
- drivers/rtc/rtc-hibvt.c[269-275]
- drivers/rtc/rtc-hibvt.c[285-294]
## Recommended Fix
Make read and write behavior consistent while still rejecting a counter that restarted from zero. Use a reset-counter criterion that does not reject supported dates, or explicitly enforce the same supported date range when setting the RTC.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can open the rule or relationship behind a finding in one click

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[openipc-ai]

/review

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit b2c076e