- Dec 19, 2020
-
-
Rasmus Villemoes authored
Some RTCs, e.g. the pcf2127, can be used as a hardware watchdog. But if the reset pin is not actually wired up, the driver exposes a watchdog device that doesn't actually work. Provide a standard binding that can be used to indicate that a given RTC can perform a reset of the machine, similar to wakeup-source. Suggested-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- Dec 16, 2020
-
-
Alexandre Belloni authored
Since the rtc_register_device, removing an RTC device will end with a refcount_t: underflow; use-after-free warning since put_device is called twice in the device tear down path. Fixes: fdcfd854 ("rtc: rework rtc_register_device() resource management") Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20201205231449.610980-1-alexandre.belloni@bootlin.com
-
- Dec 04, 2020
-
-
Marek Szyprowski authored
Support for periodic tick interrupts has been moved from the RTC class to the HR-timers long time ago. Then it has been removed from this driver by commits 80d4bb51 ("RTC: Cleanup rtc_class_ops->irq_set_state") and 696160fe ("RTC: Cleanup rtc_class_ops->irq_set_freq()"). They however did not remove all the code related to the tick handling. Do it now then. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201202111318.5353-2-m.szyprowski@samsung.com
-
Marek Szyprowski authored
Bootloader might use RTC hardware and leave it in the enabled state. Ensure that the potentially enabled periodic tick interrupts are disabled before enabling the driver, because they might cause lockup if tick interrupt happens after disabling RTC gate clock. Signed-off-by:
-
Nikita Shubin authored
Mismatch in probe platform_set_drvdata set's and method's that call dev_get_platdata will result in "Unable to handle kernel NULL pointer dereference", let's use according method for getting driver data after platform_set_drvdata. 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = (ptrval) [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.10-00003-g723e101e0037-dirty #4 Hardware name: Technologic Systems TS-72xx SBC PC is at ep93xx_rtc_read_time+0xc/0x2c LR is at __rtc_read_time+0x4c/0x8c [...] [<c02b01c8>] (ep93xx_rtc_read_time) from [<c02ac38c>] (__rtc_read_time+0x4c/0x8c) [<c02ac38c>] (__rtc_read_time) from [<c02ac3f8>] (rtc_read_time+0x2c/0x4c) [<c02ac3f8>] (rtc_read_time) from [<c02acc54>] (__rtc_read_alarm+0x28/0x358) [<c02acc54>] (__rtc_read_alarm) from [<c02abd80>] (__rtc_register_device+0x124/0x2ec) [<c02abd80>] (__rtc_register_device) from [<c02b028c>] (ep93xx_rtc_probe+0xa4/0xac) [<c02b028c>] (ep93xx_rtc_probe) from [<c026424c>] (platform_drv_probe+0x24/0x5c) [<c026424c>] (platform_drv_probe) from [<c0262918>] (really_probe+0x218/0x374) [<c0262918>] (really_probe) from [<c0262da0>] (device_driver_attach+0x44/0x60) [<c0262da0>] (device_driver_attach) from [<c0262e70>] (__driver_attach+0xb4/0xc0) [<c0262e70>] (__driver_attach) from [<c0260d44>] (bus_for_each_dev+0x68/0xac) [<c0260d44>] (bus_for_each_dev) from [<c026223c>] (driver_attach+0x18/0x24) [<c026223c>] (driver_attach) from [<c0261dd8>] (bus_add_driver+0x150/0x1b4) [<c0261dd8>] (bus_add_driver) from [<c026342c>] (driver_register+0xb0/0xf4) [<c026342c>] (driver_register) from [<c0264210>] (__platform_driver_register+0x30/0x48) [<c0264210>] (__platform_driver_register) from [<c04cb9ac>] (ep93xx_rtc_driver_init+0x10/0x1c) [<c04cb9ac>] (ep93xx_rtc_driver_init) from [<c000973c>] (do_one_initcall+0x7c/0x1c0) [<c000973c>] (do_one_initcall) from [<c04b9ecc>] (kernel_init_freeable+0x168/0x1ac) [<c04b9ecc>] (kernel_init_freeable) from [<c03b2228>] (kernel_init+0x8/0xf4) [<c03b2228>] (kernel_init) from [<c00082c0>] (ret_from_fork+0x14/0x34) Exception stack(0xc441dfb0 to 0xc441dff8) dfa0: 00000000 00000000 00000000 00000000 dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e12fff1e e92d4010 e590303c e1a02001 (e5933000) ---[ end trace c914d6030eaa95c8 ]--- Fixes: b809d192 ("rtc: ep93xx: stop setting platform_data") Signed-off-by:
Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by:
-
Alexandre Belloni authored
Remove leftover debug message Signed-off-by:
-
Alexandre Belloni authored
Extend code coverage for the rtc-mxc and rtc-mxc-v2 drivers. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201121224529.568237-1-alexandre.belloni@bootlin.com
-
Johannes Berg authored
There's no real reason it should be disabled, and at least we can use it for development & testing with the RTC test driver. However, two devices are missing a HAS_IOMEM dependency, so add that to avoid build failures from e.g. allyesconfig. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
- Nov 19, 2020
-
-
Alexandre Belloni authored
Use the BIT macro to define register bits. Signed-off-by:
-
Alexandre Belloni authored
Set the th RTC range, it is a classic BCD RTC, considering 00 as a leap year. Let the core handle range checking. Signed-off-by:
-
Alexandre Belloni authored
Switch to devm_rtc_allocate_device/devm_rtc_register_device, this allows for further improvement of the driver. Signed-off-by:
-
Bartosz Golaszewski authored
Not destroying mutexes doesn't lead to resource leak but it's the correct thing to do for mutex debugging accounting. Signed-off-by:
-
Bartosz Golaszewski authored
We don't need to use devres_alloc() & devres_add() manually if all we want to manage is a single pointer. We can shrink the code by using devm_add_action_or_reset() instead. The number of allocations stays the same. Signed-off-by:
-
Bartosz Golaszewski authored
rtc_register_device() is a managed interface but it doesn't use devres by itself - instead it marks an rtc_device as "registered" and the devres callback for devm_rtc_allocate_device() takes care of resource release. This doesn't correspond with the design behind devres where managed structures should not be aware of being managed. The correct solution here is to register a separate devres callback for unregistering the device. While at it: rename rtc_register_device() to devm_rtc_register_device() and add it to the list of managed interfaces in devres.rst. This way we can avoid any potential confusion of driver developers who may expect there to exist a corresponding unregister function. Signed-off-by:
-
Bartosz Golaszewski authored
Some users check the return value of devm_rtc_nvmem_register() only in order to emit an error message and then continue probing. This is fine as an rtc can function without exposing nvmem but let's generalize it: let's make the registration function emit the error message so that users don't have to. Signed-off-by:
-
Bartosz Golaszewski authored
rtc_nvmem_register() is a managed interface. It doesn't require any release function to be called at driver detach. To avoid confusing driver authors, let's rename it to devm_rtc_nvmem_register() and add it to the list of managed interfaces in Documentation/. Signed-off-by:
-
Alexandre Belloni authored
The nvram sysfs attributes have been deprecated at least since v4.13, more than 3 years ago and nobody ever complained about the deprecation warning. Remove the sysfs attributes now. [Bartosz: remove the declaration of rtc_nvmem_unregister()] Signed-off-by:
-
Bartosz Golaszewski authored
It's customary to list all devres helpers in devres.rst. Add missing RTC routines. Signed-off-by:
-
Bartosz Golaszewski authored
Use a managed variant of pinctrl_register(). This way we can shorten the remove() callback as well as drop a goto label from probe(). Signed-off-by:
-
Alexandre Belloni authored
The RTC core only reads the alarm from the hardware at boot time, to know whether an alarm was already set before booting. It keeps track of all the alarms after that so there is no need to ever read the auxiliary alarm. Commit 3822d1bb ("rtc: sc27xx: Always read normal alarm when registering RTC device") already effectively removed the capability to read the auxiliary alarm as .read_alarm is always called with rtc->registered set to false. Signed-off-by:
Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lore.kernel.org/r/20201117212201.1288608-1-alexandre.belloni@bootlin.com
-
- Nov 18, 2020
-
-
Alexandre Belloni authored
Use of_device_get_match_data to simplify mxc_rtc_probe. Signed-off-by:
-
Fabio Estevam authored
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code by removing the unused non-DT support. Signed-off-by:
-
Claudius Heine authored
The RX6110 also supports I2C, so this patch adds support for it to the driver. This also renames the SPI specific functions and variables to include `_spi_` in their names. Signed-off-by:
Claudius Heine <ch@denx.de> Signed-off-by:
Henning Schild <henning.schild@siemens.com> Signed-off-by:
-
Claudius Heine authored
The help message in the Kconfig for the RX-6110 erronously stated RX-6610. Signed-off-by:
-
Andy Shevchenko authored
These prevent use of this driver with ACPI via PRP0001. Drop them to remove this restriction. Also added mod_devicetable.h include given use of struct of_device_id. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Andy Shevchenko authored
Device property API allows to gather device resources from different sources, such as ACPI. Convert the drivers to unleash the power of device property API. Signed-off-by:
-
Andy Shevchenko authored
The commit 9c19b893 ("rtc: ds1307: Add ACPI support") added invalid ACPI IDs (all of them are abusing ACPI specification). Moreover there is not even a single evidence that vendor registered any of such devices. Remove broken ACPI IDs from the driver. For prototyping one may use PRP0001 with device properties adhering to a DT binding. The following patches will add support of that to the driver. Signed-off-by:
-
Alexandre Belloni authored
Handle the sam9x60 RTC. While it can work with the at91sam9x5 fallback, it has crystal correction support and doesn't need to shadow IMR. Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20201117133920.1229679-1-alexandre.belloni@bootlin.com
-
Alexandre Belloni authored
The sama5d4 and sama5d2 RTCs are able to correct for imprecise crystals, up to 1953 ppm. Signed-off-by:
-
- Nov 15, 2020
-
-
Alexandre Belloni authored
The nvmem priv pointer is set to rv3032 but the rv3032_nvram_write and rv3032_nvram_read expect the regmap pointer. Signed-off-by:
-
Jiaxun Yang authored
While Goldfish platform is dusted, the RTC driver remains valuable for us. I'm volunteering to maintain goldfish RTC driver onward. Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
-
Jiaxun Yang authored
Goldfish platform is covered with dust. However the goldfish-rtc had been used as virtualized RTC in QEMU for RISC-V virt hw and MIPS loongson3-virt hw, thus we can drop other parts of goldfish but leave goldfish-rtc here. Signed-off-by:
-
Xu Wang authored
Because clk_* already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Signed-off-by:
-
Xu Wang authored
Because clk_disable_unprepare() already checked NULL clock parameter, so the additional check is unnecessary, just remove it. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20201113074538.65028-1-vulab@iscas.ac.cn
-
Zheng Liang authored
When devm_rtc_allocate_device is failed in pl031_probe, it should release mem regions with device. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zheng Liang <zhengliang6@huawei.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201112093139.32566-1-zhengliang6@huawei.com
-
Tian Tao authored
Coccinelle noticed: drivers/rtc/rtc-cpcap.c:271:7-32: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT drivers/rtc/rtc-cpcap.c:287:7-32: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Signed-off-by:
-
Guillaume Tucker authored
Enable wakeup in the hym8563 driver if the IRQ was successfully requested or if wakeup-source is set in the devicetree. As per the description of device_init_wakeup(), it should be enabled for "devices that everyone expects to be wakeup sources". One would expect this to be the case with a real-time clock. Tested on rk3288-rock2-square, which has an IRQ configured for the RTC. As a result, wakeup was enabled during driver initialisation. Fixes: dcaf0384 ("rtc: add hym8563 rtc-driver") Reported-by:
kernelci.org bot <bot@kernelci.org> Signed-off-by:
Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by:
-
Kaixu Xia authored
Fix the following coccicheck warning: ./drivers/rtc/rtc-da9063.c:246:5-18: WARNING: Comparison to bool Reported-by:
Tosk Robot <tencent_os_robot@tencent.com> Signed-off-by:
Kaixu Xia <kaixuxia@tencent.com> Signed-off-by:
-
Kaixu Xia authored
Here we could use the '!=' expression to fix the following coccicheck warning: ./drivers/rtc/rtc-sc27xx.c:566:50-55: WARNING: conversion to bool not needed here Reported-by:
-
- Oct 29, 2020
-
-
Dinghao Liu authored
When clk_hw_register_fixed_rate_with_accuracy() fails, clk_data should be freed. It's the same for the subsequent two error paths, but we should also unregister the already registered clocks in them. Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by:
-
