Re: [bug report] iio: light: isl29018: Replace a variant of iio_get_acpi_device_name_and_data()

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

 



On Thu, Oct 31, 2024 at 10:21:04AM +0200, Andy Shevchenko wrote:
> On Wed, Oct 30, 2024 at 04:50:14PM +0200, Andy Shevchenko wrote:
> > On Wed, Oct 30, 2024 at 12:53:57PM +0300, Dan Carpenter wrote:
> > > Hello Andy Shevchenko,
> > > 
> > > Commit 14686836fb69 ("iio: light: isl29018: Replace a variant of
> > > iio_get_acpi_device_name_and_data()") from Oct 24, 2024 (linux-next),
> > > leads to the following Smatch static checker warning:
> > > 
> > >     drivers/iio/light/isl29018.c:724 isl29018_probe() error: uninitialized symbol 'ddata'.
> > >     drivers/iio/light/ltr501.c:1514 ltr501_probe() error: uninitialized symbol 'ddata'.
> > > 
> > > drivers/iio/light/isl29018.c
> > >     701 static int isl29018_probe(struct i2c_client *client)
> > >     702 {
> > >     703         const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > >     704         struct isl29018_chip *chip;
> > >     705         struct iio_dev *indio_dev;
> > >     706         const void *ddata;
> > >     707         const char *name;
> > >     708         int dev_id;
> > >     709         int err;
> > >     710 
> > >     711         indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*chip));
> > >     712         if (!indio_dev)
> > >     713                 return -ENOMEM;
> > >     714 
> > >     715         chip = iio_priv(indio_dev);
> > >     716 
> > >     717         i2c_set_clientdata(client, indio_dev);
> > >     718 
> > >     719         if (id) {
> > >     720                 name = id->name;
> > >     721                 dev_id = id->driver_data;
> > >     722         } else {
> > >     723                 name = iio_get_acpi_device_name_and_data(&client->dev, &ddata);
> > > --> 724                 dev_id = (intptr_t)ddata;
> > > 
> > > How do we know that iio_get_acpi_device_name_and_data() will succeed?
> > 
> > Ideally we need to file &ddata with NULL in such case, but it will be
> > equal to 0, so it only works with the chip_info in place.
> > 
> > Let me look into this once more, thanks for the good catch!
> 
> I have sent a patch series to address that (you are in Cc there), does it help?
> 

Yes.  Thanks!

regards,
dan carpenter






[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux