From: Stephen Boyd <swboyd@chromium.org>
To: dikshita@codeaurora.org
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, jim.cromie@gmail.com,
Joe Perches <joe@perches.com>, Jason Baron <jbaron@akamai.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media-owner@vger.kernel.org,
Akinobu Mita <akinobu.mita@gmail.com>
Subject: Re: [PATCH v5 2/3] venus: Add a debugfs file for SSR trigger
Date: Wed, 15 Sep 2021 12:39:42 -0700 [thread overview]
Message-ID: <CAE-0n53T-RoOvR=s9nHiXAriMgKvBfDqfBfoGKX5Ju5YF3Tcqw@mail.gmail.com> (raw)
In-Reply-To: <8c1fdf2d0807f07ec57b232497b405f1@codeaurora.org>
Quoting dikshita@codeaurora.org (2021-09-15 02:13:09)
> Hi Stephen,
>
> Reviving the discussion on this change as we need to pull this in.
>
> As per your suggestion, I explored the fault injection framework to
> implement this functionality.
> But I don't think that meets our requirements.
>
> We need a way to trigger subsystem restart from the client-side, it's
> not derived from the driver.
Just to confirm, this is all for debugging purposes right?
>
> while fault injection framework enables the driver to trigger an
> injection
> when a specific event occurs for eg: page allocation failure or memory
> access failure.
>
> So, IMO, we will have to use custom debugfs only.
Can you use DECLARE_FAULT_ATTR()? Or you need it to be active instead of
passive, i.e. it shouldn't wait for should_fail() to return true, but
actively trigger something on the remoteproc?
>
> Please feel free to correct me in case my understanding of the framework
> is wrong.
>
I presume the fault injection framework could get a new feature that
lets the fault be injected immediately upon writing the debugfs file.
My goal is to consolidate this sort of logic into one place and then put
it behind some config option that distros can disable so the kernel
isn't bloated with debug features that end users will never care about.
next prev parent reply other threads:[~2021-09-15 19:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 9:53 [PATCH v5 0/3] Venus dynamic debug Stanimir Varbanov
2020-07-30 9:53 ` [PATCH v5 1/3] venus: Add debugfs interface to set firmware log level Stanimir Varbanov
2020-07-30 9:53 ` [PATCH v5 2/3] venus: Add a debugfs file for SSR trigger Stanimir Varbanov
2020-08-11 21:49 ` Stephen Boyd
2021-09-15 9:13 ` dikshita
2021-09-15 19:39 ` Stephen Boyd [this message]
2021-09-16 6:29 ` dikshita
2021-09-17 6:18 ` Stephen Boyd
2021-09-20 5:48 ` dikshita
2020-07-30 9:53 ` [PATCH v5 3/3] venus: Make debug infrastructure more flexible Stanimir Varbanov
2020-08-21 10:51 ` [PATCH v5 0/3] Venus dynamic debug Stanimir Varbanov
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='CAE-0n53T-RoOvR=s9nHiXAriMgKvBfDqfBfoGKX5Ju5YF3Tcqw@mail.gmail.com' \
--to=swboyd@chromium.org \
--cc=akinobu.mita@gmail.com \
--cc=dikshita@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=jbaron@akamai.com \
--cc=jim.cromie@gmail.com \
--cc=joe@perches.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media-owner@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=stanimir.varbanov@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).