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

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/chrome: cros_ec_lpc: Convert to platform remove callback returning void

2023-09-28T05:18:06Z

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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230927081040.2198742-5-u.kleine-koenig@pengutronix.de Signed-off-by: Tzung-Bi Shih

platform/chrome: cros_ec_lpc: Remove EC panic shutdown timeout

2023-08-07T02:39:16Z

Remove the 1 second timeout applied to hw_protection_shutdown after an EC panic. On some platforms this 1 second timeout is insufficient to allow the filesystem to fully sync. Independently the EC will force a full system reset after a short period. So this backup timeout is unnecessary. Signed-off-by: Rob Barnes Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230802175847.1.Ie9fc53b6a1f4c6661c5376286a50e0cf51b3e961@changeid Signed-off-by: Tzung-Bi Shih

platform/chrome: cros_ec_lpc: Move host command to prepare/complete

2023-05-22T01:54:36Z

Update cros_ec_lpc_pm_ops to call cros_ec_lpc_prepare() during PM .prepare() and cros_ec_lpc_complete() during .complete(). This moves the host command that the AP sends and allows the EC to log entry/exit of AP's suspend/resume more accurately. Reviewed-by: Raul E Rangel Signed-off-by: Tim Van Patten Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230515142552.1.I17cae37888be3a8683911991602f18e482e7a621@changeid

platform/chrome: cros_ec: Report EC panic as uevent

2023-05-15T03:55:41Z

Create a uevent when an EC panic is detected. This will allow udev rules to trigger when a panic occurs. For example, a udev rule could be added to capture an EC coredump. This approach avoids the need to stuff all the processing into the driver. Signed-off-by: Rob Barnes Reviewed-by: Prashant Malani Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230509232624.3120347-1-robbarnes@google.com

platform/chrome: cros_ec_lpc: initialize the buf variable

2023-01-11T03:27:56Z

Clang static analysis reports this problem drivers/platform/chrome/cros_ec_lpc.c:379:13: warning: The left operand of '!=' is a garbage value [core.UndefinedBinaryOperatorResult] if (buf[0] != 'E' || buf[1] != 'C') { ~~~~~~ ^ The check depends on the side effect of the read. When the read fails or is short, a buf containing garbage could be mistaken as correct. Signed-off-by: Tom Rix Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230110193611.3573777-1-trix@redhat.com

platform/chrome: cros_ec: Shutdown on EC Panic

2023-01-06T03:48:06Z

When an EC panic is reported, attempt an orderly shutdown. Force a shutdown after a brief timeout if the orderly shutdown fails for any reason. Using the common hw_protection_shutdown utility function since an EC panic has the potential to cause hw damage. This is all best effort. EC should also force a hard reset after a short timeout. Signed-off-by: Rob Barnes Reviewed-by: Prashant Malani Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230104011524.369764-3-robbarnes@google.com

platform/chrome: cros_ec: Poll EC log on EC panic

2023-01-06T03:48:06Z

Add handler for CrOS EC panic events. When a panic is reported, immediately poll for EC log. This should result in the log leading to the EC panic being preserved. ACPI_NOTIFY_CROS_EC_PANIC is defined in coreboot at https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/ec/google/chromeec/acpi/ec.asl Signed-off-by: Rob Barnes Reviewed-by: Prashant Malani Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230104011524.369764-2-robbarnes@google.com

platform/chrome: cros_ec_lpc: Force synchronous probe

2022-11-14T02:26:46Z

This reverts commit bd88b965ae8c ("platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUS"), and then some. It has been reported that there are issues with 'cros-ec-keyb' devices that are children of this. As noted in the initial patch for its ACPI support (commit ba0f32141bc5 ("Input: cros_ec_keyb - handle x86 detachable/convertible Chromebooks")), it's possible to probe an ACPI child device before its parent is probed -- hence the need for EPROBE_DEFER. Unfortunately, poking your parent's dev_get_drvdata() isn't safe with asynchronous probe, as there's no locking, and the ordering is all wrong anyway (drvdata is set before the device is *really* ready). Because this parent/child relationship has known issues, let's go the other direction and force synchronous probe, until we resolve the issues. Possible solutions involve adding device links, so we ensure the child doesn't probe before the parent is done; or perhaps some other larger refactoring (auxiliary bus?). But that might take a little more effort and review, as there are many other potential sub-devices of cros_ec_lpc that could need patching. Note that we don't have the same problem for non-ACPI cros-ec hosts, like cros-ec-spi (commit 015e4b05c377 ("platform/chrome: cros_ec_spi: Set PROBE_PREFER_ASYNCHRONOUS")), because its sub-devices aren't created until cros_ec_register(), or they don't exist at all (e.g., FPMCU uses). Fixes: bd88b965ae8c ("platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUS") Signed-off-by: Brian Norris Reviewed-by: Dmitry Torokhov Reviewed-by: Guenter Roeck Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20221111231302.3458191-1-briannorris@chromium.org

platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUS

2022-11-02T04:28:47Z

This takes on the order of 60ms to probe on some systems, so let it probe asynchronously. It shouldn't have any dependencies that aren't handled cleanly. Signed-off-by: Brian Norris Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20221101152132.v2.2.Ib1036816e77aba71ebc16b71f7615c55d054689c@changeid