From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Joe Talbott <joetalbott@gmail.com>, <linux-iio@vger.kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] iio: Prefer octal over symbolic permissions.
Date: Tue, 31 May 2022 10:56:47 +0100 [thread overview]
Message-ID: <20220531105647.00006c00@Huawei.com> (raw)
In-Reply-To: <CAL7gdfeoRM8APfLL77bbGiWWBa0qOF8g0rza+=7hCdo+jaYNLQ@mail.gmail.com>
On Sun, 29 May 2022 10:08:21 -0400
Joe Talbott <joetalbott@gmail.com> wrote:
> On Sat, May 28, 2022 at 1:25 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Fri, 27 May 2022 14:56:52 -0400
> > Joe Simmons-Talbott <joetalbott@gmail.com> wrote:
> >
> > > As reported by checkpatch.pl use ocatl permissions rather than symbolic
> > > permissions.
> > >
> > > Signed-off-by: Joe Simmons-Talbott <joetalbott@gmail.com>
> >
> > Hi Joe,
> >
> > Why the resend? Given change of description, I'm guessing this is v2
> > because of feedback on a similar patch elsewhere. If so, please
> > put the version number in the patch log and provide a changelog
> > below the ---
>
>
> I sent the patch again because I neglected to include linux-kernel and
> you in the
> original patch's recipients. I wasn't sure if I should include the v2
> but will in the future.
For that case, common choice is [RESEND PATCH ....
with a brief note in the cover letter that you missed some to/cc
> Should I use v3 for my updated patch?
v2 is fine given v2 doesn't yet exist - v3 also fine though...
Jonathan
>
> Thanks,
> Joe
>
> >
> >
> > Hmm. I guess I don't really mind cleaning this up though it is
> > some churn in core code which is usually something we try to avoid
> > for fairly trivial style reasons.
> >
> > One request inline (though I suspect it applies in several places,
> > I just haven't checked ;)
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > drivers/iio/industrialio-buffer.c | 12 ++++++------
> > > drivers/iio/industrialio-core.c | 10 +++++-----
> > > drivers/iio/industrialio-trigger.c | 4 ++--
> > > 3 files changed, 13 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> > > index b078eb2f3c9d..c27f74a3c0f3 100644
> > > --- a/drivers/iio/industrialio-buffer.c
> > > +++ b/drivers/iio/industrialio-buffer.c
> > > @@ -1391,17 +1391,17 @@ static ssize_t direction_show(struct device *dev,
> > > }
> > > }
> > >
> > > -static DEVICE_ATTR(length, S_IRUGO | S_IWUSR, iio_buffer_read_length,
> > > +static DEVICE_ATTR(length, 0644, iio_buffer_read_length,
> > > iio_buffer_write_length);
> > > static struct device_attribute dev_attr_length_ro = __ATTR(length,
> > > - S_IRUGO, iio_buffer_read_length, NULL);
> > > -static DEVICE_ATTR(enable, S_IRUGO | S_IWUSR,
> > > + 0444, iio_buffer_read_length, NULL);
> > > +static DEVICE_ATTR(enable, 0644,
> > > iio_buffer_show_enable, iio_buffer_store_enable);
> > > -static DEVICE_ATTR(watermark, S_IRUGO | S_IWUSR,
> > > +static DEVICE_ATTR(watermark, 0644,
> > > iio_buffer_show_watermark, iio_buffer_store_watermark);
> > > static struct device_attribute dev_attr_watermark_ro = __ATTR(watermark,
> > > - S_IRUGO, iio_buffer_show_watermark, NULL);
> > > -static DEVICE_ATTR(data_available, S_IRUGO,
> > > + 0444, iio_buffer_show_watermark, NULL);
> > > +static DEVICE_ATTR(data_available, 0444,
> > > iio_dma_show_data_available, NULL);
> >
> > a side effect of this change a slight shortening of how long the above
> > two lines will be if combined into one. It's now sub 80 chars
> > I think, so please make them a single line. Also check for similar
> > cases elsewhere.
> >
> >
> > > static DEVICE_ATTR_RO(direction);
> > >
> > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > index e1ed44dec2ab..35de348d686e 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -1114,12 +1114,12 @@ int __iio_device_attr_init(struct device_attribute *dev_attr,
> > > dev_attr->attr.name = name;
> > >
> > > if (readfunc) {
> > > - dev_attr->attr.mode |= S_IRUGO;
> > > + dev_attr->attr.mode |= 0444;
> > > dev_attr->show = readfunc;
> > > }
> > >
> > > if (writefunc) {
> > > - dev_attr->attr.mode |= S_IWUSR;
> > > + dev_attr->attr.mode |= 0200;
> > > dev_attr->store = writefunc;
> > > }
> > >
> > > @@ -1401,7 +1401,7 @@ static ssize_t iio_show_dev_name(struct device *dev,
> > > return sysfs_emit(buf, "%s\n", indio_dev->name);
> > > }
> > >
> > > -static DEVICE_ATTR(name, S_IRUGO, iio_show_dev_name, NULL);
> > > +static DEVICE_ATTR(name, 0444, iio_show_dev_name, NULL);
> > >
> > > static ssize_t iio_show_dev_label(struct device *dev,
> > > struct device_attribute *attr,
> > > @@ -1411,7 +1411,7 @@ static ssize_t iio_show_dev_label(struct device *dev,
> > > return sysfs_emit(buf, "%s\n", indio_dev->label);
> > > }
> > >
> > > -static DEVICE_ATTR(label, S_IRUGO, iio_show_dev_label, NULL);
> > > +static DEVICE_ATTR(label, 0444, iio_show_dev_label, NULL);
> > >
> > > static ssize_t iio_show_timestamp_clock(struct device *dev,
> > > struct device_attribute *attr,
> > > @@ -1509,7 +1509,7 @@ int iio_device_register_sysfs_group(struct iio_dev *indio_dev,
> > > return 0;
> > > }
> > >
> > > -static DEVICE_ATTR(current_timestamp_clock, S_IRUGO | S_IWUSR,
> > > +static DEVICE_ATTR(current_timestamp_clock, 0644,
> > > iio_show_timestamp_clock, iio_store_timestamp_clock);
> > >
> > > static int iio_device_register_sysfs(struct iio_dev *indio_dev)
> > > diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
> > > index f504ed351b3e..e22a35634f2c 100644
> > > --- a/drivers/iio/industrialio-trigger.c
> > > +++ b/drivers/iio/industrialio-trigger.c
> > > @@ -54,7 +54,7 @@ static ssize_t iio_trigger_read_name(struct device *dev,
> > > return sysfs_emit(buf, "%s\n", trig->name);
> > > }
> > >
> > > -static DEVICE_ATTR(name, S_IRUGO, iio_trigger_read_name, NULL);
> > > +static DEVICE_ATTR(name, 0444, iio_trigger_read_name, NULL);
> > >
> > > static struct attribute *iio_trig_dev_attrs[] = {
> > > &dev_attr_name.attr,
> > > @@ -494,7 +494,7 @@ static ssize_t iio_trigger_write_current(struct device *dev,
> > > return ret;
> > > }
> > >
> > > -static DEVICE_ATTR(current_trigger, S_IRUGO | S_IWUSR,
> > > +static DEVICE_ATTR(current_trigger, 0644,
> > > iio_trigger_read_current,
> > > iio_trigger_write_current);
> > >
> >
next prev parent reply other threads:[~2022-05-31 9:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-27 18:56 [PATCH 1/1] iio: Prefer octal over symbolic permissions Joe Simmons-Talbott
2022-05-28 17:34 ` Jonathan Cameron
2022-05-28 17:36 ` Joe Perches
2022-05-29 14:08 ` Joe Talbott
2022-05-31 9:56 ` Jonathan Cameron [this message]
2022-06-01 14:09 ` Joe Simmons-Talbott
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=20220531105647.00006c00@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=jic23@kernel.org \
--cc=joetalbott@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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.