- 17 Mar, 2018 16 commits
-
-
Alexandre Belloni authored
This helps debugging as it allows reading registers from debugfs. Signed-off-by:Alexandre Belloni <alexandre.belloni@bootlin.com>
-
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 17 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: -
Alexandre Belloni authored
The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. 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 just before returning from the callback. Signed-off-by: -
Alexandre Belloni authored
isl12022_get_datetime and isl12022_set_datetime are only used after casting dev to an i2c_client. Remove that useless indirection. Signed-off-by: -
Alexandre Belloni authored
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 authored
The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. 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
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. Acked-by:
Steve Twiss <stwiss.opensource@diasemi.com> 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 just before returning from the callback. Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.co.uk> 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 just before returning from the callback. 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 just before returning from the callback. Signed-off-by:
-
- 01 Mar, 2018 7 commits
-
-
Alexandre Belloni authored
rtc_time_to_tm never generates an invalid tm. It is not necessary to validate it. Signed-off-by: -
Alexandre Belloni authored
rtc_time64_to_tm never generates an invalid tm. It is not necessary to validate it. Signed-off-by: -
Alexandre Belloni authored
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. Signed-off-by: -
Alexandre Belloni authored
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. Signed-off-by: -
Alexandre Belloni authored
Setting the rtc to a valid time when the time is invalid is a bad practice, because then userspace doesn't know it shouldn't trust the RTC. Signed-off-by: -
Alexandre Belloni authored
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. Signed-off-by: -
Alexandre Belloni authored
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. Signed-off-by:
-
