summaryrefslogtreecommitdiff
path: root/drivers/rtc
AgeCommit message (Collapse)AuthorFilesLines
9 daysrtc: gamecube: Check the return value of ioremap()Haotian Zhang1-0/+4
[ Upstream commit d1220e47e4bd2be8b84bc158f4dea44f2f88b226 ] The function ioremap() in gamecube_rtc_read_offset_from_sram() can fail and return NULL, which is dereferenced without checking, leading to a NULL pointer dereference. Add a check for the return value of ioremap() and return -ENOMEM on failure. Fixes: 86559400b3ef ("rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Reviewed-by: Link Mauve <kernel@linkmauve.fr> Link: https://patch.msgid.link/20251126080625.1752-1-vulab@iscas.ac.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-24rtc: rx8025: fix incorrect register referenceYuta Hayama1-1/+1
commit 162f24cbb0f6ec596e7e9f3e91610d79dc805229 upstream. This code is intended to operate on the CTRL1 register, but ctrl[1] is actually CTRL2. Correctly, ctrl[0] is CTRL1. Signed-off-by: Yuta Hayama <hayama@lineo.co.jp> Fixes: 71af91565052 ("rtc: rx8025: fix 12/24 hour mode detection on RX-8035") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/eae5f479-5d28-4a37-859d-d54794e7628c@lineo.co.jp Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-24rtc: pcf2127: fix watchdog interrupt mask on pcf2131Bruno Thomsen1-0/+15
[ Upstream commit 87064da2db7be537a7da20a25c18ba912c4db9e1 ] When using interrupt pin (INT A) as watchdog output all other interrupt sources need to be disabled to avoid additional resets. Resulting INT_A_MASK1 value is 55 (0x37). Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com> Link: https://lore.kernel.org/r/20250902182235.6825-1-bruno.thomsen@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-24rtc: pcf2127: clear minute/second interruptJosua Mayer1-1/+3
[ Upstream commit a6f1a4f05970664004a9370459c6799c1b2f2dcf ] PCF2127 can generate interrupt every full second or minute configured from control and status register 1, bits MI (1) and SI (0). On interrupt control register 2 bit MSF (7) is set and must be cleared to continue normal operation. While the driver never enables this interrupt on its own, users or firmware may do so - e.g. as an easy way to test the interrupt. Add preprocessor definition for MSF bit and include it in the irq bitmask to ensure minute and second interrupts are cleared when fired. This fixes an issue where the rtc enters a test mode and becomes unresponsive after a second interrupt has fired and is not cleared in time. In this state register writes to control registers have no effect and the interrupt line is kept asserted [1]: [1] userspace commands to put rtc into unresponsive state: $ i2cget -f -y 2 0x51 0x00 0x04 $ i2cset -f -y 2 0x51 0x00 0x05 # set bit 0 SI $ i2cget -f -y 2 0x51 0x00 0x84 # bit 8 EXT_TEST set $ i2cset -f -y 2 0x51 0x00 0x05 # try overwrite control register $ i2cget -f -y 2 0x51 0x00 0x84 # no change Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com> Link: https://lore.kernel.org/r/20250825-rtc-irq-v1-1-0133319406a7@solid-run.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19rtc: interface: Fix long-standing race when setting alarmEsben Haabendal1-0/+23
commit 795cda8338eab036013314dbc0b04aae728880ab upstream. As described in the old comment dating back to commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") from 2010, we have been living with a race window when setting alarm with an expiry in the near future (i.e. next second). With 1 second resolution, it can happen that the second ticks after the check for the timer having expired, but before the alarm is actually set. When this happen, no alarm IRQ is generated, at least not with some RTC chips (isl12022 is an example of this). With UIE RTC timer being implemented on top of alarm irq, being re-armed every second, UIE will occasionally fail to work, as an alarm irq lost due to this race will stop the re-arming loop. For now, I have limited the additional expiry check to only be done for alarms set to next seconds. I expect it should be good enough, although I don't know if we can now for sure that systems with loads could end up causing the same problems for alarms set 2 seconds or even longer in the future. I haven't been able to reproduce the problem with this check in place. Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-1-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-19rtc: interface: Ensure alarm irq is enabled when UIE is enabledEsben Haabendal1-0/+4
commit 9db26d5855d0374d4652487bfb5aacf40821c469 upstream. When setting a normal alarm, user-space is responsible for using RTC_AIE_ON/RTC_AIE_OFF to control if alarm irq should be enabled. But when RTC_UIE_ON is used, interrupts must be enabled so that the requested irq events are generated. When RTC_UIE_OFF is used, alarm irq is disabled if there are no other alarms queued, so this commit brings symmetry to that. Signed-off-by: Esben Haabendal <esben@geanix.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-5-3de8e530a39e@geanix.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-19rtc: optee: fix memory leak on driver removalClément Le Goffic1-0/+1
[ Upstream commit a531350d2fe58f7fc4516e555f22391dee94efd9 ] Fix a memory leak in case of driver removal. Free the shared memory used for arguments exchanges between kernel and OP-TEE RTC PTA. Fixes: 81c2f059ab90 ("rtc: optee: add RTC driver for OP-TEE RTC PTA") Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com> Link: https://lore.kernel.org/r/20250715-upstream-optee-rtc-v1-1-e0fdf8aae545@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19rtc: x1205: Fix Xicor X1205 vendor prefixRob Herring (Arm)1-1/+1
[ Upstream commit 606d19ee37de3a72f1b6e95a4ea544f6f20dbb46 ] The vendor for the X1205 RTC is not Xircom, but Xicor which was acquired by Intersil. Since the I2C subsystem drops the vendor prefix for driver matching, the vendor prefix hasn't mattered. Fixes: 6875404fdb44 ("rtc: x1205: Add DT probing support") Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250821215703.869628-2-robh@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-09-25rtc: pcf2127: fix SPI command byte for PCF2131 backportBruno Thomsen1-5/+5
When commit fa78e9b606a472495ef5b6b3d8b45c37f7727f9d upstream was backported to LTS branches linux-6.12.y and linux-6.6.y, the SPI regmap config fix got applied to the I2C regmap config. Most likely due to a new RTC get/set parm feature introduced in 6.14 causing regmap config sections in the buttom of the driver to move. LTS branch linux-6.1.y and earlier does not have PCF2131 device support. Issue can be seen in buttom of this diff in stable/linux.git tree: git diff master..linux-6.12.y -- drivers/rtc/rtc-pcf2127.c Fixes: ee61aec8529e ("rtc: pcf2127: fix SPI command byte for PCF2131") Fixes: 5cdd1f73401d ("rtc: pcf2127: fix SPI command byte for PCF2131") Cc: stable@vger.kernel.org Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Elena Popa <elena.popa@nxp.com> Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28rtc: ds1307: remove clear of oscillator stop flag (OSF) in probeMeagan Lloyd1-3/+1
[ Upstream commit 48458654659c9c2e149c211d86637f1592470da5 ] In using CONFIG_RTC_HCTOSYS, rtc_hctosys() will sync the RTC time to the kernel time as long as rtc_read_time() succeeds. In some power loss situations, our supercapacitor-backed DS1342 RTC comes up with either an unpredictable future time or the default 01/01/00 from the datasheet. The oscillator stop flag (OSF) is set in these scenarios due to the power loss and can be used to determine the validity of the RTC data. Some chip types in the ds1307 driver already have OSF handling to determine whether .read_time provides valid RTC data or returns -EINVAL. This change removes the clear of the OSF in .probe as the OSF needs to be preserved to expand the OSF handling to the ds1341 chip type (note that DS1341 and DS1342 share a datasheet). Signed-off-by: Meagan Lloyd <meaganlloyd@linux.microsoft.com> Reviewed-by: Tyler Hicks <code@tyhicks.com> Acked-by: Rodolfo Giometti <giometti@enneenne.com> Link: https://lore.kernel.org/r/1749665656-30108-2-git-send-email-meaganlloyd@linux.microsoft.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28rtc: ds1307: handle oscillator stop flag (OSF) for ds1341Meagan Lloyd1-0/+11
[ Upstream commit 523923cfd5d622b8f4ba893fdaf29fa6adeb8c3e ] In using CONFIG_RTC_HCTOSYS, rtc_hctosys() will sync the RTC time to the kernel time as long as rtc_read_time() succeeds. In some power loss situations, our supercapacitor-backed DS1342 RTC comes up with either an unpredictable future time or the default 01/01/00 from the datasheet. The oscillator stop flag (OSF) is set in these scenarios due to the power loss and can be used to determine the validity of the RTC data. This change expands the oscillator stop flag (OSF) handling that has already been implemented for some chips to the ds1341 chip (DS1341 and DS1342 share a datasheet). This handling manages the validity of the RTC data in .read_time and .set_time based on the OSF. Signed-off-by: Meagan Lloyd <meaganlloyd@linux.microsoft.com> Reviewed-by: Tyler Hicks <code@tyhicks.com> Acked-by: Rodolfo Giometti <giometti@enneenne.com> Link: https://lore.kernel.org/r/1749665656-30108-3-git-send-email-meaganlloyd@linux.microsoft.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15rtc: rv3028: fix incorrect maximum clock rate handlingBrian Masney1-1/+1
[ Upstream commit b574acb3cf7591d2513a9f29f8c2021ad55fb881 ] When rv3028_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: f583c341a515f ("rtc: rv3028: add clkout support") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-6-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15rtc: pcf8563: fix incorrect maximum clock rate handlingBrian Masney1-1/+1
[ Upstream commit 906726a5efeefe0ef0103ccff5312a09080c04ae ] When pcf8563_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: a39a6405d5f94 ("rtc: pcf8563: add CLKOUT to common clock framework") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-5-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15rtc: pcf85063: fix incorrect maximum clock rate handlingBrian Masney1-1/+1
[ Upstream commit 186ae1869880e58bb3f142d222abdb35ecb4df0f ] When pcf85063_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 8c229ab6048b7 ("rtc: pcf85063: Add pcf85063 clkout control to common clock framework") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-4-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15rtc: nct3018y: fix incorrect maximum clock rate handlingBrian Masney1-1/+1
[ Upstream commit 437c59e4b222cd697b4cf95995d933e7d583c5f1 ] When nct3018y_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 5adbaed16cc63 ("rtc: Add NCT3018Y real time clock driver") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-3-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15rtc: hym8563: fix incorrect maximum clock rate handlingBrian Masney1-1/+1
[ Upstream commit d0a518eb0a692a2ab8357e844970660c5ea37720 ] When hym8563_clkout_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: dcaf038493525 ("rtc: add hym8563 rtc-driver") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-2-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15rtc: ds1307: fix incorrect maximum clock rate handlingBrian Masney1-1/+1
[ Upstream commit cf6eb547a24af7ad7bbd2abe9c5327f956bbeae8 ] When ds3231_clk_sqw_round_rate() is called with a requested rate higher than the highest supported rate, it currently returns 0, which disables the clock. According to the clk API, round_rate() should instead return the highest supported rate. Update the function to return the maximum supported rate in this case. Fixes: 6c6ff145b3346 ("rtc: ds1307: add clock provider support for DS3231") Signed-off-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20250710-rtc-clk-round-rate-v1-1-33140bb2278e@redhat.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-10rtc: cmos: use spin_lock_irqsave in cmos_interruptMateusz Jończyk1-4/+6
commit 00a39d8652ff9088de07a6fe6e9e1893452fe0dd upstream. cmos_interrupt() can be called in a non-interrupt context, such as in an ACPI event handler (which runs in an interrupt thread). Therefore, usage of spin_lock(&rtc_lock) is insecure. Use spin_lock_irqsave() / spin_unlock_irqrestore() instead. Before a misguided commit 6950d046eb6e ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in hard IRQ") the cmos_interrupt() function used spin_lock_irqsave(). That commit changed it to spin_lock() and broke locking, which was partially fixed in commit 13be2efc390a ("rtc: cmos: Disable irq around direct invocation of cmos_interrupt()") That second commit did not take account of the ACPI fixed event handler pathway, however. It introduced local_irq_disable() workarounds in cmos_check_wkalrm(), which can cause problems on PREEMPT_RT kernels and are now unnecessary. Add an explicit comment so that this change will not be reverted by mistake. Cc: stable@vger.kernel.org Fixes: 6950d046eb6e ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in hard IRQ") Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Reported-by: Chris Bainbridge <chris.bainbridge@gmail.com> Closes: https://lore.kernel.org/all/aDtJ92foPUYmGheF@debian.local/ Link: https://lore.kernel.org/r/20250607210608.14835-1-mat.jonczyk@o2.pl Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-10rtc: pcf2127: fix SPI command byte for PCF2131Elena Popa1-0/+5
commit fa78e9b606a472495ef5b6b3d8b45c37f7727f9d upstream. PCF2131 was not responding to read/write operations using SPI. PCF2131 has a different command byte definition, compared to PCF2127/29. Added the new command byte definition when PCF2131 is detected. Fixes: afc505bf9039 ("rtc: pcf2127: add support for PCF2131 RTC") Cc: stable@vger.kernel.org Signed-off-by: Elena Popa <elena.popa@nxp.com> Acked-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20250530104001.957977-1-elena.popa@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-10rtc: pcf2127: add missing semicolon after statementHugo Villeneuve1-1/+1
commit 08d82d0cad51c2b1d454fe41ea1ff96ade676961 upstream. Replace comma with semicolon at the end of the statement when setting config.max_register. Fixes: fd28ceb4603f ("rtc: pcf2127: add variant-specific configuration structure") Cc: stable@vger.kernel.org Cc: Elena Popa <elena.popa@nxp.com> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20250529202923.1552560-1-hugo@hugovil.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19rtc: loongson: Add missing alarm notifications for ACPI RTC eventsLiu Dalin1-0/+8
[ Upstream commit 5af9f1fa576874b24627d4c05e3a84672204c200 ] When an application sets and enables an alarm on Loongson RTC devices, the alarm notification fails to propagate to userspace because the ACPI event handler omits calling rtc_update_irq(). As a result, processes waiting via select() or poll() on RTC device files fail to receive alarm notifications. The ACPI interrupt is also triggered multiple times. In loongson_rtc_handler, we need to clear TOY_MATCH0_REG to resolve this issue. Fixes: 09471d8f5b39 ("rtc: loongson: clear TOY_MATCH0_REG in loongson_rtc_isr()") Fixes: 1b733a9ebc3d ("rtc: Add rtc driver for the Loongson family chips") Signed-off-by: Liu Dalin <liudalin@kylinsec.com.cn> Reviewed-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://lore.kernel.org/r/20250509084416.7979-1-liudalin@kylinsec.com.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19rtc: sh: assign correct interrupts with DTWolfram Sang1-3/+9
[ Upstream commit 8f2efdbc303fe7baa83843d3290dd6ea5ba3276c ] The DT bindings for this driver define the interrupts in the order as they are numbered in the interrupt controller. The old platform_data, however, listed them in a different order. So, for DT based platforms, they are mixed up. Assign them specifically for DT, so we can keep the bindings stable. After the fix, 'rtctest' passes again on the Renesas Genmai board (RZ-A1 / R7S72100). Fixes: dab5aec64bf5 ("rtc: sh: add support for rza series") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250227134256.9167-11-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19rtc: Fix offset calculation for .start_secs < 0Alexandre Mergnat1-1/+1
commit fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d upstream. The comparison rtc->start_secs > rtc->range_max has a signed left-hand side and an unsigned right-hand side. So the comparison might become true for negative start_secs which is interpreted as a (possibly very large) positive value. As a negative value can never be bigger than an unsigned value the correct representation of the (mathematical) comparison rtc->start_secs > rtc->range_max in C is: rtc->start_secs >= 0 && rtc->start_secs > rtc->range_max Use that to fix the offset calculation currently used in the rtc-mt6397 driver. Fixes: 989515647e783 ("rtc: Add one offset seconds to expand RTC range") Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-2-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19rtc: Make rtc_time64_to_tm() support dates before 1970Alexandre Mergnat1-5/+19
commit 7df4cfef8b351fec3156160bedfc7d6d29de4cce upstream. Conversion of dates before 1970 is still relevant today because these dates are reused on some hardwares to store dates bigger than the maximal date that is representable in the device's native format. This prominently and very soon affects the hardware covered by the rtc-mt6397 driver that can only natively store dates in the interval 1900-01-01 up to 2027-12-31. So to store the date 2028-01-01 00:00:00 to such a device, rtc_time64_to_tm() must do the right thing for time=-2208988800. Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-1-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-04rtc: ds1307: stop disabling alarms on probeAlexandre Belloni1-3/+1
[ Upstream commit dcec12617ee61beed928e889607bf37e145bf86b ] It is a bad practice to disable alarms on probe or remove as this will prevent alarms across reboots. Link: https://lore.kernel.org/r/20250303223744.1135672-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04rtc: rv3032: fix EERD locationAlexandre Belloni1-1/+1
[ Upstream commit b0f9cb4a0706b0356e84d67e48500b77b343debe ] EERD is bit 2 in CTRL1 Link: https://lore.kernel.org/r/20250306214243.1167692-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02rtc: pcf85063: do a SW reset if POR failedLukas Stockmann1-1/+18
[ Upstream commit 2b7cbd98495f6ee4cd6422fe77828a19e9edf87f ] Power-on Reset has a documented issue in PCF85063, refer to its datasheet, section "Software reset": "There is a low probability that some devices will have corruption of the registers after the automatic power-on reset if the device is powered up with a residual VDD level. It is required that the VDD starts at zero volts at power up or upon power cycling to ensure that there is no corruption of the registers. If this is not possible, a reset must be initiated after power-up (i.e. when power is stable) with the software reset command" Trigger SW reset if there is an indication that POR has failed. Link: https://www.nxp.com/docs/en/data-sheet/PCF85063A.pdf Signed-off-by: Lukas Stockmann <lukas.stockmann@siemens.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20250120093451.30778-1-alexander.sverdlin@siemens.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-17rtc: zynqmp: Fix optional clock name propertyMichal Simek1-2/+2
commit 2a388ff22d2cbfc5cbd628ef085bdcd3b7dc64f5 upstream. Clock description in DT binding introduced by commit f69060c14431 ("dt-bindings: rtc: zynqmp: Add clock information") is talking about "rtc" clock name but driver is checking "rtc_clk" name instead. Because clock is optional property likely in was never handled properly by the driver. Fixes: 07dcc6f9c762 ("rtc: zynqmp: Add calibration set and get support") Signed-off-by: Michal Simek <michal.simek@amd.com> Cc: stable@kernel.org Reviewed-by: Peter Korsgaard <peter@korsgaard.com> Link: https://lore.kernel.org/r/cd5f0c9d01ec1f5a240e37a7e0d85b8dacb3a869.1732723280.git.michal.simek@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08rtc: loongson: clear TOY_MATCH0_REG in loongson_rtc_isr()Ming Wang1-5/+8
[ Upstream commit 09471d8f5b390883eaf21b917c4bf3ced1b8a1df ] The TOY_MATCH0_REG should be cleared to 0 in the RTC interrupt handler, otherwise the interrupt cannot be cleared, which will cause the loongson_rtc_isr() to be triggered multiple times. The previous code cleared TOY_MATCH0_REG in the loongson_rtc_handler(), which is an ACPI interrupt. This did not prevent loongson_rtc_isr() from being triggered multiple times. This commit moves the clearing of TOY_MATCH0_REG to the loongson_rtc_isr() to ensure that the interrupt is properly cleared. Fixes: 1b733a9ebc3d ("rtc: Add rtc driver for the Loongson family chips") Signed-off-by: Ming Wang <wangming01@loongson.cn> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Reviewed-by: Keguang Zhang <keguang.zhang@gmail.com> # on LS1B Tested-by: Keguang Zhang <keguang.zhang@gmail.com> Link: https://lore.kernel.org/r/20241205114307.1891418-1-wangming01@loongson.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM readOleksij Rempel1-1/+10
[ Upstream commit 3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c ] The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value. Fixes: fadfd092ee91 ("rtc: pcf85063: add nvram support") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20241218-rtc-pcf85063-stack-corruption-v1-1-12fd0ee0f046@pengutronix.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14rtc: cmos: avoid taking rtc_lock for extended period of timeDmitry Torokhov1-16/+15
[ Upstream commit 0a6efab33eab4e973db26d9f90c3e97a7a82e399 ] On my device reading entirety of /sys/devices/pnp0/00:03/cmos_nvram0/nvmem takes about 9 msec during which time interrupts are off on the CPU that does the read and the thread that performs the read can not be migrated or preempted by another higher priority thread (RT or not). Allow readers and writers be preempted by taking and releasing rtc_lock spinlock for each individual byte read or written rather than once per read/write request. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Link: https://lore.kernel.org/r/Zxv8QWR21AV4ztC5@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09rtc: ab-eoz9: don't fail temperature reads on undervoltage notificationMaxime Chevallier1-7/+0
[ Upstream commit e0779a0dcf41a6452ac0a169cd96863feb5787c7 ] The undervoltage flags reported by the RTC are useful to know if the time and date are reliable after a reboot. Although the threshold VLOW1 indicates that the thermometer has been shutdown and time compensation is off, it doesn't mean that the temperature readout is currently impossible. As the system is running, the RTC voltage is now fully established and we can read the temperature. Fixes: 67075b63cce2 ("rtc: add AB-RTCMC-32.768kHz-EOZ9 RTC support") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://lore.kernel.org/r/20241122101031.68916-3-maxime.chevallier@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09rtc: rzn1: fix BCD to rtc_time conversion errorsWolfram Sang1-4/+4
[ Upstream commit 55727188dfa3572aecd946e58fab9e4a64f06894 ] tm_mon describes months from 0 to 11, but the register contains BCD from 1 to 12. tm_year contains years since 1900, but the BCD contains 20XX. Apply the offsets when converting these numbers. Fixes: deeb4b5393e1 ("rtc: rzn1: Add new RTC driver") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20241113113032.27409-1-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09rtc: check if __rtc_read_time was successful in rtc_timer_do_work()Yongliang Gao1-1/+6
[ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ] If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") Signed-off-by: Yongliang Gao <leonylgao@tencent.com> Acked-by: Jingqun Li <jingqunli@tencent.com> Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09rtc: abx80x: Fix WDT bit position of the status registerNobuhiro Iwamatsu1-1/+1
[ Upstream commit 10e078b273ee7a2b8b4f05a64ac458f5e652d18d ] The WDT bit in the status register is 5, not 6. This fixes from 6 to 5. Link: https://abracon.com/Support/AppsManuals/Precisiontiming/AB08XX-Application-Manual.pdf Link: https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-1805-C3_App-Manual.pdf Fixes: 749e36d0a0d7 ("rtc: abx80x: add basic watchdog support") Cc: Jeremy Gebben <jgebben@sweptlaser.com> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Link: https://lore.kernel.org/r/20241008041737.1640633-1-iwamatsu@nigauri.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()Jinjie Ruan1-3/+2
[ Upstream commit b6cd7adec0cf03f0aefc55676e71dd721cbc71a8 ] If request_irq() fails in st_rtc_probe(), there is no need to enable the irq, and if it succeeds, disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: b5b2bdfc2893 ("rtc: st: Add new driver for ST's LPC RTC") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20240912033727.3013951-1-ruanjinjie@huawei.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-10rtc: at91sam9: fix OF node leak in probe() error pathKrzysztof Kozlowski1-0/+1
commit 73580e2ee6adfb40276bd420da3bb1abae204e10 upstream. Driver is leaking an OF node reference obtained from of_parse_phandle_with_fixed_args(). Fixes: 43e112bb3dea ("rtc: at91sam9: make use of syscon/regmap to access GPBR registers") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240825183103.102904-1-krzysztof.kozlowski@linaro.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-29rtc: nct3018y: fix possible NULL dereferenceAlexandre Belloni1-3/+3
[ Upstream commit babfeb9cbe7ebc657bd5b3e4f9fde79f560b6acc ] alarm_enable and alarm_flag are allowed to be NULL but will be dereferenced later by the dev_dbg call. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202305180042.DEzW1pSd-lkp@intel.com/ Link: https://lore.kernel.org/r/20240229222127.1878176-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03rtc: abx80x: Fix return value of nvmem callback on readJoy Chakraborty1-4/+8
commit fc82336b50e7652530bc32caec80be0f8792513b upstream. Read callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. abx80x_nvmem_xfer() on read calls i2c_smbus_read_i2c_block_data() which returns the number of bytes read on success as per its api description, this return value is handled as an error and returned to nvmem even on success. Fix to handle all possible values that would be returned by i2c_smbus_read_i2c_block_data(). Fixes: e90ff8ede777 ("rtc: abx80x: Add nvmem support") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty <joychakr@google.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20240613120750.1455209-1-joychakr@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03rtc: isl1208: Fix return value of nvmem callbacksJoy Chakraborty1-7/+4
commit 70f1ae5f0e7f44edf842444044615da7b59838c1 upstream. Read/write callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. isl1208_nvmem_read()/isl1208_nvmem_write() currently return the number of bytes read/written on success, fix to return 0 on success and negative on failure. Fixes: c3544f6f51ed ("rtc: isl1208: Add new style nvmem support to driver") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty <joychakr@google.com> Link: https://lore.kernel.org/r/20240612080831.1227131-1-joychakr@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03rtc: cmos: Fix return value of nvmem callbacksJoy Chakraborty1-6/+4
commit 1c184baccf0d5e2ef4cc1562261d0e48508a1c2b upstream. Read/write callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. cmos_nvram_read()/cmos_nvram_write() currently return the number of bytes read or written, fix to return 0 on success and -EIO incase number of bytes requested was not read or written. Fixes: 8b5b7958fd1c ("rtc: cmos: use generic nvmem") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty <joychakr@google.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20240612083635.1253039-1-joychakr@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03rtc: interface: Add RTC offset to alarm after fix-upCsókás, Bence1-4/+5
[ Upstream commit 463927a8902a9f22c3633960119410f57d4c8920 ] `rtc_add_offset()` is called by `__rtc_read_time()` and `__rtc_read_alarm()` to add the RTC's offset to the raw read-outs from the device drivers. However, in the latter case, a fix-up algorithm is run if the RTC device does not report a full `struct rtc_time` alarm value. In that case, the offset was forgot to be added. Fixes: fd6792bb022e ("rtc: fix alarm read and set offset") Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Link: https://lore.kernel.org/r/20240619140451.2800578-1-csokas.bence@prolan.hu Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17nvmem: add explicit config option to read old syntax fixed OF cellsRafał Miłecki1-0/+1
[ Upstream commit 2cc3b37f5b6df8189d55d0e812d9658ce256dfec ] Binding for fixed NVMEM cells defined directly as NVMEM device subnodes has been deprecated. It has been replaced by the "fixed-layout" NVMEM layout binding. New syntax is meant to be clearer and should help avoiding imprecise bindings. NVMEM subsystem already supports the new binding. It should be a good idea to limit support for old syntax to existing drivers that actually support & use it (we can't break backward compatibility!). That way we additionally encourage new bindings & drivers to ignore deprecated binding. It wasn't clear (to me) if rtc and w1 code actually uses old syntax fixed cells. I enabled them to don't risk any breakage. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> [for meson-{efuse,mx-efuse}.c] Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [for mtk-efuse.c, nvmem/core.c, nvmem-provider.h] Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [MT8192, MT8195 Chromebooks] Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [for microchip-otpc.c] Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> [SAMA7G5-EK] Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: d2d73a6dd173 ("mtd: limit OTP NVMEM cell parse to non-NAND devices") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27rtc: mt6397: select IRQ_DOMAIN instead of depending on itRandy Dunlap1-1/+2
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ] IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Relying on it being set for a dependency is risky. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on" for IRQ_DOMAIN to "select" for RTC_DRV_MT6397. Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency") Cc: Arnd Bergmann <arnd@arndb.de> Cc: Eddie Huang <eddie.huang@mediatek.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: linux-rtc@vger.kernel.org Cc: Marc Zyngier <maz@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Peter Rosin <peda@axentia.se> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27rtc: test: Fix invalid format specifier.David Gow1-1/+1
[ Upstream commit 8a904a3caa88118744062e872ae90f37748a8fd8 ] 'days' is a s64 (from div_s64), and so should use a %lld specifier. This was found by extending KUnit's assertion macros to use gcc's __printf attribute. Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Add tests.") Signed-off-by: David Gow <davidgow@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Justin Stitt <justinstitt@google.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-01rtc: Extend timeout for waiting for UIP to clear to 1sMario Limonciello2-2/+2
commit cef9ecc8e938dd48a560f7dd9be1246359248d20 upstream. Specs don't say anything about UIP being cleared within 10ms. They only say that UIP won't occur for another 244uS. If a long NMI occurs while UIP is still updating it might not be possible to get valid data in 10ms. This has been observed in the wild that around s2idle some calls can take up to 480ms before UIP is clear. Adjust callers from outside an interrupt context to wait for up to a 1s instead of 10ms. Cc: <stable@vger.kernel.org> # 6.1.y Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP") Reported-by: Carsten Hatger <xmb8dsv4@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217626 Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231128053653.101798-5-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-01rtc: Add support for configuring the UIP timeout for RTC readsMario Limonciello2-11/+32
commit 120931db07b49252aba2073096b595482d71857c upstream. The UIP timeout is hardcoded to 10ms for all RTC reads, but in some contexts this might not be enough time. Add a timeout parameter to mc146818_get_time() and mc146818_get_time_callback(). If UIP timeout is configured by caller to be >=100 ms and a call takes this long, log a warning. Make all callers use 10ms to ensure no functional changes. Cc: <stable@vger.kernel.org> # 6.1.y Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Link: https://lore.kernel.org/r/20231128053653.101798-4-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-01rtc: mc146818-lib: Adjust failure return code for mc146818_get_time()Mario Limonciello1-1/+1
commit af838635a3eb9b1bc0d98599c101ebca98f31311 upstream. mc146818_get_time() calls mc146818_avoid_UIP() to avoid fetching the time while RTC update is in progress (UIP). When this fails, the return code is -EIO, but actually there was no IO failure. The reason for the return from mc146818_avoid_UIP() is that the UIP wasn't cleared in the time period. Adjust the return code to -ETIMEDOUT to match the behavior. Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: <stable@vger.kernel.org> Fixes: 2a61b0ac5493 ("rtc: mc146818-lib: refactor mc146818_get_time") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231128053653.101798-2-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-01rtc: Adjust failure return code for cmos_set_alarm()Mario Limonciello1-2/+2
commit 1311a8f0d4b23f58bbababa13623aa40b8ad4e0c upstream. When mc146818_avoid_UIP() fails to return a valid value, this is because UIP didn't clear in the timeout period. Adjust the return code in this case to -ETIMEDOUT. Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: <stable@vger.kernel.org> Fixes: cdedc45c579f ("rtc: cmos: avoid UIP when reading alarm time") Fixes: cd17420ebea5 ("rtc: cmos: avoid UIP when writing alarm time") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231128053653.101798-3-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-01rtc: cmos: Use ACPI alarm for non-Intel x86 systems tooMario Limonciello1-6/+12
commit 3d762e21d56370a43478b55e604b4a83dd85aafc upstream. Intel systems > 2015 have been configured to use ACPI alarm instead of HPET to avoid s2idle issues. Having HPET programmed for wakeup causes problems on AMD systems with s2idle as well. One particular case is that the systemd "SuspendThenHibernate" feature doesn't work properly on the Framework 13" AMD model. Switching to using ACPI alarm fixes the issue. Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards. This matches what has been tested and is specifically to avoid potential risk to older systems. Cc: <stable@vger.kernel.org> # 6.1+ Reported-by: <alvin.zhuge@gmail.com> Reported-by: <renzhamin@gmail.com> Closes: https://github.com/systemd/systemd/issues/24279 Reported-by: Kelvie Wong <kelvie@kelvie.ca> Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-20 11:40:59 +0300