Re: cros_ec_lpcs breaking sleep mode on HP Elite Dragonfly

[Tzung-Bi Shih]

On Tue, Mar 03, 2026 at 07:15:03PM -0800, Aaron Burton wrote:
> I'm reaching out in regards to an issue I've been trying to troubleshoot
> running Fedora (6.18.13-200.fc43.x86_64) on a HP Elite Dragonfly Chromebook.
> I'm aware this is not relevant to ChromeOS, but I was hoping maybe I could
> get some insight on this sleep mode issue I've been experiencing. This
> affects basically every Linux distro I've tested thus far, where if I put
> this Chromebook to sleep, it will immediately wake up. dmesg output when
> attempting sleep mode:

AFAIK, the EC drivers used in ChromeOS shouldn't diverge significantly from
the upstream kernel.

> 
> 
> [ 1478.853982] PM: suspend entry (s2idle)
> [ 1478.876379] Filesystems sync: 0.022 seconds
> [ 1478.877848] Freezing user space processes
> [ 1478.885201] Freezing user space processes completed (elapsed 0.007
> seconds)
> [ 1478.885217] OOM killer disabled.
> [ 1478.885220] Freezing remaining freezable tasks
> [ 1478.886503] Freezing remaining freezable tasks completed (elapsed 0.001
> seconds)
> [ 1478.933986] PM: Some devices failed to suspend, or early wake event
> detected
> [ 1478.961519] PM: resume devices took 0.027 seconds
> [ 1478.961978] OOM killer enabled.
> [ 1478.961980] Restarting tasks: Starting
> [ 1478.963295] Restarting tasks: Done
> [ 1478.963339] random: crng reseeded on system resumption
> [ 1478.965350] PM: suspend exit
> 
> I've tried troubleshooting via /proc/acpi/wakeup by disabling each device
> enabled one by one, then eventually everything listed, and putting it to
> sleep via systemctl suspend, the machine still wakes up instantly without
> any user input. I eventually stumbled across what was causing the issue and
> it's related to the cros_ec_lpcs kernel driver as unloading the driver
> allowed it to sleep properly, though this also has unwanted side effects
> like the power LED no longer working and some issues with USB-C ports. I'd
> like to find a proper fix for this Chromebook EC in the kernel driver,
> though I don't have much experience debugging low-level kernel drivers. I'd
> be more than happy to provide any debugging data to try to fix this issue if
> possible.

I'm not sure if this helps, but a few ideas:
- You could increase the kernel log verbosity (e.g., print DEBUG level
  messages) to identify exactly which device failed to suspend.  It's likely
  one of the cros_ec_lpc subdevices.
- Have you checked if there are any relevant logs from the EC side (e.g.,
  via ectool)?