From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Puranjay Mohan <puranjay12@gmail.com>,
kishon@ti.com, vigneshr@ti.com, s-anna@ti.com,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
Puranjay Mohan <p-mohan@ti.com>
Subject: Re: [PATCH 1/2] remoteproc: Introduce deny_sysfs_ops flag
Date: Thu, 3 Feb 2022 12:43:01 -0800 [thread overview]
Message-ID: <Yfw+VdrUJFjl6ZAQ@ripper> (raw)
In-Reply-To: <20220203183700.GB2982815@p14s>
On Thu 03 Feb 10:37 PST 2022, Mathieu Poirier wrote:
> Hi Puranjay,
>
> On Mon, Jan 31, 2022 at 07:41:51PM +0530, Puranjay Mohan wrote:
> > The remoteproc framework provides sysfs interfaces for changing
> > the firmware name and for starting/stopping a remote processor
> > through the sysfs files 'state' and 'firmware'. The 'recovery'
> > sysfs file can also be used similarly to control the error recovery
> > state machine of a remoteproc. These interfaces are currently
> > allowed irrespective of how the remoteprocs were booted (like
> > remoteproc self auto-boot, remoteproc client-driven boot etc).
> > These interfaces can adversely affect a remoteproc and its clients
> > especially when a remoteproc is being controlled by a remoteproc
> > client driver(s). Also, not all remoteproc drivers may want to
> > support the sysfs interfaces by default.
> >
> > Add support to deny the sysfs state/firmware/recovery change by
> > introducing a state flag 'deny_sysfs_ops' that the individual
> > remoteproc drivers can set based on their usage needs. The default
> > behavior is to allow the sysfs operations as before.
> >
> > Implement attribute_group->is_visible() to hide the sysfs
> > state/firmware/recovery entries when deny_sysfs_ops flag is set.
> >
>
> The address in the "To:" field of this email doesn't match the one in the SoB,
> Something that makes checkpatch angry.
>
> > Signed-off-by: Puranjay Mohan <p-mohan@ti.com>
> > ---
> > drivers/remoteproc/remoteproc_sysfs.c | 18 +++++++++++++++++-
> > include/linux/remoteproc.h | 2 ++
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
> > index ea8b89f97d7b..4a41abdd1f7b 100644
> > --- a/drivers/remoteproc/remoteproc_sysfs.c
> > +++ b/drivers/remoteproc/remoteproc_sysfs.c
> > @@ -230,6 +230,21 @@ static ssize_t name_show(struct device *dev, struct device_attribute *attr,
> > }
> > static DEVICE_ATTR_RO(name);
> >
> > +static umode_t rproc_is_visible(struct kobject *kobj, struct attribute *attr,
> > + int n)
> > +{
> > + struct device *dev = kobj_to_dev(kobj);
> > + struct rproc *rproc = to_rproc(dev);
> > + umode_t mode = attr->mode;
> > +
> > + if (rproc->deny_sysfs_ops && (attr == &dev_attr_recovery.attr ||
> > + attr == &dev_attr_firmware.attr ||
> > + attr == &dev_attr_state.attr))
>
> I toyed with this solution for a little while. I think the use case is valid
> but hiding the above options will also result in a system that is difficult to
> use (and debug) because they convey important information.
>
> I suggest introducing a new kernel configuration options to make the attributes
> of the rproc_devgroup return -EINVAL when it is set. So in remoteproc_sysfs.c
> do something like:
>
> #if CONFIG_REMOTEPROC_SYSFS_RO
We should assume that people runs the common multi_v7_defconfig for arm,
or defconfig for arm64, and still want this support.
Based on Puranjay's proposed patch I think it's also reasonable to
assume that we might have platforms with a mixture of "read-only" and
"normal" remoteprocs (e.g. some power-management uC + some DSP).
> static bool option_is_read_only()
> {
> return true;
> }
> #else
> static bool option_is_read_only()
> {
> return false;
> }
> #endif
>
> [...]
>
> static ssize_t recovery_store(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> struct rproc *rproc = to_rproc(dev);
>
> if (option_is_read_only())
struct attribute_group has a .is_visible callback which I think is
better to base this on.
Regards,
Bjorn
> return -EINVAL;
>
> if (sysfs_streq(buf, "enabled")) {
> /* change the flag and begin the recovery process if needed */
> rproc->recovery_disabled = false;
> rproc_trigger_recovery(rproc);
> } else if (sysfs_streq(buf, "disabled")) {
> rproc->recovery_disabled = true;
> } else if (sysfs_streq(buf, "recover")) {
> /* begin the recovery process without changing the flag */
> rproc_trigger_recovery(rproc);
> } else {
> return -EINVAL;
> }
>
> return count;
> }
>
> Thanks,
> Mathieu
>
> > + mode = 0;
> > +
> > + return mode;
> > +}
> > +
> > static struct attribute *rproc_attrs[] = {
> > &dev_attr_coredump.attr,
> > &dev_attr_recovery.attr,
> > @@ -240,7 +255,8 @@ static struct attribute *rproc_attrs[] = {
> > };
> >
> > static const struct attribute_group rproc_devgroup = {
> > - .attrs = rproc_attrs
> > + .attrs = rproc_attrs,
> > + .is_visible = rproc_is_visible,
> > };
> >
> > static const struct attribute_group *rproc_devgroups[] = {
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index e0600e1e5c17..3849c66ce38f 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -523,6 +523,7 @@ struct rproc_dump_segment {
> > * @table_sz: size of @cached_table
> > * @has_iommu: flag to indicate if remote processor is behind an MMU
> > * @auto_boot: flag to indicate if remote processor should be auto-started
> > + * @deny_sysfs_ops: flag to not permit sysfs operations on state, firmware and recovery
> > * @dump_segments: list of segments in the firmware
> > * @nb_vdev: number of vdev currently handled by rproc
> > * @elf_class: firmware ELF class
> > @@ -562,6 +563,7 @@ struct rproc {
> > size_t table_sz;
> > bool has_iommu;
> > bool auto_boot;
> > + bool deny_sysfs_ops;
> > struct list_head dump_segments;
> > int nb_vdev;
> > u8 elf_class;
> > --
> > 2.24.3
> >
next prev parent reply other threads:[~2022-02-03 20:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 14:11 [PATCH 0/2] remoteproc sysfs fixes/improvements Puranjay Mohan
2022-01-31 14:11 ` [PATCH 1/2] remoteproc: Introduce deny_sysfs_ops flag Puranjay Mohan
2022-02-03 18:37 ` Mathieu Poirier
2022-02-03 20:10 ` Puranjay Mohan
2022-02-04 17:03 ` Mathieu Poirier
2022-02-03 20:43 ` Bjorn Andersson [this message]
2022-02-04 13:17 ` Puranjay Mohan
2022-01-31 14:11 ` [PATCH 2/2] remoteproc: wkup_m3: Set " Puranjay Mohan
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=Yfw+VdrUJFjl6ZAQ@ripper \
--to=bjorn.andersson@linaro.org \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=p-mohan@ti.com \
--cc=puranjay12@gmail.com \
--cc=s-anna@ti.com \
--cc=vigneshr@ti.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.