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@xxxxxxxxxx> 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?