On Wed, Feb 21, 2018 at 9:45 PM, Pierre Bourdon <delroth@xxxxxxxxxx> wrote: > Ambient light sensor that supports visible light and IR measurements and > configurable gain/integration time. > > Changed in v2: > * Split off DT documentation change into a separate commit. > * Use i2c's probe_new. Btw, how big the difference with existing drivers? > + default: > + return -1; Better to return -EINVAL; > + highest = max(visible, ir); > + > + /* > + * If the read value is being clamped, assume the worst and go to the > + * lowest possible gain. The alternative is doing multiple > + * recalibrations, which would be slower and have the same effect. > + */ > + if (highest == USHRT_MAX) > + highest *= 128; > + else > + highest = (highest * 128) / bh1730_gain_multiplier(bh1730); In both cases you multiply. Why not just highest = max(visible, ir) * 128; if (highest < USHRT_MAX) ... ? > + millilux = (u64)USEC_PER_MSEC * (visible_coef * visible - ir_coef * ir); I'm not sure I understand how time units is related to lux one. > + millilux /= bh1730_gain_multiplier(bh1730); > + millilux *= 103; > + millilux /= itime_us; > + return millilux; > +} > + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*bh1730)); > + if (!indio_dev) > + return -ENOMEM; > + > + indio_dev->dev.parent = &client->dev; Strange, it's not done in IIO core... Jonathan, is it true that in case of devm_iio_device_alloc() all drivers use supplied struct device as a parent one? If so, doesn't make sense to modify IIO core to do this? > +static int bh1730_remove(struct i2c_client *client) > +{ > + struct iio_dev *indio_dev = i2c_get_clientdata(client); > + struct bh1730_data *bh1730 = iio_priv(indio_dev); > + > + iio_device_unregister(indio_dev); Hmm... Do you still need this even with devm IIO in ->probe()? > +#ifdef CONFIG_OF > +#endif This... > + .of_match_table = of_match_ptr(of_bh1730_match), ...and of_match_ptr() now pointless. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html