kernel/linux.git/drivers/rtc, branch master

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: Drop PNP device support

2026-02-26T17:49:34+00:00

Previous changes effectively prevented PNP devices from being created for the CMOS RTC on x86 with ACPI. Although in principle a CMOS RTC PNP device may exist on an x86 system without ACPI (that is, an x86 system where there is no ACPI at all, not one booted with ACPI disabled), such systems were there in the field ~30 years ago and most likely they would not be able to run a contemporary Linux kernel. For the above reasons, drop the PNP device support from the rtc-cmos driver. Signed-off-by: Rafael J. Wysocki Acked-by: Alexandre Belloni Link: https://patch.msgid.link/2355012.iZASKD2KPV@rafael.j.wysocki

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

2026-02-26T17:47:52+00:00

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

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

2026-02-22T17:43:11+00:00

Pull RTC updates from Alexandre Belloni: - loongson: Loongson-2K0300 support - s35390a: nvmem support - zynqmp: rework calibration * tag 'rtc-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: rtc: ds1390: fix number of bytes read from RTC rtc: class: Remove duplicate check for alarm rtc: optee: simplify OP-TEE context match rtc: interface: Alarm race handling should not discard preceding error rtc: s35390a: implement nvmem support rtc: loongson: Add Loongson-2K0300 support dt-bindings: rtc: loongson: Document Loongson-2K0300 compatible dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support dt-bindings: rtc: cpcap: convert to schema rtc: zynqmp: use dynamic max and min offset ranges rtc: zynqmp: rework set_offset rtc: zynqmp: rework read_offset rtc: zynqmp: check calibration max value rtc: zynqmp: correct frequency value rtc: amlogic-a4: Remove IRQF_ONESHOT rtc: pcf8563: use correct of_node for output clock rtc: max31335: use correct CONFIG symbol in IS_REACHABLE() rtc: nvvrs: Add ARCH_TEGRA to the NV VRS RTC driver

Convert 'alloc_flex' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

rtc: ds1390: fix number of bytes read from RTC

2026-02-20T22:12:25+00:00

The spi_write_then_read() reads 8 bytes starting from DS1390_REG_SECONDS (== 0x01), so the last byte read would already be part of the alarm (Tenths and Hundredths of Seconds) feature. However 7 bytes are engouh -- seconds (0x01), minutes (0x02), hours (0x03), day (0x04), date (0x05), month/century (0x06) and year (0x07). Signed-off-by: Andreas Gabriel-Platschek Link: https://patch.msgid.link/20260209053439.313825-1-andi.platschek@gmail.com Signed-off-by: Alexandre Belloni

rtc: class: Remove duplicate check for alarm

2026-02-20T22:12:17+00:00

In __devm_rtc_register_device(), the callee rtc_initialize_alarm() will check the alarm, there is no need to check in advance, so remove it. Signed-off-by: Jinjie Ruan Link: https://patch.msgid.link/20260122090031.3871746-1-ruanjinjie@huawei.com Signed-off-by: Alexandre Belloni