Re: [PATCH 1/2] iio: pressure: bmp280: Allow multiple chips id per family of devices

[Angel Iglesias <ang.iglesiasg@gmail.com>]

On Fri, 2023-08-18 at 14:19 +0300, Andy Shevchenko wrote:
> On Thu, Aug 17, 2023 at 11:05:21PM +0200, Angel Iglesias wrote:
> > Improve device detection in certain chip families known to have various
> > chip ids.
> 
> ...
> 
> > +       ret = -EINVAL;
> 
> Why do you need this...
> 
> > +       for (i = 0; i < data->chip_info->num_chip_id; i++) {
> > +               if (chip_id == data->chip_info->chip_id[i]) {
> 
> > +                       ret = 0;
> 
> ..and this...
> 
> > +                       break;
> > +               }
> > +       }
> 
> > +       if (ret) {
> 
> ...and this?
> 
> You can simply do
> 
>         for (i = 0; i < data->chip_info->num_chip_id; i++) {
>                 if (chip_id == data->chip_info->chip_id[i])
>                         break;
>         }
>         if (i < data->chip_info->num_chip_id) {
> 

Got it, much cleaner also.

> ...
> 
> > +               // 0x<id>, so four chars per number plus one space + ENDL
> > +               size_t nbuf = 5*data->chip_info->num_chip_id*sizeof(char);
> 
> Besides lack of spaces...
> 
> > +               char *buf = kmalloc(nbuf, GFP_KERNEL);
> 
> ...this at least should be kmalloc_array() and on top maybe something from
> overflow.h will be needed.

Sure, I'll give a look. I didn't want to do string manipulations on a kernel
driver but couldn't found a way to log the error meaningfully in one entry.

> > +               if (!buf)
> > +                       return ret;
> > +
> > +               for (i = 0; i < data->chip_info->num_chip_id; i++)
> > +                       snprintf(&buf[i*5], nbuf, "0x%x ", data->chip_info-
> > >chip_id[i]);
> > +               buf[nbuf-1] = '\0';
> > +
> > +               dev_err(dev, "bad chip id: expected [ %s ] got 0x%x\n", buf,
> > chip_id);
> > +               kfree(buf);
> > +               return ret;
> >         }
> 
> ...
> 
> > -       const unsigned int chip_id;
> 
> Yeah, this const makes a little sense...
> 
> > +       const unsigned int *chip_id;
> 
> ...but not this :-)

Isn't the same case as "const struct iio_chan_spec *channels" or "const int
*oversampling_temp_avail". I thoght that this meant a pointer to a constant
integer. On bmp280-core I declare the arrays with the modifiers static const.

> What I'm wondering is why it's int and not u8 / u16
> (as it seems only a byte value there).

Yeah, can be u8, as the reg width is 1 byte and this IDs are stored on one reg.
I just carried over the int type from previous versions, but it's just wasting
space :/

> 
> > +       int num_chip_id;
> 
> unsigned.
> 
Thanks for your time!

Kind regards,
Angel