From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Puranjay Mohan <puranjay12@gmail.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
"Raghavendra, Vignesh" <vigneshr@ti.com>,
Suman Anna <s-anna@ti.com>,
bjorn.andersson@linaro.org, linux-remoteproc@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Puranjay Mohan <p-mohan@ti.com>
Subject: Re: [PATCH 1/2] remoteproc: Introduce deny_sysfs_ops flag
Date: Fri, 4 Feb 2022 10:03:43 -0700 [thread overview]
Message-ID: <20220204170343.GA3220193@p14s> (raw)
In-Reply-To: <CANk7y0h3EDkZqSSy_i3NCwROZOMuHCNkJDvE7s6pWuO7KWipmA@mail.gmail.com>
On Fri, Feb 04, 2022 at 01:40:23AM +0530, Puranjay Mohan wrote:
> Hi Mathieu,
>
> On Fri, Feb 4, 2022 at 12:07 AM Mathieu Poirier
> <mathieu.poirier@linaro.org> 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.
>
> I will try to figure this out.
>
> >
> > > 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 feel most use cases will require it to be read-only and not hidden,
> so, we can set mode = 0444 in place of mode = 0 below.
Perfect.
> It will make these files read-only without the extra code.
I haven't looked the specifics but even better if that is the case.
> Actually, the idea to implement is_visble() was given by Bjorn in a
> reply to the patch in the previous series[1].
>
I missed Bjorn's reply, which can happen given the high traffic on this mailing
list. And having different views on how to address problems is a good thing.
It gives us an opportunity to discuss different avenues and pick out the best
one.
> >
> > I suggest introducing a new kernel configuration options to make the attributes
>
> We want to do it dynamically and on a per driver basis, hence,
> implementing is_visble() would be apt, which can be controlled by the
> specific driver using the deny_sysfs_ops flag.
I agree that if you need that kind of granularity then a kernel configuration
option is not the right approach.
>
> > of the rproc_devgroup return -EINVAL when it is set. So in remoteproc_sysfs.c
> > do something like:
> >
> > #if CONFIG_REMOTEPROC_SYSFS_RO
> > 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())
> > 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;
>
> ^^ here we can put mode = 0444; for read-only.
>
> > > +
> > > + 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
> > >
>
> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
>
> Thanks,
> Puranjay Mohan
next prev parent reply other threads:[~2022-02-04 17:03 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 [this message]
2022-02-03 20:43 ` Bjorn Andersson
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=20220204170343.GA3220193@p14s \
--to=mathieu.poirier@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.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.