linux-kernel - Re: [PATCH v3] iio: Use octal permissions and DEVICE_ATTR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 14 Jun 2022 11:35:22 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Joe Simmons-Talbott <joetalbott@...il.com>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Joe Perches <joe@...ches.com>
Subject: Re: [PATCH v3] iio: Use octal permissions and DEVICE_ATTR_{RO,RW}.

On Wed, 1 Jun 2022 21:02:52 +0200
Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Wed, Jun 1, 2022 at 8:54 PM Joe Simmons-Talbott <joetalbott@...il.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@...il.com>
> 
> > Suggested-by: Joe Perches <joe@...ches.com>
> > Suggested-by: Andy Shevchenko <andy.shevchenko@...il.com>
> > Signed-off-by: Joe Simmons-Talbott <joetalbott@...il.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