Re: cros_ec_lpcs breaking sleep mode on HP Elite Dragonfly

[Tzung-Bi Shih <tzungbi@kernel.org>]

On Tue, Mar 10, 2026 at 08:12:04AM -0700, Aaron Burton wrote:
> Apologies for the late reply. I haven't tried using ectool, though I think
> someone may have found a solution in the driver code on a Github issue
> thread I started regarding this issue using MrChromebox's firmware, so I
> wanted to relay this to you to get your thoughts.
> 
> https://github.com/MrChromebox/firmware/issues/851#issuecomment-4029188293
> 
> They claim the cros_ec_lpcs driver sends a sleep event with a sleep timeout
> of 0ms while the EC interprets it as a 10-second timeout window, which seems
> to wake the machine due to the timeout being, well, 0ms. They have posted an
> example of an out-of-tree module that adjusts this timer as the adjustment
> had been removed from debugfs in kernel 6.12. I will be testing this soon
> and report back on results.

Thanks for providing the context.

To clarify:

- The EC_HOST_SLEEP_TIMEOUT_DEFAULT (i.e. 0ms) is to tell EC to use a
  default timeout value (i.e. 10ms).

- e8bf17d58a4d ("platform/chrome: cros_ec: Expose suspend_timeout_ms in
  debugfs") opens a door for tuning the value for debug or test purpose.
  It doesn't change the behavior.

- The debugfs "suspend_timeout_ms" is still in upstream linux.

Maybe it's worth checking if your firmware interprets
EC_HOST_SLEEP_TIMEOUT_DEFAULT the same way as ChromeOS EC firmware.

> 
> On 3/5/26 8:35 AM, Tzung-Bi Shih wrote:
> > 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)?