kernel/linux.git/drivers/rtc/rtc-mv.c, branch v6.6.132

rtc: mv: remove mv_rtc_alarm_ops

2021-01-16T22:19:26+00:00

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 Link: https://lore.kernel.org/r/20210110231752.1418816-6-alexandre.belloni@bootlin.com

rtc: rework rtc_register_device() resource management

2020-11-19T11:50:12+00:00

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 Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl

rtc: use devm_platform_ioremap_resource() to simplify code

2019-10-06T23:07:35+00:00

Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20191006102953.57536-2-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-3-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-4-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-5-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-6-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-7-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-8-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-9-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-10-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-11-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-12-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-13-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-14-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-15-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-16-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-17-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-18-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-19-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-20-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-21-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-22-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-23-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-24-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-25-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-26-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-27-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-28-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-29-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-30-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-31-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-32-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-33-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-34-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-35-yuehaibing@huawei.com Signed-off-by: Alexandre Belloni

rtc: mv: add range

2019-04-04T08:06:54+00:00

This RTC handles time from 2000-01-01 00:00:00 to 2099-12-31 23:59:59 with a weird rollover to 2000-06-23 00:00:00. Tested-by: Gregory CLEMENT Signed-off-by: Alexandre Belloni

rtc: mv: convert to devm_rtc_allocate_device

2019-04-04T08:06:41+00:00

This allows further improvement of the driver. Tested-by: Gregory CLEMENT Signed-off-by: Alexandre Belloni

rtc: mv: convert to SPDX identifier

2019-04-04T08:02:58+00:00

Use SPDX-License-Identifier instead of a verbose license text. Reviewed-by: Gregory CLEMENT Signed-off-by: Alexandre Belloni

rtc: mv: let the core handle invalid alarms

2018-10-03T09:07:24+00:00

Instead of lying to the core when the alarm is invalid, let it handle that by returning the error. Signed-off-by: Alexandre Belloni Tested-by: Gregory CLEMENT (on Armada 375 DB) Signed-off-by: Alexandre Belloni

rtc: simplify getting .drvdata

2018-05-03T20:08:00+00:00

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang Acked-by: Michal Simek (for zynqmp) Signed-off-by: Alexandre Belloni

rtc: mv: remove artificial limitation

2018-03-27T08:45:02+00:00

Dates after 2038 actually fit on 32 bits. The counter will overflow in 2106. Also, it is bad practice to reset the RTC to a default value. Signed-off-by: Alexandre Belloni

rtc: stop validating rtc_time in .read_time

2018-03-02T09:09:58+00:00

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