kernel/git/stable/linux.git/drivers/rtc, branch linux-6.18.y

ACPI: x86/rtc-cmos: Use platform device for driver binding

2026-09-11T09:49:38+00:00

[ Upstream commit 2a78e42104444f948698f1225deaf515e9b7224d ] Modify the rtc-cmos driver to bind to a platform device on systems with ACPI via acpi_match_table and advertise the CMOST RTC ACPI device IDs for driver auto-loading. Note that adding the requisite device IDs to it and exposing them via MODULE_DEVICE_TABLE() is sufficient for this purpose. Since the ACPI device IDs in question are the same as for the CMOS RTC ACPI scan handler, put them into a common header file and use the definition from there in both places. Additionally, to prevent a PNP device from being created for the CMOS RTC if a platform one is present already, make is_cmos_rtc_device() check cmos_rtc_platform_device_present introduced previously. Signed-off-by: Rafael J. Wysocki Acked-by: Alexandre Belloni Link: https://patch.msgid.link/13969123.uLZWGnKmhe@rafael.j.wysocki Stable-dep-of: a3df8bbe0a70 ("ACPI: TAD: Add locking around AML evaluations") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers

2026-09-11T09:49:13+00:00

commit 51458d5b0a1cfb1b6013400abc95aadf16ed2a57 upstream. rzn1_rtc_set_alarm() updates RZN1_RTC_ALM, RZN1_RTC_ALH and RZN1_RTC_ALW using separate MMIO writes without first disabling the alarm interrupt. If a previous alarm is still enabled, the interrupt can fire while the alarm registers contain a mixture of old and newly written values. Fix this by disabling the alarm interrupt before reprogramming ALM, ALH and ALW with a call to rzn1_rtc_alarm_irq_enable(). Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-7-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

rtc: rzn1: Handle unset alarm weekday in rzn1_rtc_read_alarm

2026-09-11T09:49:13+00:00

commit 457b5dbce31209e65e1184716ed3af59cb1c0372 upstream. RZN1_RTC_ALW is a weekday bitmask where bit N represents weekday N. When no alarm has been configured, the register has its power-on-reset value of zero. rzn1_rtc_read_alarm() uses fls() to convert the weekday bitmask into a weekday number. When RZN1_RTC_ALW is zero, fls(0) returns zero and fls(wday) - 1 evaluates to -1. This invalid weekday is then used to calculate the alarm date and can either leave tm_wday set to -1 or produce a fabricated alarm date. Treat a zero RZN1_RTC_ALW value as an unset alarm weekday and return without calculating the alarm date. Move reading RZN1_RTC_CTL1 before this check so that alrm->enabled is updated for both configured and unconfigured alarms. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

rtc: rzn1: Fix weekday underflow when alarm crosses month boundary

2026-09-11T09:49:13+00:00

commit 022a2839a52006531804a8db55d3228084400b48 upstream. rzn1_rtc_set_alarm() calculates the alarm weekday from the difference between the alarm day and the current day of the month. When the alarm crosses a month boundary, this difference can become negative. Since days_ahead is unsigned, it underflows and results in an incorrect weekday being programmed into RZN1_RTC_ALW. The RTC core already provides a fully populated struct rtc_time for the alarm, including the correct tm_wday. Use tm->tm_wday directly instead of recalculating the weekday from the day-of-month. This avoids the underflow and ensures alarms scheduled across a month boundary use the correct weekday. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Suggested-by: Wolfram Sang Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt

2026-09-11T09:49:13+00:00

commit 708546aa39560a11cf44c7ba99492c8395a6c2fb upstream. Check for -EPROBE_DEFER from platform_get_irq_byname_optional() and handle the deferred probe request properly. Although the "pps" interrupt is optional, an error code of -EPROBE_DEFER indicates that the interrupt subsystem is not yet ready. Intercept this specific error condition, assign it to the return value, and jump to the dis_runtime_pm label to avoid ignoring a valid probe deferral. Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

rtc: mpfs: fix counter upload completion condition

2026-07-24T14:17:14+00:00

commit 9792ff8afa9017fe14f436f3ef3cd75f41f9f145 upstream. The condition that needs to be checked for upload completion is the UPLOAD bit in the completion register going low. The original iterations of this driver used a do-while and this was converted to a read_poll_timeout() during upstreaming without the condition being inverted as it should have been. I suspect that this went unnoticed until now because a) the first read was done when the bit was still set, immediately completing the read_poll_timeout() and b) because the RTC doesn't hold time when power is removed from the SoC reducing its utility (I for one keep it disabled). If my first suspicion was true when the driver was upstreamed, it's not true any longer though, hence the detection of the problem. Fixes: 0b31d703598dc ("rtc: Add driver for Microchip PolarFire SoC") CC: stable@vger.kernel.org Signed-off-by: Conor Dooley Tested-by: Valentina Fernandez Link: https://patch.msgid.link/20260513-panhandle-ashy-70c6abf84d59@spud Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error path

2026-07-24T14:17:14+00:00

commit 7e342d87aa8e6b831cf6d21ca41b1f7e032d0fcf upstream. In rtca3_set_alarm(), the setup_failed path attempts to disable the Periodic Interrupt Enable (PIE) bit and wait until it is cleared. However, the polling condition passed to readb_poll_timeout_atomic() uses an incorrect expression: !(tmp & ~RTCA3_RCR1_PIE) As ~RTCA3_RCR1_PIE evaluates to a mask of all bits except PIE, the condition effectively waits for all non-PIE bits to become zero, which is unrelated to the intended operation and is unlikely to ever be true. This causes the poll to time out unnecessarily. Fix the condition to check for the PIE bit itself being cleared: !(tmp & RTCA3_RCR1_PIE) This correctly waits until PIE is deasserted after being cleared. Fixes: d4488377609e3 ("rtc: renesas-rtca3: Add driver for RTCA-3 available on Renesas RZ/G3S SoC") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Claudiu Beznea Tested-by: Claudiu Beznea # on RZ/G3S Link: https://patch.msgid.link/20260602192559.1791344-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

rtc: cmos: unregister HPET IRQ handler on probe failure

2026-07-24T14:16:39+00:00

[ Upstream commit a5bb580df018b5d1c5668f05f7979044fb19e23a ] cmos_do_probe() registers cmos_interrupt() as the HPET RTC IRQ handler before requesting the RTC IRQ and registering the RTC device. If either request_irq() or devm_rtc_register_device() fails afterwards, the error path leaves the HPET RTC IRQ handler installed. This leaves a stale handler behind and make a later hpet_register_irq_handler() fail with -EBUSY. Track whether the HPET handler was registered successfully and undo the registration on the probe error path. Also mask the HPET RTC IRQ bits to match the normal shutdown cleanup. Fixes: 9d8af78b0797 ("rtc: add HPET RTC emulation to RTC_DRV_CMOS") Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260623100848.2127281-1-haoxiang_li2024@163.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

rtc: ds1307: Fix off-by-one issue with wday for rx8130

2026-07-24T14:16:39+00:00

[ Upstream commit 6882aab3c66112b33b251be95c09c8ead3e8d580 ] The RTC represent each weekday with a individual bit set in the WDAY register, where the 0th bit represent the first day of the week and the 6th bit represents the last day of the week. For each passed day the chip performs a rotary-left-shift by one to advance the weekday by one. The tm_wday field represent weekdays by a value in the range of 0-6. The fls() function return the bit index of the last bit set. To handle when there are no bits set it will return 0, and if the 0th bit is set it will return 1, and if the 1st bit is set it will return 2, and so on. In order to make the result of the fls() function fall into the expected range of 0-6 (instead of 1-7) this patch subtracts one from the result (which matches how the value is written in ds1307_set_time()). Fixes: 204756f016726 ("rtc: ds1307: Fix wday settings for rx8130") Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Fredrik M Olsson Link: https://patch.msgid.link/20260520-ds1307-rx8901-add-v2-2-e069ea32e1db@axis.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

rtc: msc313: fix NULL deref in shared IRQ handler at probe

2026-07-24T14:16:36+00:00

[ Upstream commit a369f48be8de426a7d2bca18dbd46c2ad1138803 ] msc313_rtc_probe() calls devm_request_irq() with IRQF_SHARED and &pdev->dev as the cookie, but platform_set_drvdata() is only called later after the clock setup. With a shared IRQ line, another device on the same line can trigger the handler in that window. The handler does dev_get_drvdata() on the cookie, gets NULL, and dereferences priv->rtc_base in interrupt context. Pass priv as the cookie directly so the handler reads it from dev_id without the lookup, removing the dependency on probe order. Fixes: be7d9c9161b9 ("rtc: Add support for the MSTAR MSC313 RTC") Signed-off-by: Stepan Ionichev Link: https://patch.msgid.link/20260511032703.48262-1-sozdayvek@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin