kernel/linux.git/include/linux/rtc.h, branch v6.19.11

rtc: pm8xxx: add support for uefi offset

2025-03-17T10:52:25+00:00

On many Qualcomm platforms the PMIC RTC control and time registers are read-only so that the RTC time can not be updated. Instead an offset needs be stored in some machine-specific non-volatile memory, which the driver can take into account. Add support for storing a 32-bit offset from the GPS time epoch in a UEFI variable so that the RTC time can be set on such platforms. The UEFI variable is 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo and holds a 12-byte structure where the first four bytes is a GPS time offset in little-endian byte order. Note that this format is not arbitrary as the variable is shared with the UEFI firmware (and Windows). Tested-by: Jens Glathe Tested-by: Steev Klimaszewski Tested-by: Joel Stanley Tested-by: Sebastian Reichel # Lenovo T14s Gen6 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20250219134118.31017-3-johan+linaro@kernel.org Signed-off-by: Alexandre Belloni

rtc: class: make rtc_class constant

2024-03-08T11:05:10+00:00

Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the rtc_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman Suggested-by: Greg Kroah-Hartman Signed-off-by: Ricardo B. Marliere Link: https://lore.kernel.org/r/20240305-class_cleanup-abelloni-v1-1-944c026137c8@marliere.net Signed-off-by: Alexandre Belloni

rtc: Add API function to return alarm time bound by hardware limit

2023-10-09T13:03:28+00:00

Add rtc_bound_alarmtime() to return the requested alarm timeout bound by the maxmum alarm timeout that is supported by a given RTC. Signed-off-by: Guenter Roeck Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20230915152238.1144706-2-linux@roeck-us.net

rtc: Add support for limited alarm timer offsets

2023-08-27T21:50:22+00:00

Some alarm timers are based on time offsets, not on absolute times. In some situations, the amount of time that can be scheduled in the future is limited. This may result in a refusal to suspend the system, causing substantial battery drain. Some RTC alarm drivers remedy the situation by setting the alarm time to the maximum supported time if a request for an out-of-range timeout is made. This is not really desirable since it may result in unexpected early wakeups. To reduce the impact of this problem, let RTC drivers report the maximum supported alarm timer offset. The code setting alarm timers can then decide if it wants to reject setting alarm timers to a larger value, if it wants to implement recurring alarms until the actually requested alarm time is met, or if it wants to accept the limited alarm time. Only introduce the necessary variable into struct rtc_device. Code to set and use the variable will follow with subsequent patches. Cc: Brian Norris Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/r/20230817225537.4053865-2-linux@roeck-us.net Signed-off-by: Alexandre Belloni

rtc: remove uie_unsupported

2022-03-23T18:58:41+00:00

uie_unsupported is not used by any drivers anymore, remove it. Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220309162301.61679-29-alexandre.belloni@bootlin.com

rtc: add BSM parameter

2021-10-18T15:20:50+00:00

BSM or Backup Switch Mode is a common feature on RTCs, allowing to select how the RTC will decide when to switch from its primary power supply to the backup power supply. It is necessary to be able to set it from userspace as there are uses cases where it has to be done dynamically. Supported values are: RTC_BSM_DISABLED: disabled RTC_BSM_DIRECT: switching will happen as soon as Vbackup > Vdd RTC_BSM_LEVEL: switching will happen around a threshold, usually with an hysteresis RTC_BSM_STANDBY: switching will not happen until Vdd > Vbackup, this is useful to ensure the RTC doesn't draw any power until the device is first powered on. Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20211018151933.76865-6-alexandre.belloni@bootlin.com

rtc: class: don't call cdev_device_del() when cdev_device_add() failed

2021-10-15T19:05:33+00:00

I got a null-ptr-deref report when doing fault injection test: general protection fault, probably for non-canonical address 0xdffffc0000000022: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000110-0x0000000000000117] RIP: 0010:device_del+0x132/0xdc0 Call Trace: cdev_device_del+0x1a/0x80 devm_rtc_unregister_device+0x37/0x80 release_nodes+0xc3/0x3b0 If cdev_device_add() fails, 'dev->p' is not set, it causes null-ptr-deref when calling cdev_device_del(). Registering character device is optional, we don't return error code here, so introduce a new flag 'RTC_NO_CDEV' to indicate if it has character device, cdev_device_del() is called when this bit is not set. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20211011132114.3663509-1-yangyingliang@huawei.com

rtc: introduce features bitfield

2021-01-16T22:19:26+00:00

Introduce a bitfield to allow the drivers to announce the available features for an RTC. The main use case would be to better handle alarms, that could be present or not or have a minute resolution or may need a correct week day to be set. Use the newly introduced RTC_FEATURE_ALARM bit to then test whether alarms are available instead of relying on the presence of ops->set_alarm. Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210110231752.1418816-2-alexandre.belloni@bootlin.com

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

2020-12-20T18:12:06+00:00

Pull RTC updates from Alexandre Belloni: "Subsystem: - Remove nvram ABI. There was no complaints about the deprecation for the last 3 years. - Improve RTC device allocation and registration - Now available for ARCH=um Drivers: - at91rm9200: correction and sam9x60 support - ds1307: improve ACPI support - mxc: now DT only - pcf2127: watchdog support now needs the reset-source property - pcf8523: set range - rx6110: i2c support" * tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (43 commits) rtc: pcf2127: only use watchdog when explicitly available dt-bindings: rtc: add reset-source property rtc: fix RTC removal rtc: s3c: Remove dead code related to periodic tick handling rtc: s3c: Disable all enable (RTC, tick) bits in the probe rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time rtc: test: remove debug message rtc: mxc{,_v2}: enable COMPILE_TEST rtc: enable RTC framework on ARCH=um rtc: pcf8523: use BIT rtc: pcf8523: set range rtc: pcf8523: switch to devm_rtc_allocate_device rtc: destroy mutex when releasing the device rtc: shrink devm_rtc_allocate_device() rtc: rework rtc_register_device() resource management rtc: nvmem: emit an error message when nvmem registration fails rtc: add devm_ prefix to rtc_nvmem_register() rtc: nvmem: remove nvram ABI Documentation: list RTC devres helpers in devres.rst rtc: omap: use devm_pinctrl_register() ...

ntp: Make the RTC sync offset less obscure

2020-12-11T09:40:53+00:00

The current RTC set_offset_nsec value is not really intuitive to understand. tsched twrite(t2.tv_sec - 1) t2 (seconds increment) The offset is calculated from twrite based on the assumption that t2 - twrite == 1s. That means for the MC146818 RTC the offset needs to be negative so that the write happens 500ms before t2. It's easier to understand when the whole calculation is based on t2. That avoids negative offsets and the meaning is obvious: t2 - twrite: The time defined by the chip when seconds increment after the write. twrite - tsched: The time for the transport to the point where the chip is updated. ==> set_offset_nsec = t2 - tsched ttransport = twrite - tsched tRTCinc = t2 - twrite ==> set_offset_nsec = ttransport + tRTCinc tRTCinc is a chip property and can be obtained from the data sheet. ttransport depends on how the RTC is connected. It is close to 0 for directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the time required to send the update over the bus. This can be estimated or even calibrated, but that's a different problem. Adjust the implementation and update comments accordingly. Signed-off-by: Thomas Gleixner Acked-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de