From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Scott Collyer <scollyer@google.com>
Cc: Benson Leung <bleung@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC
Date: Mon, 19 Oct 2026 02:50:43 +0000 [thread overview]
Message-ID: <atWFg7gm_jLBOwxu@google.com> (raw)
In-Reply-To: <CALUcz=3WE+SUx2j8LKFQQK-fMVXdk69rZJ9nKgBMQ_UwnWRPSA@mail.gmail.com>
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?
> >
next prev parent reply other threads:[~2026-10-19 2:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 17:22 [PATCH] platform/chrome: cros_ec: trigger kernel_restart on EC_HOST_EVENT_PANIC Scott Collyer
2026-10-14 7:17 ` Tzung-Bi Shih
2026-10-14 21:30 ` Scott Collyer
[not found] ` <CALUcz=3WE+SUx2j8LKFQQK-fMVXdk69rZJ9nKgBMQ_UwnWRPSA@mail.gmail.com>
2026-10-19 2:50 ` Tzung-Bi Shih [this message]
2026-10-19 22:12 ` Scott Collyer
2026-10-20 0:44 ` Tzung-Bi Shih
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atWFg7gm_jLBOwxu@google.com \
--to=tzungbi@kernel.org \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=groeck@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scollyer@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.