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

Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of
a flexible structure where the size of the flexible-array mem

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

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 <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/Z9PpPg06OK8ghNvm@kspp
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: use boolean values with device_init_wakeup()

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
whi

rtc: use boolean values with device_init_wakeup()

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 <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

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

After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platf

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

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

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

Instead of using fallback driver name match, provide ID table[1] for the
primary match.

[1]: https://elixir.bootlin.com/linux/v6.8/source/

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

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 <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

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

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 al

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

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 <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

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

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error

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

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 <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

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

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

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

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 <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Commit: Guenter Roeck <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Tested-by: Brian Norris <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

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

When a remove platform device callback returns an error code, the driver
core emits an error message ("remove callback returne

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

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 <[email protected]>
Acked-by: Tzung-Bi Shih <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: rework rtc_register_device() resource management

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

rtc: rework rtc_register_device() resource management

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 <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

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

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 defi

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

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 <[email protected]>
Acked-by: Lee Jones <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Acked-by: Sebastian Reichel <[email protected]>
Acked-by: Hans Verkuil <[email protected]>

show more ...

rtc: cros-ec: let the core handle rtc range

Let the rtc core check the date/time against the RTC range.

Reviewed-by: Enric Balletbo i Serra <[email protected]>
Link: https://lore.kernel.

rtc: cros-ec: let the core handle rtc range

Let the rtc core check the date/time against the RTC range.

Reviewed-by: Enric Balletbo i Serra <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: cros-ec: remove superfluous error message

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 Ballet

rtc: cros-ec: remove superfluous error message

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

mfd / platform: cros_ec: Reorganize platform and mfd includes

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
expor

mfd / platform: cros_ec: Reorganize platform and mfd includes

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 <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Acked-by: Benjamin Tissoires <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Sebastian Reichel <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Reviewed-by: Gwendal Grignou <[email protected]>
Tested-by: Gwendal Grignou <[email protected]>
Series changes: 3
- Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp)
Signed-off-by: Lee Jones <[email protected]>

show more ...

rtc: cros-ec: Fail suspend/resume if wake IRQ can't be configured

If we encounter a failure during suspend where this RTC was programmed
to wakeup the system from suspend, but that wakeup couldn't b

rtc: cros-ec: Fail suspend/resume if wake IRQ can't be configured

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 <[email protected]>
Cc: Evan Green <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Acked-By: Benson Leung <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: cros-ec: Switch to SPDX identifier.

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed

rtc: cros-ec: Switch to SPDX identifier.

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: cros-ec: Make license text and module license match.

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

rtc: cros-ec: Make license text and module license match.

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 <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: cros-ec: return -ETIME when refused to set alarms in the past

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

rtc: cros-ec: return -ETIME when refused to set alarms in the past

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 <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Tested-by: Brian Norris <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: cros-ec: add cros-ec-rtc driver.

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@chro

rtc: cros-ec: add cros-ec-rtc driver.

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 <[email protected]>
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Benson Leung <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Tested-by: Brian Norris <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...