Re: [PATCH 6/6] rtc: rzn1: add R-Car X5H support
From: sashiko-bot@kernel.org
Date: 2026-09-14 21:28:30
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: New issues: - [High] rzn1_rtc_probe() dynamically modifies the static global rzn1_rtc_ops struct, which causes state corruption if the driver is unbound and rebound or if multiple device instances exist. Pre-existing issues: - [High] rzn1_rtc_set_offset() fails to clear the hardware offset when the requested offset is 0, leaving the previous offset stuck in hardware. -- commit c04fb139b5ae435fea49907420111efaa4083c83 Author: Wolfram Sang [off-list ref] rtc: rzn1: add R-Car X5H support This commit adds the compatible string for the Renesas R-Car X5H RTC to the rzn1 driver.
quoted hunk ↗ jump to hunk
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c index 583ce12b052d9..5860ecef428a6 100644 --- a/drivers/rtc/rtc-rzn1.c +++ b/drivers/rtc/rtc-rzn1.c@@ -527,6 +527,7 @@ static const struct rzn1_rtc_data rzn1_rtc_rzn1_data = { static const struct of_device_id rzn1_rtc_of_match[] = { { .compatible = "renesas,r9a09g077-rtc", .data = &rzn1_rtc_rzt2h_data }, + { .compatible = "renesas,rcar-gen5-rtc", .data = &rzn1_rtc_rzt2h_data },
[Severity: High]
Does dynamically modifying the static global rzn1_rtc_ops struct in
rzn1_rtc_probe() cause a regression where state is corrupted if multiple
device instances exist or if the driver is unbound and rebound?
If a device with alarms is probed, the global struct is modified:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_probe() {
...
if (irq >= 0) {
...
rzn1_rtc_ops.read_alarm = rzn1_rtc_read_alarm;
rzn1_rtc_ops.set_alarm = rzn1_rtc_set_alarm;
rzn1_rtc_ops.alarm_irq_enable = rzn1_rtc_alarm_irq_enable;
}
...
}
If the driver is subsequently bound to a device without alarms (like R-Car
X5H, as introduced by this patch), the global struct incorrectly retains
the alarm callbacks. The RTC subsystem will then expose non-existent alarm
capabilities to userspace.
[Severity: High]
This is a pre-existing issue, but does rzn1_rtc_set_offset() fail to clear
the hardware offset when the requested offset is 0?
If a user configures a non-zero offset and subsequently attempts to clear
it by setting it to 0, the function exits before updating the hardware
register:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_set_offset() {
...
if (!steps)
return 0;
...
writel(subu, rtc->base + RZN1_RTC_SUBU);
...
}
This early return leaves the previous offset permanently active in hardware.
{ .compatible = "renesas,rzn1-rtc", .data = &rzn1_rtc_rzn1_data },
{ /* sentinel */ }
};-- Sashiko AI review · https://sashiko.dev/#/patchset/20260914211826.73727-8-wsa+renesas@sang-engineering.com?part=6