linux.git/drivers/rtc, branch master

Merge tag 'rtc-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux

2026-04-25T23:39:03+00:00

Pull RTC updates from Alexandre Belloni:
 "Subsystem:
   - add data_race() in rtc_dev_poll()

  Drivers:
   - remove i2c_match_id usage
   - abx80x: Disable alarm feature if no interrupt attached
   - ti-k3: support resuming from IO DDR low power mode"

* tag 'rtc-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
  rtc: abx80x: Disable alarm feature if no interrupt attached
  rtc: ntxec: fix OF node reference imbalance
  rtc: pic32: allow driver to be compiled with COMPILE_TEST
  rtc: ti-k3: Add support to resume from IO DDR low power mode
  rtc: cmos: Use platform_get_irq_optional() in cmos_platform_probe()
  dt-bindings: rtc: add olpc,xo1-rtc to trivial-rtc
  dt-bindings: rtc: sc2731: Add compatible for SC2730
  rtc: add data_race() in rtc_dev_poll()
  rtc: armada38x: zalloc + calloc to single allocation
  dt-bindings: rtc: isl12026: convert to YAML schema
  dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply
  rtc: max77686: convert to i2c_new_ancillary_device
  dt-bindings: rtc: mpfs-rtc: permit resets
  rtc: rx8025: Remove use of i2c_match_id()
  rtc: rv8803: Remove use of i2c_match_id()
  rtc: rs5c372: Remove use of i2c_match_id()
  rtc: pcf2127: Remove use of i2c_match_id()
  rtc: m41t80: Remove use of i2c_match_id()
  rtc: abx80x: Remove use of i2c_match_id()

rtc: abx80x: Disable alarm feature if no interrupt attached

2026-04-12T22:02:59+00:00

Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting
alarm") exposed an issue where the rtc-abx80x driver does not clear the
alarm feature bit, but instead relies on the set_alarm operation to return
invalid.

For example, when a RTC_UIE_ON ioctl is handled, it should abort at the
feature validation. Instead, it proceeds to the rtc_timer_enqueue(),
which used to return an error from the set_alarm call. However,
following the race condition handling, which likely should not be
discarding predecing errors, a success condition is returned to the
ioctl() caller. This results in (for example):
    hwclock: select() to /dev/rtc0 to wait for clock tick timed out

Notwithstanding the validity of the race condition handling, if an interrupt
wasn't specified, or could not be attached, the driver should clear the
alarm feature bit.

Fixes: 718a820a303c ("rtc: abx80x: add alarm support")
Signed-off-by: Anthony Pighin 
Link: https://patch.msgid.link/BN0PR08MB69510928028C933749F4139383D1A@BN0PR08MB6951.namprd08.prod.outlook.com
Signed-off-by: Alexandre Belloni

rtc: ntxec: fix OF node reference imbalance

2026-04-12T20:54:35+00:00

The driver reuses the OF node of the parent multi-function device but
fails to take another reference to balance the one dropped by the
platform bus code when unbinding the MFD and deregistering the child
devices.

Fix this by using the intended helper for reusing OF nodes.

Fixes: 435af89786c6 ("rtc: New driver for RTC in Netronix embedded controller")
Cc: stable@vger.kernel.org	# 5.13
Cc: Jonathan Neuschäfer 
Signed-off-by: Johan Hovold 
Link: https://patch.msgid.link/20260407122717.2676774-1-johan@kernel.org
Signed-off-by: Alexandre Belloni

rtc: pic32: allow driver to be compiled with COMPILE_TEST

2026-04-12T20:53:18+00:00

This driver currently only supports builds against a PIC32 target. Now
that commit ed65ae9f6c6b ("rtc: pic32: update include to use pic32.h
from platform_data") is merged, it's possible to compile this driver on
other architectures.

To avoid future breakage of this driver in the future, let's update the
Kconfig so that it can be built with COMPILE_TEST enabled on all
architectures.

Signed-off-by: Brian Masney 
Link: https://patch.msgid.link/20260222-rtc-pic32-v1-1-3f8eb654a34d@redhat.com
Signed-off-by: Alexandre Belloni

rtc: ti-k3: Add support to resume from IO DDR low power mode

2026-04-12T20:51:31+00:00

Restore the RTC HW context which may be lost when system enters
certain low power mode (IO+DDR mode).
Check if the RTC registers are locked which would indicate loss of
context (reset) and restore the context as needed.

Signed-off-by: Akashdeep Kaur 
Reviewed-by: Vignesh Raghavendra 
Link: https://patch.msgid.link/20260313111740.1492519-1-a-kaur@ti.com
Signed-off-by: Alexandre Belloni

rtc: cmos: Do not require IRQ if ACPI alarm is used

2026-04-04T17:14:58+00:00

If the ACPI RTC fixed event is used, a dedicated IRQ is not required
for the CMOS RTC alarm to work, so allow the driver to use the alarm
without a valid IRQ in that case.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Alexandre Belloni 
Reviewed-by: Mario Limonciello (AMD) 
Link: https://patch.msgid.link/6168746.MhkbZ0Pkbq@rafael.j.wysocki

rtc: cmos: Enable ACPI alarm if advertised in ACPI FADT

2026-04-04T17:14:58+00:00

If the ACPI_FADT_FIXED_RTC flag is unset, the platform is declaring that
it supports the ACPI RTC fixed event which should be used instead of a
dedicated CMOS RTC IRQ.  However, the driver only enables it when
is_hpet_enabled() returns true, which is questionable because there is
no clear connection between enabled HPET and signaling wakeup via the
ACPI RTC fixed event (for instance, the latter can be expected to work
on systems that don't include a functional HPET).

Moreover, since use_hpet_alarm() returns false if use_acpi_alarm is set,
the ACPI RTC fixed event is effectively used instead of the HPET alarm
if the latter is functional, but there is no particular reason why it
could not be used otherwise.

Accordingly, on x86 systems with ACPI, set use_acpi_alarm if
ACPI_FADT_FIXED_RTC is unset without looking at whether or not HPET is
enabled.

Also, do the ACPI FADT check in use_acpi_alarm_quirks() before the DMI
BIOS year checks which are more expensive and it's better to skip them
if ACPI_FADT_FIXED_RTC is set.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Alexandre Belloni 
Reviewed-by: Mario Limonciello (AMD) 
Link: https://patch.msgid.link/9618535.CDJkKcVGEf@rafael.j.wysocki

rtc: cmos: Use platform_get_irq_optional() in cmos_platform_probe()

2026-04-04T10:08:22+00:00

The rtc-cmos driver can live without an IRQ and returning an error
code from platform_get_irq() is not a problem for it in general, so
make it call platform_get_irq_optional() in cmos_platform_probe()
instead of platform_get_irq() to avoid a confusing error message
printed by the latter if an IRQ cannot be found for index 0, which
is possible on x86 platforms.

Additionally, on x86, if the IRQ is not defined and the system has
a legacy PIC, hardcode it to RTC_IRQ, which should be safe then (and
which is what the dropped PNP code did).

Fixes: d15f1c2e413e ("ACPI: PNP: Drop CMOS RTC PNP device support")
Reported-by: Nathan Chancellor 
Closes: https://lore.kernel.org/linux-acpi/20260303060752.GA2749263@ax162/
Tested-by: Nathan Chancellor 
Signed-off-by: Rafael J. Wysocki 
Link: https://patch.msgid.link/12857714.O9o76ZdvQC@rafael.j.wysocki
Signed-off-by: Alexandre Belloni

rtc: add data_race() in rtc_dev_poll()

2026-03-18T21:27:04+00:00

The unlocked read of rtc->irq_data in rtc_dev_poll() can race with
the write in rtc_handle_legacy_irq() and also, theoretically, with
the write in rtc_dev_read().

These races should be safe (see inline comment), thus annotate the
read with data_race() for KCSAN.

Reported-by: syzbot+2d4127acca35ed7b31ad@syzkaller.appspotmail.com
Closes: https://syzbot.org/bug?extid=2d4127acca35ed7b31ad
Signed-off-by: Mauricio Faria de Oliveira 
Link: https://patch.msgid.link/20260317-irq_data-v1-1-a2741002be60@igalia.com
Signed-off-by: Alexandre Belloni

rtc: armada38x: zalloc + calloc to single allocation

2026-03-13T10:22:04+00:00

Use a flexible array member to simplify allocation.

Signed-off-by: Rosen Penev 
Reviewed-by: Gregory CLEMENT 
Link: https://patch.msgid.link/20260304225329.24510-1-rosenp@gmail.com
Signed-off-by: Alexandre Belloni