[PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC

[PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC

[Scott Collyer]

When an attached EC or ISH device reports an EC_HOST_EVENT_PANIC host
event, the EC/ISH subsystem has encountered a fatal exception.

Handle the EC_HOST_EVENT_PANIC event by:
1. Logging an emergency message (dev_emerg) with the device name.
2. Calling the panic notifier chain (panic_notifier).
3. Emitting a uevent (ERROR=PANIC) to userspace.
4. Triggering kernel_restart("CrOS EC Panic") to cleanly restart the AP
   so that panic logs are preserved and collected by crash reporting
   services across reboot.

Signed-off-by: Scott Collyer <scollyer@google.com>
---
 drivers/platform/chrome/cros_ec.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/chrome/cros_ec.c b/drivers/platform/chrome/cros_ec.c
index 1da79e3d215b..cee7018a2d7d 100644
--- a/drivers/platform/chrome/cros_ec.c
+++ b/drivers/platform/chrome/cros_ec.c
@@ -11,11 +11,13 @@
 
 #include <linux/cleanup.h>
 #include <linux/interrupt.h>
+#include <linux/kobject.h>
 #include <linux/module.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/cros_ec_commands.h>
 #include <linux/platform_data/cros_ec_proto.h>
+#include <linux/reboot.h>
 #include <linux/slab.h>
 #include <linux/suspend.h>
 
@@ -109,8 +111,10 @@ static irqreturn_t cros_ec_irq_handler(int irq, void *data)
  */
 static bool cros_ec_handle_event(struct cros_ec_device *ec_dev)
 {
+	static const char * const panic_env[] = { "ERROR=PANIC", NULL };
 	bool wake_event;
 	bool ec_has_more_events;
+	u32 host_event;
 	int ret;
 
 	ret = cros_ec_get_next_event(ec_dev, &wake_event, &ec_has_more_events);
@@ -123,9 +127,21 @@ static bool cros_ec_handle_event(struct cros_ec_device *ec_dev)
 	if (wake_event && device_may_wakeup(ec_dev->dev))
 		pm_wakeup_event(ec_dev->dev, 0);
 
-	if (ret > 0)
+	if (ret > 0) {
+		if (ec_dev->event_data.event_type == EC_MKBP_EVENT_HOST_EVENT) {
+			host_event = cros_ec_get_host_event(ec_dev);
+			if (host_event & EC_HOST_EVENT_MASK(EC_HOST_EVENT_PANIC)) {
+				dev_emerg(ec_dev->dev, "CrOS EC Panic Reported (%s). Reboot is imminent!\n",
+					  dev_name(ec_dev->dev));
+				blocking_notifier_call_chain(&ec_dev->panic_notifier, 0, ec_dev);
+				kobject_uevent_env(&ec_dev->dev->kobj, KOBJ_CHANGE,
+						   (char **)panic_env);
+				kernel_restart("CrOS EC Panic");
+			}
+		}
 		blocking_notifier_call_chain(&ec_dev->event_notifier,
 					     0, ec_dev);
+	}
 
 	return ec_has_more_events;
 }
-- 
2.56.0.385.gd3acb90ef8-goog

Re: [PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC

[Tzung-Bi Shih]

On Thu, Oct 08, 2026 at 10:22:08AM -0700, Scott Collyer wrote:
> When an attached EC or ISH device reports an EC_HOST_EVENT_PANIC host
> event, the EC/ISH subsystem has encountered a fatal exception.
> 
> Handle the EC_HOST_EVENT_PANIC event by:
> 1. Logging an emergency message (dev_emerg) with the device name.
> 2. Calling the panic notifier chain (panic_notifier).
> 3. Emitting a uevent (ERROR=PANIC) to userspace.
> 4. Triggering kernel_restart("CrOS EC Panic") to cleanly restart the AP
>    so that panic logs are preserved and collected by crash reporting
>    services across reboot.

If the EC crashed, wouldn't the AP be reset anyway?

Re: [PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC

[Scott Collyer]

When the EC crashes, the AP will be reset as you mentioned. There is a
slight benefit for the EC case with this change in that a controlled
shutdown of the AP gets triggered. But, the primary motivation for
this change is for ISH panic handling. When the ISH resets, there is
currently nothing in place to trigger an AP reboot, and this results
in the sensor stack getting out of sync. So when the ISH panics, we
need the AP to reboot as well.

On Wed, Oct 14, 2026 at 12:17 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>
> On Thu, Oct 08, 2026 at 10:22:08AM -0700, Scott Collyer wrote:
> > When an attached EC or ISH device reports an EC_HOST_EVENT_PANIC host
> > event, the EC/ISH subsystem has encountered a fatal exception.
> >
> > Handle the EC_HOST_EVENT_PANIC event by:
> > 1. Logging an emergency message (dev_emerg) with the device name.
> > 2. Calling the panic notifier chain (panic_notifier).
> > 3. Emitting a uevent (ERROR=PANIC) to userspace.
> > 4. Triggering kernel_restart("CrOS EC Panic") to cleanly restart the AP
> >    so that panic logs are preserved and collected by crash reporting
> >    services across reboot.
>
> If the EC crashed, wouldn't the AP be reset anyway?

Re: [PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC

[Tzung-Bi Shih]

On Wed, Oct 14, 2026 at 01:57:22PM -0700, Scott Collyer wrote:
> Yes, if the EC crashed, the the AP will be reset. There is a slight benefit
> for the EC case in that a controlled shutdown gets triggered. But, the
> primary motivation for this change is to trigger an AP reset if the ISH
> panics. If the ISH panics, there isn't any trigger currently to reboot the
> AP and this leads to the sensor stack being out of sync.

Please don't top-posting [1].

I don't think this is the right approach, given that:
- cros_ec_handle_event() is a generic event dispatcher for all EC
  instances, not a place for device-specific event handling.
- The ISH driver or sensor stack should re-establish the state after an
  ISH panic rather than rebooting the AP.

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions

> 
> On Wed, Oct 14, 2026 at 12:17 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> 
> > On Thu, Oct 08, 2026 at 10:22:08AM -0700, Scott Collyer wrote:
> > > When an attached EC or ISH device reports an EC_HOST_EVENT_PANIC host
> > > event, the EC/ISH subsystem has encountered a fatal exception.
> > >
> > > Handle the EC_HOST_EVENT_PANIC event by:
> > > 1. Logging an emergency message (dev_emerg) with the device name.
> > > 2. Calling the panic notifier chain (panic_notifier).
> > > 3. Emitting a uevent (ERROR=PANIC) to userspace.
> > > 4. Triggering kernel_restart("CrOS EC Panic") to cleanly restart the AP
> > >    so that panic logs are preserved and collected by crash reporting
> > >    services across reboot.
> >
> > If the EC crashed, wouldn't the AP be reset anyway?
> >

Re: [PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC

[Scott Collyer]

On Sun, Oct 18, 2026 at 7:50 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
    > Please don't top-posting [1].
    >
    > [1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#use-trimmed-interleaved-replies-in-
  email-discussions

    Understood, apologies for the top-posting.

    > I don't think this is the right approach, given that:
    > - cros_ec_handle_event() is a generic event dispatcher for all EC
    >   instances, not a place for device-specific event handling.
    > - The ISH driver or sensor stack should re-establish the state after an
    >   ISH panic rather than rebooting the AP.

    That makes sense—the kernel should not dictate system reboot
policy for a peripheral,
    and cros_ec_handle_event() should remain a generic event dispatcher.

    We would like to drop kernel_restart() entirely and instead focus only on
    surfacing the EC_HOST_EVENT_PANIC event so that userspace crash reporting
    daemons can collect the panic dump and handle recovery policy.

    Specifically, for non-ACPI/LPC transports (e.g. MKBP host events
over ISHTP/SPI),
    we would:
    1. Register a subscriber on ec_dev->event_notifier (e.g., in cros_ec_dev) to
       listen for EC_HOST_EVENT_PANIC.
    2. Trigger the existing ec_dev->panic_notifier chain so debugfs flushes any
       pending console logs.
    3. Emit a kobject_uevent (e.g. ERROR=PANIC) on the cros_ec device kobject to
       notify userspace crash collectors.

    Does this separation of mechanism and policy align with what you'd like to
    see upstream? If so, would you prefer the event notifier subscriber in
    cros_ec_dev, or is there another location you'd recommend?

Re: [PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC

[Tzung-Bi Shih]

On Mon, Oct 19, 2026 at 03:12:37PM -0700, Scott Collyer wrote:
> On Sun, Oct 18, 2026 at 7:50 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>     We would like to drop kernel_restart() entirely and instead focus only on
>     surfacing the EC_HOST_EVENT_PANIC event so that userspace crash reporting
>     daemons can collect the panic dump and handle recovery policy.
> 
>     Specifically, for non-ACPI/LPC transports (e.g. MKBP host events
> over ISHTP/SPI),
>     we would:
>     1. Register a subscriber on ec_dev->event_notifier (e.g., in cros_ec_dev) to
>        listen for EC_HOST_EVENT_PANIC.
>     2. Trigger the existing ec_dev->panic_notifier chain so debugfs flushes any
>        pending console logs.
>     3. Emit a kobject_uevent (e.g. ERROR=PANIC) on the cros_ec device kobject to
>        notify userspace crash collectors.
> 
>     Does this separation of mechanism and policy align with what you'd like to
>     see upstream? If so, would you prefer the event notifier subscriber in
>     cros_ec_dev, or is there another location you'd recommend?

IIUC, this patch is specifically for ISHTP.  I'd expect cros_ec_ishtp.c
to register the event notifier and check if the incoming event is
EC_HOST_EVENT_PANIC.