<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/rtc, branch rpi-mipi</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/rtc?h=rpi-mipi</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/rtc?h=rpi-mipi'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2025-06-23T09:56:26Z</updated>
<entry>
<title>Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y</title>
<updated>2025-06-23T09:56:26Z</updated>
<author>
<name>Dom Cobley</name>
<email>popcornmix@gmail.com</email>
</author>
<published>2025-06-23T09:56:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d15beabc10d96912464f4b8d0717ff95dc53b01e'/>
<id>urn:sha1:d15beabc10d96912464f4b8d0717ff95dc53b01e</id>
<content type='text'>
</content>
</entry>
<entry>
<title>rtc: loongson: Add missing alarm notifications for ACPI RTC events</title>
<updated>2025-06-19T13:32:10Z</updated>
<author>
<name>Liu Dalin</name>
<email>liudalin@kylinsec.com.cn</email>
</author>
<published>2025-05-09T08:44:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9137bd312b288c98dcd2385f4b4eb16b69cbc504'/>
<id>urn:sha1:9137bd312b288c98dcd2385f4b4eb16b69cbc504</id>
<content type='text'>
[ 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 &lt;liudalin@kylinsec.com.cn&gt;
Reviewed-by: Binbin Zhou &lt;zhoubinbin@loongson.cn&gt;
Link: https://lore.kernel.org/r/20250509084416.7979-1-liudalin@kylinsec.com.cn
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtc: sh: assign correct interrupts with DT</title>
<updated>2025-06-19T13:32:09Z</updated>
<author>
<name>Wolfram Sang</name>
<email>wsa+renesas@sang-engineering.com</email>
</author>
<published>2025-02-27T13:42:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1dfeafe5850f5ba12191b34c46e3bbfbbed00ff6'/>
<id>urn:sha1:1dfeafe5850f5ba12191b34c46e3bbfbbed00ff6</id>
<content type='text'>
[ 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 &lt;wsa+renesas@sang-engineering.com&gt;
Link: https://lore.kernel.org/r/20250227134256.9167-11-wsa+renesas@sang-engineering.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtc: Fix offset calculation for .start_secs &lt; 0</title>
<updated>2025-06-10T17:28:18Z</updated>
<author>
<name>Alexandre Mergnat</name>
<email>amergnat@baylibre.com</email>
</author>
<published>2025-04-28T10:06:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=61399a582510897d5cdca6afbdd98c45ce89b54c'/>
<id>urn:sha1:61399a582510897d5cdca6afbdd98c45ce89b54c</id>
<content type='text'>
commit fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d upstream.

The comparison

        rtc-&gt;start_secs &gt; rtc-&gt;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-&gt;start_secs &gt; rtc-&gt;range_max

in C is:

        rtc-&gt;start_secs &gt;= 0 &amp;&amp; rtc-&gt;start_secs &gt; rtc-&gt;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 &lt;amergnat@baylibre.com&gt;
Reviewed-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-2-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rtc: Make rtc_time64_to_tm() support dates before 1970</title>
<updated>2025-06-10T17:28:18Z</updated>
<author>
<name>Alexandre Mergnat</name>
<email>amergnat@baylibre.com</email>
</author>
<published>2025-04-28T10:06:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=32c5f9ab067cdb0d9d1a88ec8a541cd6f2a5aab5'/>
<id>urn:sha1:32c5f9ab067cdb0d9d1a88ec8a541cd6f2a5aab5</id>
<content type='text'>
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 &lt;amergnat@baylibre.com&gt;
Reviewed-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-1-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rtc: Fix offset calculation for .start_secs &lt; 0</title>
<updated>2025-06-10T11:12:59Z</updated>
<author>
<name>Alexandre Mergnat</name>
<email>amergnat@baylibre.com</email>
</author>
<published>2025-04-28T10:06:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6b482b16f32e2b04aacff6933f6367b6afa04f5e'/>
<id>urn:sha1:6b482b16f32e2b04aacff6933f6367b6afa04f5e</id>
<content type='text'>
commit fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d upstream.

The comparison

        rtc-&gt;start_secs &gt; rtc-&gt;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-&gt;start_secs &gt; rtc-&gt;range_max

in C is:

        rtc-&gt;start_secs &gt;= 0 &amp;&amp; rtc-&gt;start_secs &gt; rtc-&gt;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 &lt;amergnat@baylibre.com&gt;
Reviewed-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-2-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rtc: Make rtc_time64_to_tm() support dates before 1970</title>
<updated>2025-06-10T11:12:58Z</updated>
<author>
<name>Alexandre Mergnat</name>
<email>amergnat@baylibre.com</email>
</author>
<published>2025-04-28T10:06:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a6a55fe660f8c0d62a1ad663fc878593dafad0f5'/>
<id>urn:sha1:a6a55fe660f8c0d62a1ad663fc878593dafad0f5</id>
<content type='text'>
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 &lt;amergnat@baylibre.com&gt;
Reviewed-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-1-2b2f7e3f9349@baylibre.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y</title>
<updated>2025-06-03T14:15:42Z</updated>
<author>
<name>Dom Cobley</name>
<email>popcornmix@gmail.com</email>
</author>
<published>2025-06-03T14:15:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=382ab4d59293bbb22c23861a4ea91f1c3e87b599'/>
<id>urn:sha1:382ab4d59293bbb22c23861a4ea91f1c3e87b599</id>
<content type='text'>
</content>
</entry>
<entry>
<title>rtc: ds1307: stop disabling alarms on probe</title>
<updated>2025-05-29T09:02:27Z</updated>
<author>
<name>Alexandre Belloni</name>
<email>alexandre.belloni@bootlin.com</email>
</author>
<published>2025-03-03T22:37:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3afa1610e5a4e50f9d87cb3460a4d02c7c14fad0'/>
<id>urn:sha1:3afa1610e5a4e50f9d87cb3460a4d02c7c14fad0</id>
<content type='text'>
[ 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 &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtc: rv3032: fix EERD location</title>
<updated>2025-05-29T09:02:16Z</updated>
<author>
<name>Alexandre Belloni</name>
<email>alexandre.belloni@bootlin.com</email>
</author>
<published>2025-03-06T21:42:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a0d34b9be2bee42ae21d59153d21b3d1bf5b0d72'/>
<id>urn:sha1:a0d34b9be2bee42ae21d59153d21b3d1bf5b0d72</id>
<content type='text'>
[ 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 &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
