<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/rtc, branch v4.9.158</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>rtc: m41t80: Correct alarm month range with RTC reads</title>
<updated>2019-01-09T15:16:45+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@linux-mips.org</email>
</author>
<published>2018-11-07T02:39:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=6e2ecb4f2ae647fabb454f06188d922958f94ecd'/>
<id>6e2ecb4f2ae647fabb454f06188d922958f94ecd</id>
<content type='text'>
commit 3cc9ffbb1f51eb4320575a48e4805a8f52e0e26b upstream.

Add the missing adjustment of the month range on alarm reads from the
RTC, correcting an issue coming from commit 9c6dfed92c3e ("rtc: m41t80:
add alarm functionality").  The range is 1-12 for hardware and 0-11 for
`struct rtc_time', and is already correctly handled on alarm writes to
the RTC.

It was correct up until commit 48e9766726eb ("drivers/rtc/rtc-m41t80.c:
remove disabled alarm functionality") too, which removed the previous
implementation of alarm support.

Signed-off-by: Maciej W. Rozycki &lt;macro@linux-mips.org&gt;
Fixes: 9c6dfed92c3e ("rtc: m41t80: add alarm functionality")
References: 48e9766726eb ("drivers/rtc/rtc-m41t80.c: remove disabled alarm functionality")
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3cc9ffbb1f51eb4320575a48e4805a8f52e0e26b upstream.

Add the missing adjustment of the month range on alarm reads from the
RTC, correcting an issue coming from commit 9c6dfed92c3e ("rtc: m41t80:
add alarm functionality").  The range is 1-12 for hardware and 0-11 for
`struct rtc_time', and is already correctly handled on alarm writes to
the RTC.

It was correct up until commit 48e9766726eb ("drivers/rtc/rtc-m41t80.c:
remove disabled alarm functionality") too, which removed the previous
implementation of alarm support.

Signed-off-by: Maciej W. Rozycki &lt;macro@linux-mips.org&gt;
Fixes: 9c6dfed92c3e ("rtc: m41t80: add alarm functionality")
References: 48e9766726eb ("drivers/rtc/rtc-m41t80.c: remove disabled alarm functionality")
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: snvs: Add timeouts to avoid kernel lockups</title>
<updated>2018-12-21T13:11:40+00:00</updated>
<author>
<name>Trent Piepho</name>
<email>tpiepho@impinj.com</email>
</author>
<published>2018-05-16T23:45:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1228a3336d90e2e3572ebaf1d959e3f51a10ea46'/>
<id>1228a3336d90e2e3572ebaf1d959e3f51a10ea46</id>
<content type='text'>
[ Upstream commit cd7f3a249dbed2858e6c2f30e5be7f1f7a709ee2 ]

In order to read correctly from asynchronously updated RTC registers,
it's necessary to read repeatedly until their values do not change from
read to read.  It's also necessary to wait for three RTC clock ticks for
certain operations.  There are no timeouts in this code and these
operations could possibly loop forever.

To avoid kernel hangs, put in timeouts.

The iMX7d can be configured to stop the SRTC on a tamper event, which
will lockup the kernel inside this driver as described above.

These hangs can happen when running under qemu, which doesn't emulate
the SNVS RTC, though currently the driver will refuse to load on qemu
due to a timeout in the driver probe method.

It could also happen if the SRTC block where somehow placed into reset
or the slow speed clock that drives the SRTC counter (but not the CPU)
were to stop.

The symptoms on a two core iMX7d are a work queue hang on
rtc_timer_do_work(), which eventually blocks a systemd fsnotify
operation that triggers a work queue flush, causing systemd to hang and
thus causing all services that should be started by systemd, like a
console getty, to fail to start or stop.

Also optimize the wait code to wait less.  It only needs to wait for the
clock to advance three ticks, not to see it change three times.

Cc: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Cc: Alessandro Zummo &lt;a.zummo@towertech.it&gt;
Cc: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Cc: Shawn Guo &lt;shawn.guo@linaro.org&gt;
Cc: Bryan O'Donoghue &lt;pure.logic@nexus-software.ie&gt;
Signed-off-by: Trent Piepho &lt;tpiepho@impinj.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit cd7f3a249dbed2858e6c2f30e5be7f1f7a709ee2 ]

In order to read correctly from asynchronously updated RTC registers,
it's necessary to read repeatedly until their values do not change from
read to read.  It's also necessary to wait for three RTC clock ticks for
certain operations.  There are no timeouts in this code and these
operations could possibly loop forever.

To avoid kernel hangs, put in timeouts.

The iMX7d can be configured to stop the SRTC on a tamper event, which
will lockup the kernel inside this driver as described above.

These hangs can happen when running under qemu, which doesn't emulate
the SNVS RTC, though currently the driver will refuse to load on qemu
due to a timeout in the driver probe method.

It could also happen if the SRTC block where somehow placed into reset
or the slow speed clock that drives the SRTC counter (but not the CPU)
were to stop.

The symptoms on a two core iMX7d are a work queue hang on
rtc_timer_do_work(), which eventually blocks a systemd fsnotify
operation that triggers a work queue flush, causing systemd to hang and
thus causing all services that should be started by systemd, like a
console getty, to fail to start or stop.

Also optimize the wait code to wait less.  It only needs to wait for the
clock to advance three ticks, not to see it change three times.

Cc: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Cc: Alessandro Zummo &lt;a.zummo@towertech.it&gt;
Cc: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Cc: Shawn Guo &lt;shawn.guo@linaro.org&gt;
Cc: Bryan O'Donoghue &lt;pure.logic@nexus-software.ie&gt;
Signed-off-by: Trent Piepho &lt;tpiepho@impinj.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: snvs: add a missing write sync</title>
<updated>2018-12-21T13:11:40+00:00</updated>
<author>
<name>Guy Shapiro</name>
<email>guy.shapiro@mobi-wize.com</email>
</author>
<published>2017-01-29T09:57:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=54dbda74475e4e6fa8fd353c2cc599bda51fc5cc'/>
<id>54dbda74475e4e6fa8fd353c2cc599bda51fc5cc</id>
<content type='text'>
[ Upstream commit 7bb633b1a9812a6b9f3e49d0cf17f60a633914e5 ]

The clear of the LPTA_EN flag should be synced before writing to the
alarm register. Omitting this synchronization creates a race when
trying to change existing alarm.

Signed-off-by: Guy Shapiro &lt;guy.shapiro@mobi-wize.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7bb633b1a9812a6b9f3e49d0cf17f60a633914e5 ]

The clear of the LPTA_EN flag should be synced before writing to the
alarm register. Omitting this synchronization creates a race when
trying to change existing alarm.

Signed-off-by: Guy Shapiro &lt;guy.shapiro@mobi-wize.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: pcf2127: fix a kmemleak caused in pcf2127_i2c_gather_write</title>
<updated>2018-12-01T08:44:20+00:00</updated>
<author>
<name>Xulin Sun</name>
<email>xulin.sun@windriver.com</email>
</author>
<published>2018-11-06T08:42:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ab509b4f9507c208148fe5bbbc234989729f1d7d'/>
<id>ab509b4f9507c208148fe5bbbc234989729f1d7d</id>
<content type='text'>
[ Upstream commit 9bde0afb7a906f1dabdba37162551565740b862d ]

pcf2127_i2c_gather_write() allocates memory as local variable
for i2c_master_send(), after finishing the master transfer,
the allocated memory should be freed. The kmemleak is reported:

unreferenced object 0xffff80231e7dba80 (size 64):
  comm "hwclock", pid 27762, jiffies 4296880075 (age 356.944s)
  hex dump (first 32 bytes):
    03 00 12 03 19 02 11 13 00 80 98 18 00 00 ff ff ................
    00 50 00 00 00 00 00 00 02 00 00 00 00 00 00 00 .P..............
  backtrace:
    [&lt;ffff000008221398&gt;] create_object+0xf8/0x278
    [&lt;ffff000008a96264&gt;] kmemleak_alloc+0x74/0xa0
    [&lt;ffff00000821070c&gt;] __kmalloc+0x1ac/0x348
    [&lt;ffff0000087ed1dc&gt;] pcf2127_i2c_gather_write+0x54/0xf8
    [&lt;ffff0000085fd9d4&gt;] _regmap_raw_write+0x464/0x850
    [&lt;ffff0000085fe3f4&gt;] regmap_bulk_write+0x1a4/0x348
    [&lt;ffff0000087ed32c&gt;] pcf2127_rtc_set_time+0xac/0xe8
    [&lt;ffff0000087eaad8&gt;] rtc_set_time+0x80/0x138
    [&lt;ffff0000087ebfb0&gt;] rtc_dev_ioctl+0x398/0x610
    [&lt;ffff00000823f2c0&gt;] do_vfs_ioctl+0xb0/0x848
    [&lt;ffff00000823fae4&gt;] SyS_ioctl+0x8c/0xa8
    [&lt;ffff000008083ac0&gt;] el0_svc_naked+0x34/0x38
    [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Signed-off-by: Xulin Sun &lt;xulin.sun@windriver.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9bde0afb7a906f1dabdba37162551565740b862d ]

pcf2127_i2c_gather_write() allocates memory as local variable
for i2c_master_send(), after finishing the master transfer,
the allocated memory should be freed. The kmemleak is reported:

unreferenced object 0xffff80231e7dba80 (size 64):
  comm "hwclock", pid 27762, jiffies 4296880075 (age 356.944s)
  hex dump (first 32 bytes):
    03 00 12 03 19 02 11 13 00 80 98 18 00 00 ff ff ................
    00 50 00 00 00 00 00 00 02 00 00 00 00 00 00 00 .P..............
  backtrace:
    [&lt;ffff000008221398&gt;] create_object+0xf8/0x278
    [&lt;ffff000008a96264&gt;] kmemleak_alloc+0x74/0xa0
    [&lt;ffff00000821070c&gt;] __kmalloc+0x1ac/0x348
    [&lt;ffff0000087ed1dc&gt;] pcf2127_i2c_gather_write+0x54/0xf8
    [&lt;ffff0000085fd9d4&gt;] _regmap_raw_write+0x464/0x850
    [&lt;ffff0000085fe3f4&gt;] regmap_bulk_write+0x1a4/0x348
    [&lt;ffff0000087ed32c&gt;] pcf2127_rtc_set_time+0xac/0xe8
    [&lt;ffff0000087eaad8&gt;] rtc_set_time+0x80/0x138
    [&lt;ffff0000087ebfb0&gt;] rtc_dev_ioctl+0x398/0x610
    [&lt;ffff00000823f2c0&gt;] do_vfs_ioctl+0xb0/0x848
    [&lt;ffff00000823fae4&gt;] SyS_ioctl+0x8c/0xa8
    [&lt;ffff000008083ac0&gt;] el0_svc_naked+0x34/0x38
    [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Signed-off-by: Xulin Sun &lt;xulin.sun@windriver.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: hctosys: Add missing range error reporting</title>
<updated>2018-11-21T08:26:03+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@linux-mips.org</email>
</author>
<published>2018-11-05T03:48:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c616a9326b235e6531a129f1bd68f7767607302e'/>
<id>c616a9326b235e6531a129f1bd68f7767607302e</id>
<content type='text'>
commit 7ce9a992ffde8ce93d5ae5767362a5c7389ae895 upstream.

Fix an issue with the 32-bit range error path in `rtc_hctosys' where no
error code is set and consequently the successful preceding call result
from `rtc_read_time' is propagated to `rtc_hctosys_ret'.  This in turn
makes any subsequent call to `hctosys_show' incorrectly report in sysfs
that the system time has been set from this RTC while it has not.

Set the error to ERANGE then if we can't express the result due to an
overflow.

Signed-off-by: Maciej W. Rozycki &lt;macro@linux-mips.org&gt;
Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
Cc: stable@vger.kernel.org # 4.17+
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7ce9a992ffde8ce93d5ae5767362a5c7389ae895 upstream.

Fix an issue with the 32-bit range error path in `rtc_hctosys' where no
error code is set and consequently the successful preceding call result
from `rtc_read_time' is propagated to `rtc_hctosys_ret'.  This in turn
makes any subsequent call to `hctosys_show' incorrectly report in sysfs
that the system time has been set from this RTC while it has not.

Set the error to ERANGE then if we can't express the result due to an
overflow.

Signed-off-by: Maciej W. Rozycki &lt;macro@linux-mips.org&gt;
Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
Cc: stable@vger.kernel.org # 4.17+
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: bq4802: add error handling for devm_ioremap</title>
<updated>2018-09-26T06:36:39+00:00</updated>
<author>
<name>Zhouyang Jia</name>
<email>jiazhouyang09@gmail.com</email>
</author>
<published>2018-06-12T04:40:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8e16e060a86f0c340346b8269c57faa069bfe545'/>
<id>8e16e060a86f0c340346b8269c57faa069bfe545</id>
<content type='text'>
[ Upstream commit 7874b919866ba91bac253fa219d3d4c82bb944df ]

When devm_ioremap fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling devm_ioremap.

Signed-off-by: Zhouyang Jia &lt;jiazhouyang09@gmail.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7874b919866ba91bac253fa219d3d4c82bb944df ]

When devm_ioremap fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling devm_ioremap.

Signed-off-by: Zhouyang Jia &lt;jiazhouyang09@gmail.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: omap: fix potential crash on power off</title>
<updated>2018-09-09T18:01:22+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2018-07-04T09:05:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4e935c2eaec5182ade1bac3d12b115e2f195a069'/>
<id>4e935c2eaec5182ade1bac3d12b115e2f195a069</id>
<content type='text'>
commit 5c8b84f410b3819d14cb1ebf32e4b3714b5a6e0b upstream.

Do not set the system power-off callback and omap power-off rtc pointer
until we're done setting up our device to avoid leaving stale pointers
around after a late probe error.

Fixes: 97ea1906b3c2 ("rtc: omap: Support ext_wakeup configuration")
Cc: stable &lt;stable@vger.kernel.org&gt;     # 4.9
Cc: Marcin Niestroj &lt;m.niestroj@grinn-global.com&gt;
Cc: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Reviewed-by: Marcin Niestroj &lt;m.niestroj@grinn-global.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5c8b84f410b3819d14cb1ebf32e4b3714b5a6e0b upstream.

Do not set the system power-off callback and omap power-off rtc pointer
until we're done setting up our device to avoid leaving stale pointers
around after a late probe error.

Fixes: 97ea1906b3c2 ("rtc: omap: Support ext_wakeup configuration")
Cc: stable &lt;stable@vger.kernel.org&gt;     # 4.9
Cc: Marcin Niestroj &lt;m.niestroj@grinn-global.com&gt;
Cc: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Reviewed-by: Marcin Niestroj &lt;m.niestroj@grinn-global.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: ensure rtc_set_alarm fails when alarms are not supported</title>
<updated>2018-08-03T05:55:13+00:00</updated>
<author>
<name>Alexandre Belloni</name>
<email>alexandre.belloni@bootlin.com</email>
</author>
<published>2018-06-05T21:09:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=fda8caa9cb0c80deab362d73a8fd2cd322ce20fc'/>
<id>fda8caa9cb0c80deab362d73a8fd2cd322ce20fc</id>
<content type='text'>
[ Upstream commit abfdff44bc38e9e2ef7929f633fb8462632299d4 ]

When using RTC_ALM_SET or RTC_WKALM_SET with rtc_wkalrm.enabled not set,
rtc_timer_enqueue() is not called and rtc_set_alarm() may succeed but the
subsequent RTC_AIE_ON ioctl will fail. RTC_ALM_READ would also fail in that
case.

Ensure rtc_set_alarm() fails when alarms are not supported to avoid letting
programs think the alarms are working for a particular RTC when they are
not.

Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit abfdff44bc38e9e2ef7929f633fb8462632299d4 ]

When using RTC_ALM_SET or RTC_WKALM_SET with rtc_wkalrm.enabled not set,
rtc_timer_enqueue() is not called and rtc_set_alarm() may succeed but the
subsequent RTC_AIE_ON ioctl will fail. RTC_ALM_READ would also fail in that
case.

Ensure rtc_set_alarm() fails when alarms are not supported to avoid letting
programs think the alarms are working for a particular RTC when they are
not.

Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: tx4939: avoid unintended sign extension on a 24 bit shift</title>
<updated>2018-05-25T14:13:15+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2018-02-15T19:36:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=0c60045656488690b047aa535bc3c3328a544062'/>
<id>0c60045656488690b047aa535bc3c3328a544062</id>
<content type='text'>
[ Upstream commit 347876ad47b9923ce26e686173bbf46581802ffa ]

The shifting of buf[5] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. If
the top bit of buf[5] is set then all then all the upper bits sec
end up as also being set because of the sign-extension. Fix this by
casting buf[5] to an unsigned long before the shift.

Detected by CoverityScan, CID#1465292 ("Unintended sign extension")

Fixes: 0e1492330cd2 ("rtc: add rtc-tx4939 driver")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 347876ad47b9923ce26e686173bbf46581802ffa ]

The shifting of buf[5] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. If
the top bit of buf[5] is set then all then all the upper bits sec
end up as also being set because of the sign-extension. Fix this by
casting buf[5] to an unsigned long before the shift.

Detected by CoverityScan, CID#1465292 ("Unintended sign extension")

Fixes: 0e1492330cd2 ("rtc: add rtc-tx4939 driver")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: hctosys: Ensure system time doesn't overflow time_t</title>
<updated>2018-05-25T14:13:15+00:00</updated>
<author>
<name>Alexandre Belloni</name>
<email>alexandre.belloni@bootlin.com</email>
</author>
<published>2018-03-08T22:27:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=dd6b3e0a66592a72914be1d38ba29f93804e3161'/>
<id>dd6b3e0a66592a72914be1d38ba29f93804e3161</id>
<content type='text'>
[ Upstream commit b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]

On 32bit platforms, time_t is still a signed 32bit long. If it is
overflowed, userspace and the kernel cant agree on the current system time.
This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143

A good workaround is to simply avoid using hctosys which is something I
greatly encourage as the time is better set by userspace.

However, many distribution enable it and use systemd which is rendering the
system unusable in case the RTC holds a date after 2038 (and more so after
2106). Many drivers have workaround for this case and they should be
eliminated so there is only one place left to fix when userspace is able to
cope with dates after the 31bit overflow.

Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]

On 32bit platforms, time_t is still a signed 32bit long. If it is
overflowed, userspace and the kernel cant agree on the current system time.
This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143

A good workaround is to simply avoid using hctosys which is something I
greatly encourage as the time is better set by userspace.

However, many distribution enable it and use systemd which is rendering the
system unusable in case the RTC holds a date after 2038 (and more so after
2106). Many drivers have workaround for this case and they should be
eliminated so there is only one place left to fix when userspace is able to
cope with dates after the 31bit overflow.

Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
