Re: [PATCH 6/6] rtc: rzn1: add R-Car X5H support

[sashiko-bot@kernel.org]

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 <wsa+renesas@sang-engineering.com>

rtc: rzn1: add R-Car X5H support

This commit adds the compatible string for the Renesas R-Car X5H RTC to
the rzn1 driver.

> 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