- 17 Mar, 2018 33 commits
-
-
Gustavo A. R. Silva authored
In preparation to enabling -Wvla, remove VLA and replace it with a fixed-length array instead. >From a security viewpoint, the use of Variable Length Arrays can be a vector for stack overflow attacks. Also, in general, as the code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having segfaults that are hard to debug. Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com>
-
Alexandre Belloni authored
Add commonly used timestamps for range definition. Signed-off-by: -
Baolin Wang authored
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:
-
Baolin Wang authored
The RTC range validation code can be factored into rtc_valid_range() function to avoid duplicate code. Signed-off-by:
-
Alexandre Belloni authored
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. Signed-off-by: -
Denis Osterland authored
Fix possible race condition. It is not allowed to return with an error code after RTC is registered. Suggested-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
Denis Osterland <Denis.Osterland@diehl.com> Reviewed-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
-
Michael Grzeschik authored
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. Signed-off-by:
-
Jeffy Chen authored
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:
-
Mohit Aggarwal authored
In order to set time in rtc, need to disable rtc hw before writing into rtc registers. Also fixes disabling of alarm while setting rtc time. Signed-off-by:
Mohit Aggarwal <maggarwa@codeaurora.org> Signed-off-by:
-
Masahiro Yamada authored
This config select's MFD_SYSCON, but does not depend on HAS_IOMEM. Compile testing on architecture without HAS_IOMEM causes "unmet direct dependencies" in Kconfig phase. Detected by "make ARCH=score allyesconfig". Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Alexandre Belloni authored
The probe function must not fail after rtc_register_device. Also, rename the nvmem device so it is easily identifiable in /sys/bus/nvmem. Signed-off-by: -
David Daney authored
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:
-
Justin Chen authored
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. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Justin Chen <justinpopo6@gmail.com> Signed-off-by:
-
Alexandre Belloni authored
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. Signed-off-by: -
Philipp Rossak authored
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-gb89e32cc #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: 04940631 ("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 authored
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): RTC System 1325388767 1325388767.000029180 1325388768 1325388768.000018362 1325388769 1325388769.000006544 1325388770 1325388769.999992725 1325388771 1325388770.999974544 Signed-off-by: -
Alexandre Belloni authored
Handle alarms, currently only on INTA Signed-off-by: -
Alexandre Belloni authored
This helps debugging as it allows reading registers from debugfs. Signed-off-by: -
Alexandre Belloni authored
m41t80_get_datetime and m41t80_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: -
Alexandre Belloni authored
The IRQ is requested before the struct rtc is allocated and registered, but this struct is used in the IRQ handler, leading to: Unable to handle kernel NULL pointer dereference at virtual address 0000017c pgd = a38a2f9b [0000017c] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 613 Comm: irq/48-m41t80 Not tainted 4.16.0-rc1+ #42 Hardware name: Atmel SAMA5 PC is at mutex_lock+0x14/0x38 LR is at m41t80_handle_irq+0x1c/0x9c pc : [<c06e864c>] lr : [<c04b70f0>] psr: 20000013 sp : dec73f30 ip : 00000000 fp : dec56d98 r10: df437cf0 r9 : c0a03008 r8 : c0145ffc r7 : df5c4300 r6 : dec568d0 r5 : df593000 r4 : 0000017c r3 : df592800 r2 : 60000013 r1 : df593000 r0 : 0000017c Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c53c7d Table: 20004059 DAC: 00000051 Process irq/48-m41t80 (pid: 613, stack limit = 0xb52d091e) Stack: (0xdec73f30 to 0xdec74000) 3f20: dec56840 df5c4300 00000001 df5c4300 3f40: c0145ffc c0146018 dec56840 ffffe000 00000001 c0146290 dec567c0 00000000 3f60: c0146084 ed7c9a62 c014615c dec56d80 dec567c0 00000000 dec72000 dec56840 3f80: c014615c c012ffc0 dec72000 dec567c0 c012fe80 00000000 00000000 00000000 3fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 29282726 2d2c2b2a [<c06e864c>] (mutex_lock) from [<c04b70f0>] (m41t80_handle_irq+0x1c/0x9c) [<c04b70f0>] (m41t80_handle_irq) from [<c0146018>] (irq_thread_fn+0x1c/0x54) [<c0146018>] (irq_thread_fn) from [<c0146290>] (irq_thread+0x134/0x1c0) [<c0146290>] (irq_thread) from [<c012ffc0>] (kthread+0x140/0x148) [<c012ffc0>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Exception stack(0xdec73fb0 to 0xdec73ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e3c33d7f e3c3303f f5d0f000 e593300c (e1901f9f) ---[ end trace 22b027302eb7c604 ]--- genirq: exiting task "irq/48-m41t80" (613) is an active IRQ thread (irq 48) 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: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc before requesting the IRQ and register it as late as possible. Signed-off-by: -
Sebastian Andrzej Siewior authored
Without CONFIG_RTC_DRV_M41T80_WDT the compiler complains: |drivers/rtc/rtc-m41t80.c:76 ‘m41t80_rtc_mutex’ defined but not used [-Wunused-variable] Move the variable to the block where it is used. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Alexandre Belloni authored
pcf85063_get_datetime and pcf85063_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: -
Alexandre Belloni authored
The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: -
Alexandre Belloni authored
max6900_i2c_read_time and max6900_i2c_set_time are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: -
Alexandre Belloni authored
The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: -
Alexandre Belloni authored
rs5c372_get_datetime and rs5c372_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: -
Alexandre Belloni authored
The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: -
Alexandre Belloni authored
It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: -
Alexandre Belloni authored
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. Signed-off-by: -
Alexandre Belloni authored
The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it before returning from the callback. Signed-off-by: -
Alexandre Belloni authored
It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: -
Alexandre Belloni authored
The probe function is not allowed to fail after registering the RTC because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc as late as possible. Signed-off-by: -
Alexandre Belloni authored
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. Signed-off-by:
-
- 02 Mar, 2018 7 commits
-
-
Alexandre Belloni authored
It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: -
Alexandre Belloni authored
It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: -
Alexandre Belloni authored
It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: -
Alexandre Belloni authored
It is not necessary to print a message when the time is invalid as userspace will already get an error (and an optional dev_dbg message). Signed-off-by: -
Alexandre Belloni authored
The RTC core is always validating the rtc_time struct before calling .set_time. It is not necessary to do it again in .set_time. Signed-off-by: -
Alexandre Belloni authored
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. Signed-off-by: -
Alexandre Belloni authored
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). Signed-off-by:
-
