Baolin Wang [Mon, 8 Jan 2018 06:04:50 +0000 (14:04 +0800)]
rtc: Add one offset seconds to expand RTC range
From our investigation for all RTC drivers, 1 driver will be expired before
year 2017, 7 drivers will be expired before year 2038, 23 drivers will be
expired before year 2069, 72 drivers will be expired before 2100 and 104
drivers will be expired before 2106. Especially for these early expired
drivers, we need to expand the RTC range to make the RTC can still work
after the expired year.
So we can expand the RTC range by adding one offset to the time when reading
from hardware, and subtracting it when writing back. For example, if you have
an RTC that can do 100 years, and currently is configured to be based in
Jan 1 1970, so it can represents times from 1970 to 2069. Then if you change
the start year from 1970 to 2000, which means it can represents times from
2000 to 2099. By adding or subtracting the offset produced by moving the wrap
point, all times between 1970 and 1999 from RTC hardware could get interpreted
as times from 2070 to 2099, but the interpretation of dates between 2000 and
2069 would not change.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Add a way for drivers to inform the core of the supported date/time range.
The core can then check whether the date/time or alarm is in the range
before calling ->set_time, ->set_mmss or ->set_alarm. It returns -ERANGE
when the time is out of range.
rtc: isl1208: enable interrupt after context preparation
The interrupt handler got enabled very early. If the interrupt cause is
triggering immediately before the context is fully prepared. This can
lead to undefined behaviour. Therefor we move the interrupt enable code
to the end of the probe function.
Jeffy Chen [Tue, 27 Feb 2018 02:50:03 +0000 (10:50 +0800)]
rtc: cros-ec: return -ETIME when refused to set alarms in the past
Since accessing a Chrome OS EC based rtc is a slow operation, there is a
race window where if the alarm is set for the next second and the second
ticks over right before calculating the alarm offset.
In this case the current driver is setting a 0-second alarm, which would
be considered as disabling alarms by the EC(EC_RTC_ALARM_CLEAR).
This breaks, e.g., hwclock which relies on RTC_UIE_ON ->
rtc_update_irq_enable(), which sets a 1-second alarm and expects it to
fire an interrupt.
So return -ETIME when the alarm is in the past, follow __rtc_set_alarm().
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
David Daney [Thu, 22 Feb 2018 20:04:32 +0000 (12:04 -0800)]
rtc: isl12026: new driver.
The ISL12026 is a combination RTC and EEPROM device with I2C
interface. The standard RTC driver interface is provided. The EEPROM
is accessed via the NVMEM interface.
Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: David Daney <david.daney@cavium.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Justin Chen [Mon, 26 Feb 2018 20:09:58 +0000 (12:09 -0800)]
rtc: brcmstb-waketimer: Set wktmr prescaler
The HW default is one tick per second, however instead of assuming this,
lets make sure the waketimer is actually one tick per second before
arming the alarm.
The current correction for leap years will fail in 3477. 3476-12-31 being
3477-01-00 because this is 366 leap years after 1970 and 3477 isn't a leap
year.
Fix that by looping over until days is positive or zero.
Philipp Rossak [Mon, 26 Feb 2018 21:19:01 +0000 (22:19 +0100)]
rtc: ac100: Fix ac100 determine rate bug
This patch fixes a bug, that prevents the Allwinner A83T and the A80
from a successful boot.
The bug is there since v4.16-rc1 and appeared after the clk branch was
merged.
You can find the shortend trace below:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be #2
Hardware name: Allwinner sun8i Family
Workqueue: events deferred_probe_work_func
PC is at clk_hw_get_rate+0x0/0x34
LR is at ac100_clkout_determine_rate+0x48/0x19c
[ ... ]
(clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
(ac100_clkout_determine_rate) from (clk_core_set_rate_nolock+0x3c/0x1a0)
(clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
(clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
(of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
To fix that bug, we first check if the return of the
clk_hw_get_parent_by_index is non zero. If it is zero we skip that
clock parent.
The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support") Signed-off-by: Philipp Rossak <embed3d@gmail.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
As per 8.2.6 Setting and reading the time in RTC mode, first stop the clok,
then reset it before setting the date and time registers. Finally, start
the clock.
This uses register address wrap around from 0x2f to 0x00 for efficiency.
This allows to set the clock with a millisecond accuracy (drift is not
corrected in this example):
Also, there is another possible race condition. The probe function is not
allowed to fail after the RTC is registered because the following may
happen:
s35390a_set_datetime, s35390a_get_datetime, s35390a_set_alarm and
s35390a_read_alarm are only used after casting dev to an i2c_client. Remove
that useless indirection.
At probe time, printing a message when the time is invalid doesn't have
much value. Also, as the comment suggest, this is a leftover from
development wherhe this was used to set the RTc to a default time.
rtc: omap: stop validating rtc_time in .set_time and .set_alarm
The RTC core is always validating the rtc_time struct before calling
.set_time or .set_alarm. It is not necessary to do it again.
Also, rtc_time_to_tm never generates an invalid rtc_tm (it can be out of
range though).
rtc: sc27xx: stop validating rtc_time in .read_time
rtc_time64_to_tm never generates an invalid tm. It is not necessary to
validate it. Also, the RTC core is always calling rtc_valid_tm after the
read_time callback.
Reviewed-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Returning a valid time when the time is invalid is a bad practice, because
then userspace is not able to react on the information. Also, it doesn't
make sense to return epoch because it is already the default time.
Returning a valid time when the time is invalid is a bad practice, because
then userspace is not able to react on the information. Also, it doesn't
make sense to return epoch because it is already the default time.
Returning a valid time when the time is invalid is a bad practice, because
then userspace is not able to react on the information. Also, it doesn't
make sense to return epoch because it is already the default time.
Returning a valid time when the time is invalid is a bad practice, because
then userspace is not able to react on the information. Also, it doesn't
make sense to return epoch because it is already the default time.
Colin Ian King [Thu, 15 Feb 2018 19:36:14 +0000 (19:36 +0000)]
rtc: tx4939: avoid unintended sign extension on a 24 bit shift
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 <colin.king@canonical.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Since commit 34ce71a96dcb ("ALSA: timer: remove legacy rtctimer"), the
rtc_register/rtc_control/rtc_unregister API is unused. As it is highly
unlikely to be needed again, remove it.
Denis Osterland [Tue, 23 Jan 2018 12:17:58 +0000 (13:17 +0100)]
rtc: isl1208: Fix unintended clear of SR bits
After successful
sr = isl1208_i2c_set_regs(client, 0, regs, ISL1208_RTC_SECTION_LEN);
sr will be 0.
As a result
sr = i2c_smbus_write_byte_data(client, ISL1208_REG_SR,
sr & ~ISL1208_REG_SR_WRTC);
is equal to
sr = i2c_smbus_write_byte_data(client, ISL1208_REG_SR, 0);
which clears all flags in SR.
Add an additional read of SR, to have value of SR in sr again.
Currently, the IRQs are disabled when the rtc driver is removed (e.g. when
shutting down the platform).
This means that the RTC will be unable to wakeup the platform.
Instead of adding a binary sysfs attribute from the driver (which suffers
from a race condition as the attribute appears after the device), use the
core to register an nvmem device.
Instead of adding a binary sysfs attribute from the driver, use the
core to register an nvmem device. This allows to use the in-kernel
interface to access the nvram.
Currently, the IRQs are disabled when the rtc driver is removed (e.g. when
shutting down the platform).
This means that the RTC will be unable to wakeup the platform.
Instead of adding a binary sysfs attribute from the driver (which suffers
from a race condition as the attribute appears after the device), use the
core to register an nvmem device.
Instead of adding a binary sysfs attribute from the driver (which suffers
from a race condition as the attribute appears after the device), use the
core to register an nvmem device.
Instead of adding a binary sysfs attribute from the driver (which suffers
from a race condition as the attribute appears after the device), use the
core to register an nvmem device.
Move m48t86_nvmem_cfg to the stack of m48t86_rtc_probe. This results in a
very small code size reduction and make it safer on systems with two
similar RTCs:
text data bss dec hex filename
1733 164 0 1897 769 drivers/rtc/rtc-m48t86.o.before
1793 100 0 1893 765 drivers/rtc/rtc-m48t86.o.after
Move ds1511_nvmem_cfg to the stack of ds1511_rtc_probe. This results in a
very small code size reduction and make it safer on systems with two
similar RTCs:
text data bss dec hex filename
2128 164 4 2296 8f8 drivers/rtc/rtc-ds1511.o.before
2175 100 4 2279 8e7 drivers/rtc/rtc-ds1511.o.after