summaryrefslogtreecommitdiff
path: root/drivers/rtc
AgeCommit message (Collapse)AuthorFilesLines
2021-01-17rtc: rv3029: constify rv3029_rtc_opsAlexandre Belloni1-5/+6
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available instead of changing the global struct rtc_class_ops, allowing to make it const. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-15-alexandre.belloni@bootlin.com
2021-01-17rtc: rv3028: constify rv3028_rtc_opsAlexandre Belloni1-5/+6
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available instead of changing the global struct rtc_class_ops, allowing to make it const. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-14-alexandre.belloni@bootlin.com
2021-01-17rtc: opal: constify opal_rtc_opsAlexandre Belloni1-6/+7
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available instead of changing the global struct rtc_class_ops, allowing to make it const. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-13-alexandre.belloni@bootlin.com
2021-01-17rtc: m41t80: constify m41t80_rtc_opsAlexandre Belloni1-7/+7
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available instead of changing the global struct rtc_class_ops, allowing to make it const. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-12-alexandre.belloni@bootlin.com
2021-01-17rtc: pcf85363: drop a struct rtc_class_opsAlexandre Belloni1-6/+2
Merge both struct rtc_class_ops in a single one and use RTC_FEATURE_ALARM to signal to the core whether alarms are available. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-11-alexandre.belloni@bootlin.com
2021-01-17rtc: rx8010: drop a struct rtc_class_opsAlexandre Belloni1-10/+3
Merge both struct rtc_class_ops in a single one and use RTC_FEATURE_ALARM to signal to the core whether alarms are available. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-10-alexandre.belloni@bootlin.com
2021-01-17rtc: pcf85063: remove pcf85063_rtc_ops_alarmAlexandre Belloni1-9/+2
Move the alarm callbacks in pcf85063_rtc_ops and use RTC_FEATURE_ALARM to signal to the core whether alarms are available instead of having a supplementary struct rtc_class_ops without alarm callbacks. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-9-alexandre.belloni@bootlin.com
2021-01-17rtc: pcf2127: remove pcf2127_rtc_alrm_opsAlexandre Belloni1-8/+3
Move the alarm callbacks in pcf2127_rtc_ops and use RTC_FEATURE_ALARM to signal to the core whether alarms are available instead of having a supplementary struct rtc_class_ops without alarm callbacks. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-8-alexandre.belloni@bootlin.com
2021-01-17rtc: m48t59: remove m48t02_rtc_opsAlexandre Belloni1-14/+8
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of having a supplementary struct rtc_class_ops without alarm callbacks. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-7-alexandre.belloni@bootlin.com
2021-01-17rtc: mv: remove mv_rtc_alarm_opsAlexandre Belloni1-10/+4
Move the alarm callbacks in mv_rtc_ops and clear RTC_FEATURE_ALARM to signal that alarms are not available instead of having a supplementary struct rtc_class_ops. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-6-alexandre.belloni@bootlin.com
2021-01-17rtc: cmos: remove cmos_rtc_ops_no_alarmAlexandre Belloni1-9/+3
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of having a supplementary struct rtc_class_ops with a NULL .set_alarm. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-5-alexandre.belloni@bootlin.com
2021-01-17rtc: armada38x: remove armada38x_rtc_ops_noirqAlexandre Belloni1-17/+4
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of having a supplementary struct rtc_class_ops with a NULL .set_alarm. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-4-alexandre.belloni@bootlin.com
2021-01-17rtc: pl031: use RTC_FEATURE_ALARMAlexandre Belloni1-6/+2
Clear RTC_FEATURE_ALARM instead of setting set_alarm, read_alarm and alarm_irq_enable to NULL. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210110231752.1418816-3-alexandre.belloni@bootlin.com
2021-01-17rtc: introduce features bitfieldAlexandre Belloni2-6/+11
Introduce a bitfield to allow the drivers to announce the available features for an RTC. The main use case would be to better handle alarms, that could be present or not or have a minute resolution or may need a correct week day to be set. Use the newly introduced RTC_FEATURE_ALARM bit to then test whether alarms are available instead of relying on the presence of ops->set_alarm. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110231752.1418816-2-alexandre.belloni@bootlin.com
2021-01-17rtc: s5m: check the return value of s5m8767_rtc_init_reg()Bartosz Golaszewski1-0/+2
This function can fail if regmap operations fail so check its return value in probe(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210114102219.23682-4-brgl@bgdev.pl
2021-01-17rtc: s5m: use devm_i2c_new_dummy_device()Bartosz Golaszewski1-24/+7
Use the managed variant of i2c_new_dummy_device() to shrink code and remove the goto label. We can drop the remove callback now too. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210114102219.23682-3-brgl@bgdev.pl
2021-01-17rtc: s5m: select REGMAP_I2CBartosz Golaszewski1-0/+1
The rtc-s5m uses the I2C regmap but doesn't select it in Kconfig so depending on the configuration the build may fail. Fix it. Fixes: 959df7778bbd ("rtc: Enable compile testing for Maxim and Samsung drivers") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210114102219.23682-2-brgl@bgdev.pl
2021-01-13rtc: opal: set rangeAlexandre Belloni1-6/+8
It is a BCD RTC with 4 digits for the year. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210110224606.1414307-1-alexandre.belloni@bootlin.com
2021-01-13rtc: tx4939: Remove driverThomas Bogendoerfer3-311/+0
CPU support for TX49xx is getting removed, so remove rtc driver for it. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210105140305.141401-9-tsbogend@alpha.franken.de
2021-01-13rtc: rx6110: fix build against modular I2CArnd Bergmann1-2/+2
With CONFIG_I2C=m, the #ifdef section is disabled, as shown by this warning: drivers/rtc/rtc-rx6110.c:314:12: error: unused function 'rx6110_probe' [-Werror,-Wunused-function] Change the driver to use IS_ENABLED() instead, which works for both module and built-in subsystems. Fixes: afa819c2c6bf ("rtc: rx6110: add i2c support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201230145938.3254459-1-arnd@kernel.org
2021-01-13rtc: pm8xxx: Read ALARM_EN and update to alarm enabled statusGuixiong Wei1-0/+9
ALARM_EN status is retained in PMIC register after device shutdown if poweron_alarm is enabled. Read it to make sure the driver has consistent value with the register status. Signed-off-by: Guixiong Wei <guixiong@codeaurora.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/1608809337-18852-1-git-send-email-guixiong@codeaurora.org
2020-12-20Merge tag 'rtc-5.11' of ↵Linus Torvalds117-772/+558
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux Pull RTC updates from Alexandre Belloni: "Subsystem: - Remove nvram ABI. There was no complaints about the deprecation for the last 3 years. - Improve RTC device allocation and registration - Now available for ARCH=um Drivers: - at91rm9200: correction and sam9x60 support - ds1307: improve ACPI support - mxc: now DT only - pcf2127: watchdog support now needs the reset-source property - pcf8523: set range - rx6110: i2c support" * tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (43 commits) rtc: pcf2127: only use watchdog when explicitly available dt-bindings: rtc: add reset-source property rtc: fix RTC removal rtc: s3c: Remove dead code related to periodic tick handling rtc: s3c: Disable all enable (RTC, tick) bits in the probe rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time rtc: test: remove debug message rtc: mxc{,_v2}: enable COMPILE_TEST rtc: enable RTC framework on ARCH=um rtc: pcf8523: use BIT rtc: pcf8523: set range rtc: pcf8523: switch to devm_rtc_allocate_device rtc: destroy mutex when releasing the device rtc: shrink devm_rtc_allocate_device() rtc: rework rtc_register_device() resource management rtc: nvmem: emit an error message when nvmem registration fails rtc: add devm_ prefix to rtc_nvmem_register() rtc: nvmem: remove nvram ABI Documentation: list RTC devres helpers in devres.rst rtc: omap: use devm_pinctrl_register() ...
2020-12-19rtc: pcf2127: only use watchdog when explicitly availableUwe Kleine-König1-1/+2
Most boards using the pcf2127 chip (in my bubble) don't make use of the watchdog functionality and the respective output is not connected. The effect on such a board is that there is a watchdog device provided that doesn't work. So only register the watchdog if the device tree has a "reset-source" property. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [RV: s/has-watchdog/reset-source/] Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201218101054.25416-3-rasmus.villemoes@prevas.dk
2020-12-16rtc: fix RTC removalAlexandre Belloni1-1/+0
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: fdcfd854333b ("rtc: rework rtc_register_device() resource management") Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20201205231449.610980-1-alexandre.belloni@bootlin.com
2020-12-11ntp: Make the RTC sync offset less obscureThomas Gleixner2-3/+8
The current RTC set_offset_nsec value is not really intuitive to understand. tsched twrite(t2.tv_sec - 1) t2 (seconds increment) The offset is calculated from twrite based on the assumption that t2 - twrite == 1s. That means for the MC146818 RTC the offset needs to be negative so that the write happens 500ms before t2. It's easier to understand when the whole calculation is based on t2. That avoids negative offsets and the meaning is obvious: t2 - twrite: The time defined by the chip when seconds increment after the write. twrite - tsched: The time for the transport to the point where the chip is updated. ==> set_offset_nsec = t2 - tsched ttransport = twrite - tsched tRTCinc = t2 - twrite ==> set_offset_nsec = ttransport + tRTCinc tRTCinc is a chip property and can be obtained from the data sheet. ttransport depends on how the RTC is connected. It is close to 0 for directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the time required to send the update over the bus. This can be estimated or even calibrated, but that's a different problem. Adjust the implementation and update comments accordingly. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de
2020-12-11ntp, rtc: Move rtc_set_ntp_time() to ntp codeThomas Gleixner2-62/+0
rtc_set_ntp_time() is not really RTC functionality as the code is just a user of RTC. Move it into the NTP code which allows further cleanups. Requested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220542.166871172@linutronix.de
2020-12-11rtc: core: Make the sync offset default more realisticThomas Gleixner1-1/+1
The offset which is used to steer the start of an RTC synchronization update via rtc_set_ntp_time() is huge. The math behind this is: tsched twrite(t2.tv_sec - 1) t2 (seconds increment) twrite - tsched is the transport time for the write to hit the device. t2 - twrite depends on the chip and is for most chips one second. The rtc_set_ntp_time() calculation of tsched is: tsched = t2 - 1sec - (t2 - twrite) The default for the sync offset is 500ms which means that twrite - tsched is 500ms assumed that t2 - twrite is one second. This is 0.5 seconds off for RTCs which are directly accessible by IO writes and probably for the majority of i2C/SPI based RTC off by an order of magnitude. Set it to 5ms which should bring it closer to reality. The default can be adjusted by drivers (rtc_cmos does so) and could be adjusted further by a calibration method which is an orthogonal problem. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.960333166@linutronix.de
2020-12-11rtc: cmos: Make rtc_cmos sync offset correctThomas Gleixner1-0/+3
The offset for rtc_cmos must be -500ms to work correctly with the current implementation of rtc_set_ntp_time() due to the following: tsched twrite(t2.tv_sec - 1) t2 (seconds increment) twrite - tsched is the transport time for the write to hit the device, which is negligible for this chip because it's accessed directly. t2 - twrite = 500ms according to the datasheet. But rtc_set_ntp_time() calculation of tsched is: tsched = t2 - 1sec - (t2 - twrite) The default for the sync offset is 500ms which means that the write happens at t2 - 1.5 seconds which is obviously off by a second for this device. Make the offset -500ms so it works correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.830517160@linutronix.de
2020-12-11rtc: mc146818: Reduce spinlock section in mc146818_set_time()Thomas Gleixner1-4/+2
No need to hold the lock and disable interrupts for doing math. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.709243630@linutronix.de
2020-12-11rtc: mc146818: Prevent reading garbageThomas Gleixner1-25/+39
The MC146818 driver is prone to read garbage from the RTC. There are several issues all related to the update cycle of the MC146818. The chip increments seconds obviously once per second and indicates that by a bit in a register. The bit goes high 244us before the actual update starts. During the update the readout of the time values is undefined. The code just checks whether the update in progress bit (UIP) is set before reading the clock. If it's set it waits arbitrary 20ms before retrying, which is ample because the maximum update time is ~2ms. But this check does not guarantee that the UIP bit goes high and the actual update happens during the readout. So the following can happen 0.997 UIP = False -> Interrupt/NMI/preemption 0.998 UIP -> True 0.999 Readout <- Undefined To prevent this rework the code so it checks UIP before and after the readout and if set after the readout try again. But that's not enough to cover the following: 0.997 UIP = False Readout seconds -> NMI (or vCPU scheduled out) 0.998 UIP -> True update completes UIP -> False 1.000 Readout minutes,.... UIP check succeeds That can make the readout wrong up to 59 seconds. To prevent this, read the seconds value before the first UIP check, validate it after checking UIP and after reading out the rest. It's amazing that the original i386 code had this actually correct and the generic implementation of the MC146818 driver got it wrong in 2002 and it stayed that way until today. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201206220541.594826678@linutronix.de
2020-12-04rtc: s3c: Remove dead code related to periodic tick handlingMarek Szyprowski1-224/+2
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 80d4bb515b78 ("RTC: Cleanup rtc_class_ops->irq_set_state") and 696160fec162 ("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: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201202111318.5353-2-m.szyprowski@samsung.com
2020-12-04rtc: s3c: Disable all enable (RTC, tick) bits in the probeMarek Szyprowski1-0/+4
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: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201202111318.5353-1-m.szyprowski@samsung.com
2020-12-04rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_timeNikita Shubin1-3/+3
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: b809d192eb98 ("rtc: ep93xx: stop setting platform_data") Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201201095507.10317-1-nikita.shubin@maquefel.me
2020-12-04rtc: test: remove debug messageAlexandre Belloni1-1/+0
Remove leftover debug message Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201121230644.572419-1-alexandre.belloni@bootlin.com
2020-12-04rtc: mxc{,_v2}: enable COMPILE_TESTAlexandre Belloni1-2/+6
Extend code coverage for the rtc-mxc and rtc-mxc-v2 drivers. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201121224529.568237-1-alexandre.belloni@bootlin.com
2020-12-04rtc: enable RTC framework on ARCH=umJohannes Berg1-1/+3
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: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201120211103.6895ac740d11.Ic19a9926e8e4c70c03329e55f9e5b1d45095b904@changeid
2020-11-19rtc: pcf8523: use BITAlexandre Belloni1-7/+7
Use the BIT macro to define register bits. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201118002747.1346504-3-alexandre.belloni@bootlin.com
2020-11-19rtc: pcf8523: set rangeAlexandre Belloni1-11/+2
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 <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201118002747.1346504-2-alexandre.belloni@bootlin.com
2020-11-19rtc: pcf8523: switch to devm_rtc_allocate_deviceAlexandre Belloni1-3/+4
Switch to devm_rtc_allocate_device/devm_rtc_register_device, this allows for further improvement of the driver. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201118002747.1346504-1-alexandre.belloni@bootlin.com
2020-11-19rtc: destroy mutex when releasing the deviceBartosz Golaszewski1-0/+1
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 <bgolaszewski@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201110094205.8972-1-brgl@bgdev.pl
2020-11-19rtc: shrink devm_rtc_allocate_device()Bartosz Golaszewski1-20/+9
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 <bgolaszewski@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201109163409.24301-9-brgl@bgdev.pl
2020-11-19rtc: rework rtc_register_device() resource managementBartosz Golaszewski110-120/+117
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 <bgolaszewski@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl
2020-11-19rtc: nvmem: emit an error message when nvmem registration failsBartosz Golaszewski4-8/+8
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 <bgolaszewski@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201109163409.24301-7-brgl@bgdev.pl
2020-11-19rtc: add devm_ prefix to rtc_nvmem_register()Bartosz Golaszewski27-30/+30
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: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201109163409.24301-6-brgl@bgdev.pl
2020-11-19rtc: nvmem: remove nvram ABIAlexandre Belloni16-98/+1
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: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20201109163409.24301-5-brgl@bgdev.pl
2020-11-19rtc: omap: use devm_pinctrl_register()Bartosz Golaszewski1-7/+2
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: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201109163409.24301-2-brgl@bgdev.pl
2020-11-19rtc: sc27xx: Always read normal alarmAlexandre Belloni1-36/+2
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 3822d1bb0df1 ("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: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lore.kernel.org/r/20201117212201.1288608-1-alexandre.belloni@bootlin.com
2020-11-17rtc: mxc: use of_device_get_match_dataAlexandre Belloni1-3/+1
Use of_device_get_match_data to simplify mxc_rtc_probe. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201117203035.1280099-1-alexandre.belloni@bootlin.com
2020-11-17rtc: mxc: Convert the driver to DT-onlyFabio Estevam1-20/+1
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: Fabio Estevam <festevam@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201116180326.5199-1-festevam@gmail.com
2020-11-17rtc: rx6110: add i2c supportClaudius Heine2-32/+153
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: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201117121817.953924-3-ch@denx.de
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-27 03:46:02 +0300