kernel/drivers/platform/chrome/cros_ec.c, branch linux-6.9.y

platform/chrome: cros_ec: Handle events during suspend after resume completion

2024-06-16T11:50:56Z

commit 2fbe479c0024e1c6b992184a799055e19932aa48 upstream. Commit 47ea0ddb1f56 ("platform/chrome: cros_ec_lpc: Separate host command and irq disable") re-ordered the resume sequence. Before that change, cros_ec resume sequence is: 1) Enable IRQ 2) Send resume event 3) Handle events during suspend After commit 47ea0ddb1f56 ("platform/chrome: cros_ec_lpc: Separate host command and irq disable"), cros_ec resume sequence is: 1) Enable IRQ 2) Handle events during suspend 3) Send resume event. This re-ordering leads to delayed handling of any events queued between items 2) and 3) with the updated sequence. Also in certain platforms, EC skips triggering interrupt for certain events eg. mkbp events until the resume event is received. Such events are stuck in the host event queue indefinitely. This change puts back the original order to avoid any delay in handling the pending events. Fixes: 47ea0ddb1f56 ("platform/chrome: cros_ec_lpc: Separate host command and irq disable") Cc: Cc: Lalith Rajendran Cc: Signed-off-by: Karthikeyan Ramasubramanian Link: https://lore.kernel.org/r/20240429121343.v2.1.If2e0cef959f1f6df9f4d1ab53a97c54aa54208af@changeid Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman

platform/chrome: cros_ec_lpc: Separate host command and irq disable

2023-10-28T03:13:25Z

Both cros host command and irq disable were moved to suspend prepare stage from late suspend recently. This is causing EC to report MKBP event timeouts during suspend stress testing. When the MKBP event timeouts happen during suspend, subsequent wakeup of AP by EC using MKBP doesn't happen properly. Move the irq disabling part back to late suspend stage which is a general suggestion from the suspend kernel documentaiton to do irq disable as late as possible. Fixes: 4b9abbc132b8 ("platform/chrome: cros_ec_lpc: Move host command to prepare/complete") Signed-off-by: Lalith Rajendran Link: https://lore.kernel.org/r/20231027160221.v4.1.I1725c3ed27eb7cd9836904e49e8bfa9fb0200a97@changeid Signed-off-by: Tzung-Bi Shih

platform: Explicitly include correct DT includes

2023-07-26T08:58:36Z

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230714174909.4062739-1-robh@kernel.org Signed-off-by: Hans de Goede

platform/chrome: cros_ec: remove unneeded label and if-condition

2023-04-24T05:35:11Z

Both `ec_dev->ec` and `ec_dev->pd` are initialized to NULL at the beginning of cros_ec_register(). Also, platform_device_unregister() takes care if the given platform_device is NULL. Remove the unneeded goto-label and if-condition. Signed-off-by: Tzung-Bi Shih Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230308031247.2866401-1-tzungbi@kernel.org

platform/chrome: cros_ec: Use per-device lockdep key

2023-01-13T01:30:50Z

Lockdep reports a bogus possible deadlock on MT8192 Chromebooks due to the following lock sequences: 1. lock(i2c_register_adapter) [1]; lock(&ec_dev->lock) 2. lock(&ec_dev->lock); lock(prepare_lock); The actual dependency chains are much longer. The shortened version looks somewhat like: 1. cros-ec-rpmsg on mtk-scp ec_dev->lock -> prepare_lock 2. In rt5682_i2c_probe() on native I2C bus: prepare_lock -> regmap->lock -> (possibly) i2c_adapter->bus_lock 3. In rt5682_i2c_probe() on native I2C bus: regmap->lock -> i2c_adapter->bus_lock 4. In sbs_probe() on i2c-cros-ec-tunnel I2C bus attached on cros-ec: i2c_adapter->bus_lock -> ec_dev->lock While lockdep is correct that the shared lockdep classes have a circular dependency, it is bogus because a) 2+3 happen on a native I2C bus b) 4 happens on the actual EC on ChromeOS devices c) 1 happens on the SCP coprocessor on MediaTek Chromebooks that just happens to expose a cros-ec interface, but does not have an i2c-cros-ec-tunnel I2C bus In short, the "dependencies" are actually on different devices. Setup a per-device lockdep key for cros_ec devices so lockdep can tell the two instances apart. This helps with getting rid of the bogus lockdep warning. For ChromeOS devices that only have one cros-ec instance this doesn't change anything. Also add a missing mutex_destroy, just to make the teardown complete. [1] This is likely the per I2C bus lock with shared lockdep class Signed-off-by: Chen-Yu Tsai Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230111074146.2624496-1-wenst@chromium.org

platform/chrome: cros_ec: Fix panic notifier registration

2023-01-11T03:27:56Z

Initialize panic notifier to avoid the following lockdep warning: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. [...] Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack [...] blocking_notifier_chain_register from cros_ec_debugfs_probe cros_ec_debugfs_probe from platform_probe Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Marek Szyprowski [tzungbi: trimmed the stack trace in commit message.] Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230110221033.7441-1-m.szyprowski@samsung.com

platform/chrome: cros_ec: Notify the PM of wake events during resume

2022-09-19T02:34:38Z

cros_ec_handle_event in the cros_ec driver can notify the PM of wake events. When a device is suspended, cros_ec_handle_event will not check MKBP events. Instead, received MKBP events are checked during resume by cros_ec_report_events_during_suspend. But cros_ec_report_events_during_suspend cannot notify the PM if received events are wake events, causing wake events to not be reported if received while the device is suspended. Update cros_ec_report_events_during_suspend to notify the PM of wake events during resume by calling pm_wakeup_event. Signed-off-by: Jameson Thies Reviewed-by: Prashant Malani Reviewed-by: Benson Leung Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20220913204954.2931042-1-jthies@google.com

platform/chrome: cros_ec: Expose suspend_timeout_ms in debugfs

2022-08-24T02:37:07Z

In modern Chromebooks, the embedded controller has a mechanism where it will watch a hardware-controlled line that toggles in suspend, and wake the system up if an expected sleep transition didn't occur. This can be very useful for detecting power management issues where the system appears to suspend, but doesn't actually reach its lowest expected power states. Sometimes it's useful in debug and test scenarios to be able to control the duration of that timeout, or even disable the EC timeout mechanism altogether. Add a debugfs control to set the timeout to values other than the EC-defined default, for more convenient debug and development iteration. Signed-off-by: Evan Green Reviewed-by: Prashant Malani Reviewed-by: Stephen Boyd Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20220822144026.v3.1.Idd188ff3f9caddebc17ac357a13005f93333c21f@changeid [tzungbi: fix one nit in Documentation/ABI/testing/debugfs-cros-ec.] Signed-off-by: Tzung-Bi Shih

platform/chrome: cros_ec: Always expose last resume result

2022-06-14T08:18:18Z

The last resume result exposing logic in cros_ec_sleep_event() incorrectly requires S0ix support, which doesn't work on ARM based systems where S0ix doesn't exist. That's because cros_ec_sleep_event() only reports the last resume result when the EC indicates the last sleep event was an S0ix resume. On ARM systems, the last sleep event is always S3 resume, but the EC can still detect sleep hang events in case some other part of the AP is blocking sleep. Always expose the last resume result if the EC supports it so that this works on all devices regardless of S0ix support. This fixes sleep hang detection on ARM based chromebooks like Trogdor. Cc: Rajat Jain Cc: Matthias Kaehlcke Cc: Hsin-Yi Wang Cc: Tzung-Bi Shih Reviewed-by: Guenter Roeck Reviewed-by: Evan Green Fixes: 7235560ac77a ("platform/chrome: Add support for v1 of host sleep event") Signed-off-by: Stephen Boyd Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20220614075726.2729987-1-swboyd@chromium.org

platform/chrome: use macros for passthru indexes

2022-06-10T02:31:42Z

Move passthru indexes for EC and PD devices to common header. Also use them instead of literal constants. Reviewed-by: Guenter Roeck Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20220609084957.3684698-4-tzungbi@kernel.org