kernel/linux.git/drivers/rtc/rtc-cros-ec.c, branch v6.19.11

rtc: cros-ec: Avoid a couple of -Wflex-array-member-not-at-end warnings

2025-03-17T22:32:15+00:00

Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with these changes, fix the following warning: drivers/rtc/rtc-cros-ec.c:62:40: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/rtc/rtc-cros-ec.c:40:40: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/Z9PpPg06OK8ghNvm@kspp Signed-off-by: Alexandre Belloni

rtc: use boolean values with device_init_wakeup()

2025-01-09T17:29:24+00:00

device_init_wakeup() second argument is a bool type. Use proper boolean values when calling it to match the type and to produce unambiguous code which is easier to understand. Signed-off-by: Wolfram Sang Reviewed-by: Charles Keepax Reviewed-by: Andre Przywara Link: https://lore.kernel.org/r/20241217071331.3607-2-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni

rtc: Switch back to struct platform_driver::remove()

2024-11-10T21:58:28+00:00

After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/rtc to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20241007205803.444994-6-u.kleine-koenig@baylibre.com Signed-off-by: Alexandre Belloni

rtc: cros-ec: provide ID table for avoiding fallback match

2024-03-29T14:46:08+00:00

Instead of using fallback driver name match, provide ID table[1] for the primary match. [1]: https://elixir.bootlin.com/linux/v6.8/source/drivers/base/platform.c#L1353 Signed-off-by: Tzung-Bi Shih Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240329075630.2069474-4-tzungbi@kernel.org Signed-off-by: Alexandre Belloni

rtc: cros-ec: Detect and report supported alarm window size

2023-08-27T21:50:22+00:00

The RTC on some older Chromebooks can only handle alarms less than 24 hours in the future. The only way to find out is to try to set an alarm further in the future. If that fails, assume that the RTC connected to the EC can only handle less than 24 hours of alarm window, and report that value to the RTC core. After that change, it is no longer necessary to limit the alarm time when setting it. Report any excessive alarms to the caller instead. Cc: Brian Norris Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/r/20230817225537.4053865-4-linux@roeck-us.net Signed-off-by: Alexandre Belloni

rtc: cros-ec: Convert to platform remove callback returning void

2023-03-17T22:03:17+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230304133028.2135435-11-u.kleine-koenig@pengutronix.de Signed-off-by: Alexandre Belloni

rtc: cros-ec: Limit RTC alarm range if needed

2022-11-15T20:01:51+00:00

RTC chips on some older Chromebooks can only handle alarms less than 24 hours in the future. Attempts to set an alarm beyond that range fails. The most severe impact of this limitation is that suspend requests fail if alarmtimer_suspend() tries to set an alarm for more than 24 hours in the future. Try to set the real-time alarm to just below 24 hours if setting it to a larger value fails to work around the problem. While not perfect, it is better than just failing the call. A similar workaround is already implemented in the rtc-tps6586x driver. Drop error messages in cros_ec_rtc_get() and cros_ec_rtc_set() since the calling code also logs an error and to avoid spurious error messages if setting the alarm ultimately succeeds. Cc: Brian Norris Signed-off-by: Guenter Roeck Commit: Guenter Roeck Reviewed-by: Tzung-Bi Shih Reviewed-by: Brian Norris Tested-by: Brian Norris Link: https://lore.kernel.org/r/20221029005400.2712577-1-linux@roeck-us.net Signed-off-by: Alexandre Belloni

rtc: cros-ec: Only warn once in .remove() about notifier_chain problems

2022-07-26T14:43:46+00:00

When a remove platform device callback returns an error code, the driver core emits an error message ("remove callback returned a non-zero value. This will be ignored.\n") and still removes the device. As the driver already emits a more specific error message, return 0 to suppress the core's error message. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König Acked-by: Tzung-Bi Shih Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220707153156.214841-1-u.kleine-koenig@pengutronix.de

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

cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h'

2020-01-07T16:36:46+00:00

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 #include for a single include #include The changes to remove the cros_ec.h include were generated with the following shell script: git grep -l "" | xargs sed -i '//d' Signed-off-by: Enric Balletbo i Serra Acked-by: Lee Jones Acked-by: Alexandre Belloni Acked-by: Jonathan Cameron Acked-by: Sebastian Reichel Acked-by: Hans Verkuil