summaryrefslogtreecommitdiff
path: root/drivers/rtc/rtc-wilco-ec.c
AgeCommit message (Collapse)Author
2020-11-19rtc: rework rtc_register_device() resource managementBartosz Golaszewski
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
2019-10-14rtc: wilco-ec: Handle reading invalid timesNick Crews
If the RTC HW returns an invalid time, the rtc_year_days() call would crash. This patch adds error logging in this situation, and removes the tm_yday and tm_wday calculations. These fields should not be relied upon by userspace according to man rtc, and thus we don't need to calculate them. Signed-off-by: Nick Crews <ncrews@chromium.org> Reviewed-by: Daniel Campello <campello@chromium.org> Link: https://lore.kernel.org/r/20191004142608.170159-1-ncrews@chromium.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2019-04-15platform/chrome: wilco_ec: Standardize mailbox interfaceNick Crews
The current API for the wilco EC mailbox interface is bad. It assumes that most messages sent to the EC follow a similar structure, with a command byte in MBOX[0], followed by a junk byte, followed by actual data. This doesn't happen in several cases, such as setting the RTC time, using the raw debugfs interface, and reading or writing properties such as the Peak Shift policy (this last to be submitted soon). Similarly for the response message from the EC, the current interface assumes that the first byte of data is always 0, and the second byte is unused. However, in both setting and getting the RTC time, in the debugfs interface, and for reading and writing properties, this isn't true. The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to specify when and when not to skip these initial bytes in the sent and received message. They are confusing and used so much that they are normal, and not exceptions. In addition, the first byte of response in the debugfs interface is still always skipped, which is weird, since this raw interface should be giving the entire result. Additionally, sent messages assume the first byte is a command, and so struct wilco_ec_message contains the "command" field. In setting or getting properties however, the first byte is not a command, and so this field has to be filled with a byte that isn't actually a command. This is again inconsistent. wilco_ec_message contains a result field as well, copied from wilco_ec_response->result. The message result field should be removed: if the message fails, the cause is already logged, and the callers are alerted. They will never care about the actual state of the result flag. These flags and different cases make the wilco_ec_transfer() function, used in wilco_ec_mailbox(), really gross, dealing with a bunch of different cases. It's difficult to figure out what it is doing. Finally, making these assumptions about the structure of a message make it so that the messages do not correspond well with the specification for the EC's mailbox interface. For instance, this interface specification may say that MBOX[9] in the received message contains some information, but the calling code needs to remember that the first byte of response is always skipped, and because it didn't set the RESPONSE_RAW flag, the next byte is also skipped, so this information is actually contained within wilco_ec_message->response_data[7]. This makes it difficult to maintain this code in the future. To fix these problems this patch standardizes the mailbox interface by: - Removing the WILCO_EC_FLAG_RAW* flags - Removing the command and reserved_raw bytes from wilco_ec_request - Removing the mbox0 byte from wilco_ec_response - Simplifying wilco_ec_transfer() because of these changes - Gives the callers of wilco_ec_mailbox() the responsibility of exactly and consistently defining the structure of the mailbox request and response - Removing command and result from wilco_ec_message. This results in the reduction of total code, and makes it much more maintainable and understandable. Signed-off-by: Nick Crews <ncrews@chromium.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-02-21platform/chrome: wilco_ec: Add RTC driverNick Crews
This Embedded Controller has an internal RTC that is exposed as a standard RTC class driver with read/write functionality. The driver is added to the drivers/rtc/ so that the maintainer of that directory will be able to comment on this change, as that maintainer is the expert on this system. In addition, the driver code is called indirectly after a corresponding device is registered from core.c, as opposed to core.c registering the driver callbacks directly. To test: > hwclock --show --rtc /dev/rtc1 2007-12-31 16:01:20.460959-08:00 > hwclock --systohc --rtc /dev/rtc1 > hwclock --show --rtc /dev/rtc1 2018-11-29 17:08:00.780793-08:00 > hwclock --show --rtc /dev/rtc1 2007-12-31 16:01:20.460959-08:00 > hwclock --systohc --rtc /dev/rtc1 > hwclock --show --rtc /dev/rtc1 2018-11-29 17:08:00.780793-08:00 Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Nick Crews <ncrews@chromium.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> [Fix the sparse warning: symbol 'wilco_ec_rtc_read/write' was not declared] Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>