Re: [PATCH v6 2/2] iio: proximity: Add driver support for vcnl3020 proximity sensor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> On Thu, Apr 2, 2020 at 11:24 AM Ivan Mikhaylov <i.mikhaylov@xxxxxxxxx> 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@xxxxxxxxx> 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





> 




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux