From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Joe Simmons-Talbott <joetalbott@gmail.com>,
linux-iio <linux-iio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Joe Perches <joe@perches.com>
Subject: Re: [PATCH v3] iio: Use octal permissions and DEVICE_ATTR_{RO,RW}.
Date: Tue, 14 Jun 2022 11:35:22 +0100 [thread overview]
Message-ID: <20220614113522.432ebca8@jic23-huawei> (raw)
In-Reply-To: <CAHp75Vd79=x93KgqcR3coYHUbHiHwyYTagOuKki54omEPx64jA@mail.gmail.com>
On Wed, 1 Jun 2022 21:02:52 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Wed, Jun 1, 2022 at 8:54 PM Joe Simmons-Talbott <joetalbott@gmail.com> wrote:
> >
> > As reported by checkpatch.pl. Where possible use DEVICE_ATTR_RO(),
> > DEVICE_ATTR_RW(), and __ATTR_RO(). Change function names to be
> > <var>_show() for read and <var>_store() for write.
>
> Thank you for an update!
> I have a few nit-picks, but no need to resend, I believe Jonathan may
> (or may not :) modify when applying.
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> > Suggested-by: Joe Perches <joe@perches.com>
> > Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Signed-off-by: Joe Simmons-Talbott <joetalbott@gmail.com>
> > +static ssize_t watermark_store(struct device *dev,
> > + struct device_attribute *attr,
>
> Ditto.
Nope. 81 chars ;)
>
> > + const char *buf,
> > + size_t len)
>
> Ditto.
>
> > {
> > struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > struct iio_buffer *buffer = to_iio_dev_attr(attr)->buffer;
> > @@ -1366,9 +1366,9 @@ static ssize_t iio_buffer_store_watermark(struct device *dev,
> > return ret ? ret : len;
> > }
> >
> > -static ssize_t iio_dma_show_data_available(struct device *dev,
> > - struct device_attribute *attr,
> > - char *buf)
> > +static ssize_t data_available_show(struct device *dev,
> > + struct device_attribute *attr,
>
> Ditto.
Nope, well over 80, but pulling char *buf up to previous line fits nicely.
>
> > + char *buf)
...
> > diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
> > index f504ed351b3e..21f113c0ee96 100644
> > --- a/drivers/iio/industrialio-trigger.c
> > +++ b/drivers/iio/industrialio-trigger.c
> > @@ -37,7 +37,7 @@ static LIST_HEAD(iio_trigger_list);
> > static struct attribute *iio_trig_dev_attrs[] = {
> > &dev_attr_name.attr,
> > @@ -395,7 +395,7 @@ void iio_dealloc_pollfunc(struct iio_poll_func *pf)
> > EXPORT_SYMBOL_GPL(iio_dealloc_pollfunc);
> >
> > /**
> > - * iio_trigger_read_current() - trigger consumer sysfs query current trigger
> > + * current_trigger_show() - trigger consumer sysfs query current trigger
> > * @dev: device associated with an industrial I/O device
> > * @attr: pointer to the device_attribute structure that
> > * is being processed
> > @@ -407,9 +407,9 @@ EXPORT_SYMBOL_GPL(iio_dealloc_pollfunc);
> > * Return: a negative number on failure, the number of characters written
> > * on success or 0 if no trigger is available
> > */
> > -static ssize_t iio_trigger_read_current(struct device *dev,
> > - struct device_attribute *attr,
> > - char *buf)
> > +static ssize_t current_trigger_show(struct device *dev,
> > + struct device_attribute *attr,
>
> Ditto.
Nope, but dragging char *buf up to previous line is good.
>
> > + char *buf)
> > {
> > struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> >
> > @@ -419,7 +419,7 @@ static ssize_t iio_trigger_read_current(struct device *dev,
> > }
> >
> > /**
> > - * iio_trigger_write_current() - trigger consumer sysfs set current trigger
> > + * current_trigger_store() - trigger consumer sysfs set current trigger
> > * @dev: device associated with an industrial I/O device
> > * @attr: device attribute that is being processed
> > * @buf: string buffer that holds the name of the trigger
> > @@ -432,10 +432,10 @@ static ssize_t iio_trigger_read_current(struct device *dev,
> > * Return: negative error code on failure or length of the buffer
> > * on success
> > */
> > -static ssize_t iio_trigger_write_current(struct device *dev,
> > - struct device_attribute *attr,
> > - const char *buf,
> > - size_t len)
> > +static ssize_t current_trigger_store(struct device *dev,
> > + struct device_attribute *attr,
>
> Ditto.
>
No
All others tweaked as suggested.
Patch applied to the togreg branch of iio.git and if the train wifi
remains stable (far too many tunnels), shortly pushed out as testing
for 0-day to see if we missed anything (or I messed up the tweaks).
Thanks,
Jonathan
prev parent reply other threads:[~2022-06-14 10:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 18:54 [PATCH v3] iio: Use octal permissions and DEVICE_ATTR_{RO,RW} Joe Simmons-Talbott
2022-06-01 19:02 ` Andy Shevchenko
2022-06-04 14:17 ` Jonathan Cameron
2022-06-14 10:35 ` Jonathan Cameron [this message]
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=20220614113522.432ebca8@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy.shevchenko@gmail.com \
--cc=joe@perches.com \
--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 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).