summaryrefslogtreecommitdiff
path: root/drivers/rtc/rtc-cros-ec.c
AgeCommit message (Collapse)AuthorFilesLines
2020-11-19rtc: rework rtc_register_device() resource managementBartosz Golaszewski1-1/+1
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-01-07cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h'Enric Balletbo i Serra1-1/+0
This header file now only includes the cros_ec_dev struct, however, is the 'include/linux/platform_data/cros_ec_proto.h' who contains the definition of all the Chrome OS EC related structs. There is no reason to have a separate include for this struct so move to the place where other structs are defined. That way, we can remove the include itself, but also simplify the common pattern #include <linux/mfd/cros_ec.h> #include <linux/platform_data/cros_ec_proto.h> for a single include #include <linux/platform_data/cros_ec_proto.h> The changes to remove the cros_ec.h include were generated with the following shell script: git grep -l "<linux/mfd/cros_ec.h>" | xargs sed -i '/<linux\/mfd\/cros_ec.h>/d' Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Sebastian Reichel <sre@kernel.org> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2019-11-08rtc: cros-ec: let the core handle rtc rangeAlexandre Belloni1-8/+9
Let the rtc core check the date/time against the RTC range. Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20191016201414.30934-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2019-11-08rtc: cros-ec: remove superfluous error messageAlexandre Belloni1-5/+2
The RTC core now has error messages in case of registration failure, there is no need to have other messages in the drivers. Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20191016201414.30934-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2019-09-02mfd / platform: cros_ec: Reorganize platform and mfd includesEnric Balletbo i Serra1-1/+2
There is a bit of mess between cros-ec mfd includes and platform includes. For example, we have a linux/mfd/cros_ec.h include that exports the interface implemented in platform/chrome/cros_ec_proto.c. Or we have a linux/mfd/cros_ec_commands.h file that is non related to the multifunction device (in the sense that is not exporting any function of the mfd device). This causes crossed includes between mfd and platform/chrome subsystems and makes the code difficult to read, apart from creating 'curious' situations where a platform/chrome driver includes a linux/mfd/cros_ec.h file just to get the exported functions that are implemented in another platform/chrome driver. In order to have a better separation on what the cros-ec multifunction driver does and what the cros-ec core provides move and rework the affected includes doing: - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h - Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c driver from include/linux/mfd/cros_ec.h to a new file include/linux/platform_data/cros_ec_proto.h - Update all the drivers with the new includes, so - Drivers that only need to know about the protocol include - linux/platform_data/cros_ec_proto.h - linux/platform_data/cros_ec_commands.h - Drivers that need to know about the cros-ec mfd device also include - linux/mfd/cros_ec.h Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Series changes: 3 - Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp) Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-03-20rtc: cros-ec: Fail suspend/resume if wake IRQ can't be configuredStephen Boyd1-2/+2
If we encounter a failure during suspend where this RTC was programmed to wakeup the system from suspend, but that wakeup couldn't be configured because the system didn't support wakeup interrupts, we'll run into the following warning: Unbalanced IRQ 166 wake disable WARNING: CPU: 7 PID: 3071 at kernel/irq/manage.c:669 irq_set_irq_wake+0x108/0x278 This happens because the suspend process isn't aborted when the RTC fails to configure the wakeup IRQ. Instead, we continue suspending the system and then another suspend callback fails the suspend process and "unwinds" the previously suspended drivers by calling their resume callbacks. When we get back to resuming this RTC driver, we'll call disable_irq_wake() on an IRQ that hasn't been configured for wake. Let's just fail suspend/resume here if we can't configure the system to wake and the user has chosen to wakeup with this device. This fixes this warning and makes the code more robust in case there are systems out there that can't wakeup from suspend on this line but the user has chosen to do so. Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Evan Green <evgreen@chromium.org> Cc: Benson Leung <bleung@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Acked-By: Benson Leung <bleung@chromium.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-06-07rtc: cros-ec: Switch to SPDX identifier.Enric Balletbo i Serra1-16/+5
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-06-07rtc: cros-ec: Make license text and module license match.Enric Balletbo i Serra1-1/+1
The license text is specifying "GPLv2" but the MODULE_LICENSE is set to GPL which means GNU Public License v2 or later. When MODULE_LICENSE and boiler plate does not match, go for boiler plate license. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2018-03-17rtc: cros-ec: return -ETIME when refused to set alarms in the pastJeffy Chen1-4/+4
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: Brian Norris <briannorris@chromium.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2017-12-19rtc: cros-ec: add cros-ec-rtc driver.Stephen Barber1-0/+413
On platforms with a Chrome OS EC, the EC can function as a simple RTC. Add a basic driver with this functionality. Signed-off-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Benson Leung <bleung@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>