Hi Andy, Thanks for the review! Answers inline. I'll send a v3 when the two open questions are resolved. On Wed, Feb 21, 2018 at 10:57 PM, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > 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? See https://lkml.org/lkml/2018/2/21/982 . In retrospect, I should have added this to the commit message. It will be there in v3. >> + 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) > ... > ? You'd need < USHRT_MAX * 128 then. I refactored this a bit but differently. WDYT? if (highest == USHRT_MAX) gain = 1; else gain = bh1730_gain_multiplier(bh1730); highest = (highest * BH1730_MAX_GAIN_MULTIPLIER) / gain; >> + 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. Now looks like this, which should match the units together better while keeping most multiplications before divisions (for accuracy). Not much better I can do here I think, for example the magic "103" is straight from the datasheet with no explanation. millilux = visible_coef * visible - ir_coef * ir; millilux = (millilux * USEC_PER_MSEC) / itime_us; millilux *= 103; millilux /= bh1730_gain_multiplier(bh1730); >> + 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? It doesn't seem like IIO core is doing it at this point. Should we just leave that as-is for now and get everything fixed in a future patch? >> +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()? I *think* so, but that's mostly because all the other IIO light drivers that I've looked at are doing it. Can someone who knows the IIO subsystem well weigh in? Thanks! Best, -- Pierre Bourdon (delroth@) -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
