linux.git/drivers/rtc, branch v6.16-rc2 Linux kernel source tree treewide, timers: Rename from_timer() to timer_container_of() 2025-06-08T07:07:37+00:00 Ingo Molnar mingo@kernel.org 2025-05-09T05:51:14+00:00 41cb08555c4164996d67c78b3bf1c658075b75f1 Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com 
Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
rtc: mt6359: Add mt6357 support 2025-06-01T22:25:32+00:00 Alexandre Mergnat amergnat@baylibre.com 2025-04-28T14:29:55+00:00 3d8b44b104fb5f93a853ae34fbcf8d840e4482f5 The MT6357 PMIC contains the same RTC as MT6358 which allows to add support for it trivially by just complementing the list of compatibles. Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Tested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250428-rtc-mt6357-v1-1-31f673b0a723@baylibre.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
The MT6357 PMIC contains the same RTC as MT6358 which allows to add
support for it trivially by just complementing the list of compatibles.

Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Tested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250428-rtc-mt6357-v1-1-31f673b0a723@baylibre.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rtc: test: Test date conversion for dates starting in 1900 2025-06-01T22:10:18+00:00 Uwe Kleine-König u.kleine-koenig@baylibre.com 2025-04-28T10:06:51+00:00 ccb2dba3c19f04d2203a4b630180bf50fe710d22 While the RTC framework intends to only handle dates after 1970 for consumers, time conversion must also work for earlier dates to cover e.g. storing dates beyond an RTC's range_max. This is most relevant for the rtc-mt6397 driver that has range_min = RTC_TIMESTAMP_BEGIN_1900; range_max = mktime64(2027, 12, 31, 23, 59, 59); and so needs working support for timestamps in 1900 starting in less than three years. So shift the tested interval of timestamps to also cover years 1900 to 1970. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-5-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
While the RTC framework intends to only handle dates after 1970 for
consumers, time conversion must also work for earlier dates to cover
e.g. storing dates beyond an RTC's range_max. This is most relevant for
the rtc-mt6397 driver that has

	range_min = RTC_TIMESTAMP_BEGIN_1900;
	range_max = mktime64(2027, 12, 31, 23, 59, 59);

and so needs working support for timestamps in 1900 starting in less than
three years.

So shift the tested interval of timestamps to also cover years 1900 to
1970.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-5-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rtc: test: Also test time and wday outcome of rtc_time64_to_tm() 2025-06-01T22:10:18+00:00 Uwe Kleine-König u.kleine-koenig@baylibre.com 2025-04-28T10:06:50+00:00 da62b49830f83d1c80bfa1f2208db0cc6c19a1f9 To cover calculation of the time and wday in the rtc kunit test also check tm_hour, tm_min, tm_sec and tm_wday of the rtc_time calculated by rtc_time64_to_tm(). There are no surprises, the two tests making use of rtc_time64_to_tm_test_date_range() continue to succeed. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-4-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
To cover calculation of the time and wday in the rtc kunit test also check
tm_hour, tm_min, tm_sec and tm_wday of the rtc_time calculated by
rtc_time64_to_tm().

There are no surprises, the two tests making use of
rtc_time64_to_tm_test_date_range() continue to succeed.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-4-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rtc: test: Emit the seconds-since-1970 value instead of days-since-1970 2025-06-01T22:10:18+00:00 Uwe Kleine-König u.kleine-koenig@baylibre.com 2025-04-28T10:06:49+00:00 46351921cbe11403a4fcab00e76fa03d99a7aef2 This is easier to handle because you can just consult date(1) to convert between a seconds-since-1970 value and a date string: $ date --utc -d @3661 Thu Jan 1 01:01:01 AM UTC 1970 $ date -d "Jan 1 12:00:00 AM UTC 1900" +%s -2208988800 The intended side effect is that this prepares the test for dates before 1970. The division of a negative value by 86400 doesn't result in the desired days-since-1970 value as e.g. secs=-82739 should map to days=-1. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-3-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
This is easier to handle because you can just consult date(1) to convert
between a seconds-since-1970 value and a date string:

	$ date --utc -d @3661
	Thu Jan  1 01:01:01 AM UTC 1970

	$ date -d "Jan 1 12:00:00 AM UTC 1900" +%s
	-2208988800

The intended side effect is that this prepares the test for dates before
1970. The division of a negative value by 86400 doesn't result in the
desired days-since-1970 value as e.g. secs=-82739 should map to days=-1.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-3-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rtc: Fix offset calculation for .start_secs < 0 2025-06-01T22:10:18+00:00 Alexandre Mergnat amergnat@baylibre.com 2025-04-28T10:06:48+00:00 fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d 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> 
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>
rtc: Make rtc_time64_to_tm() support dates before 1970 2025-06-01T22:10:17+00:00 Alexandre Mergnat amergnat@baylibre.com 2025-04-28T10:06:47+00:00 7df4cfef8b351fec3156160bedfc7d6d29de4cce 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> 
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>
rtc: pcf8563: fix wrong alarm register 2025-06-01T22:00:37+00:00 Troy Mitchell troymitchell988@gmail.com 2025-05-31T07:20:40+00:00 1e15a6803df01471e0065dabd8b9563692c47219 When the regmap framework was introduced to this driver, the PCF8563_REG_AMN register within the set_alarm function was incorrectly changed to PCF8563_REG_SC. The PCF8563_REG_SC register is the seconds register. This caused alarm values to be written to the seconds register when an alarm was set. Which means the alarm would not trigger as expected and the seconds register would be overwritten with an incorrect value. Signed-off-by: Troy Mitchell <troymitchell988@gmail.com> Link: https://lore.kernel.org/r/20250531-pcf8563-fix-alarm-v2-1-cac4b1716167@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
When the regmap framework was introduced to this driver,
the PCF8563_REG_AMN register within the set_alarm function was
incorrectly changed to PCF8563_REG_SC.

The PCF8563_REG_SC register is the seconds register.
This caused alarm values to be written to the seconds register
when an alarm was set. Which means the alarm would not trigger
as expected and the seconds register would be overwritten
with an incorrect value.

Signed-off-by: Troy Mitchell <troymitchell988@gmail.com>
Link: https://lore.kernel.org/r/20250531-pcf8563-fix-alarm-v2-1-cac4b1716167@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rtc: rzn1: support input frequencies other than 32768Hz 2025-06-01T21:53:02+00:00 Wolfram Sang wsa+renesas@sang-engineering.com 2025-05-26T09:58:04+00:00 f096bdbf08c9c696a6b5c18a36b75c43f8d86eba When using the SCMP mode instead of SUBU, this RTC can also support other input frequencies than 32768Hz. Also, upcoming SoCs will only support SCMP. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20250526095801.35781-8-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
When using the SCMP mode instead of SUBU, this RTC can also support
other input frequencies than 32768Hz. Also, upcoming SoCs will only
support SCMP.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20250526095801.35781-8-wsa+renesas@sang-engineering.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
rtc: rzn1: Disable controller before initialization 2025-06-01T21:53:02+00:00 Wolfram Sang wsa+renesas@sang-engineering.com 2025-05-26T09:58:03+00:00 a50f00cb87b1c69eb4a08ae5c79e9536da839dfd Datasheet says that the controller must be disabled before setting up either SUBU or SCMP. This did not matter so far because the driver only supported SUBU which was the default, too. It is good practice to follow datasheet recommendations, though. It will also be needed because SCMP mode will be added in a later patch. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20250526095801.35781-7-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 
Datasheet says that the controller must be disabled before setting up
either SUBU or SCMP. This did not matter so far because the driver only
supported SUBU which was the default, too. It is good practice to follow
datasheet recommendations, though. It will also be needed because SCMP
mode will be added in a later patch.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20250526095801.35781-7-wsa+renesas@sang-engineering.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>