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] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 5 Apr 2020 11:13:41 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Ivan Mikhaylov <i.mikhaylov@...ro.com>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v6 2/2] iio: proximity: Add driver support for vcnl3020
 proximity sensor

On Thu, 2 Apr 2020 15:42:02 +0300
Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Thu, Apr 2, 2020 at 11:24 AM Ivan Mikhaylov <i.mikhaylov@...ro.com> wrote:
> >
> > On Wed, 2020-04-01 at 19:35 +0300, Andy Shevchenko wrote:  
> > > On Wed, Apr 1, 2020 at 7:24 PM Ivan Mikhaylov <i.mikhaylov@...ro.com> wrote:  
> > > > Proximity sensor driver based on light/vcnl4000.c code.
> > > > For now supports only the single on-demand measurement.
> > > >
> > > > The VCNL3020 is a fully integrated proximity sensor. Fully
> > > > integrated means that the infrared emitter is included in the
> > > > package. It has 16-bit resolution. It includes a signal
> > > > processing IC and features standard I2C communication
> > > > interface. It features an interrupt function.  
> > >
> > > Thank you for an update, my comments below.
> > >
> > > ...
> > >  
> > > > +static int get_and_apply_property(struct vcnl3020_data *data, const char
> > > > *prop,
> > > > +                                 u32 reg)
> > > > +{
> > > > +       int rc;
> > > > +       u32 val;
> > > > +
> > > > +       rc = device_property_read_u32(data->dev, prop, &val);
> > > > +       if (rc)
> > > > +               return 0;
> > > > +
> > > > +       rc = regmap_write(data->regmap, reg, val);
> > > > +       if (rc)
> > > > +               dev_err(data->dev, "Error (%d) setting property (%s)",
> > > > +                       rc, prop);  
> > >
> > > This requires {} according to the coding style  
> >
> > checkpatch.pl doesn't say anything bad on this spot. Do you mean to make
> > something like this?
> >
> > rc = regmap_write(data->regmap, reg, val);
> > if (rc) {
> >         dev_err(data->dev, "Error (%d) setting property (%s)",
> >                 rc, prop);
> > }  
> 
> Yes. Checkpatch is neither strict nor fully comprehensive tool.
> 
> > In previous notes you said to remove them.  
> 
> When it's one line, it fine, otherwise you need {} surround.
> 
> https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces
> 
> > > > +       return rc;
> > > > +}  
> > >
> > > ...
> > >  
> > > > +static int vcnl3020_probe(struct i2c_client *client)
> > > > +{
> > > > +       indio_dev->name = VCNL_DRV_NAME;  
> > >
> > > It's definitely not a driver name. You have to put part number here.  
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/light/tsl4531.c?h=v5.6#n199
That one is actually fine (if not very pretty) because the driver only supports one part and it happens
to also be the name of the driver.

> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/light/max44009.c?h=v5.6#n507
Also only one part supported, so fine if liable to accidentally get broken if we support more parts.

> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/light/vl6180.c?h=v5.6#n515  

Again, one part supported and the driver has the same name.

> 
> Let's Jonathan speak up.

So, the real point here is not the value being assigned but the fact it's
explicitly linked to the name of the driver.  I'd argue that you could use
VCNL_NAME as the define and that link is clearly broken. Or just put the string
inline in both places and don't worry about the tiny bit of replication!

Jonathan





> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ