From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Shreeya Patel <shreeya.patel@collabora.com>,
Zhigang Shi <Zhigang.Shi@liteon.com>,
Paul Gazzillo <paul@pgazz.com>,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/5] iio: light: ROHM BU27008 color sensor
Date: Thu, 4 May 2023 17:33:52 +0300 [thread overview]
Message-ID: <ZFPCUJ81aw/GkJgT@smile.fi.intel.com> (raw)
In-Reply-To: <6d1e37f95dd039d9c96a992b1855fd193bdded40.1683105758.git.mazziesaccount@gmail.com>
On Wed, May 03, 2023 at 12:50:14PM +0300, Matti Vaittinen wrote:
> The ROHM BU27008 is a sensor with 5 photodiodes (red, green, blue, clear
> and IR) with four configurable channels. Red and green being always
> available and two out of the rest three (blue, clear, IR) can be
> selected to be simultaneously measured. Typical application is adjusting
> LCD backlight of TVs, mobile phones and tablet PCs.
>
> Add initial support for the ROHM BU27008 color sensor.
> - raw_read() of RGB and clear channels
> - triggered buffer w/ DRDY interrtupt
...
> +config ROHM_BU27008
> + tristate "ROHM BU27008 color (RGB+C/IR) sensor"
> + depends on I2C
> + select REGMAP_I2C
> + select IIO_GTS_HELPER
> + help
> + Enable support for the ROHM BU27008 color sensor.
> + The ROHM BU27008 is a sensor with 5 photodiodes (red, green,
> + blue, clear and IR) with four configurable channels. Red and
> + green being always available and two out of the rest three
> + (blue, clear, IR) can be selected to be simultaneously measured.
> + Typical application is adjusting LCD backlight of TVs,
> + mobile phones and tablet PCs.
Module name?
...
> +static const struct regmap_range bu27008_read_only_ranges[] = {
> + {
> + .range_min = BU27008_REG_DATA0_LO,
> + .range_max = BU27008_REG_DATA3_HI,
> + }, {
> + .range_min = BU27008_REG_MANUFACTURER_ID,
> + .range_max = BU27008_REG_MANUFACTURER_ID,
> + }
+ trailing comma for consistency?
> +};
...
> +static const struct regmap_config bu27008_regmap = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = BU27008_REG_MAX,
> + .cache_type = REGCACHE_RBTREE,
> + .volatile_table = &bu27008_volatile_regs,
> + .wr_table = &bu27008_ro_regs,
Do you need regmap lock? If so, why (since you have mutex)?
> +};
...
> +static int bu27008_read_one(struct bu27008_data *data, struct iio_dev *idev,
> + struct iio_chan_spec const *chan, int *val, int *val2)
> +{
> + int ret, int_time;
> +
> + ret = bu27008_chan_cfg(data, chan);
> + if (ret)
> + return ret;
> +
> + ret = bu27008_meas_set(data, BU27008_MEAS_EN);
> + if (ret)
> + return ret;
> +
> + int_time = bu27008_get_int_time_us(data);
> + if (int_time < 0)
> + int_time = BU27008_MEAS_TIME_MAX_MS;
> + else
> + int_time /= USEC_PER_MSEC;
The above function returns an error code when negative, so I would rather see
ret = bu27008_get_int_time_us(data);
if (ret < 0)
int_time = BU27008_MEAS_TIME_MAX_MS;
else
int_time = ret / USEC_PER_MSEC;
at least this explicitly shows the semantics of the "negative" time.
> + msleep(int_time);
> +
> + ret = bu27008_chan_read_data(data, chan->address, val);
> + if (!ret)
> + ret = IIO_VAL_INT;
> +
> + if (bu27008_meas_set(data, BU27008_MEAS_DIS))
> + dev_warn(data->dev, "measurement disabling failed\n");
> +
> + return ret;
> +}
...
> + ret = regmap_reinit_cache(data->regmap, &bu27008_regmap);
> + if (ret) {
> + dev_err(data->dev, "Failed to reinit reg cache\n");
> + return ret;
Dup is not needed.
> + }
> +
> + return ret;
...
> + if (i2c->irq) {
Instead of a long body, I would rather see a call to
ret = ..._setup_irq();
if (ret)
return ret;
> + ret = devm_iio_triggered_buffer_setup(dev, idev,
> + &iio_pollfunc_store_time,
> + bu27008_trigger_handler,
> + &bu27008_buffer_ops);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "iio_triggered_buffer_setup_ext FAIL\n");
> +
> + itrig = devm_iio_trigger_alloc(dev, "%sdata-rdy-dev%d",
> + idev->name, iio_device_id(idev));
> + if (!itrig)
> + return -ENOMEM;
> +
> + data->trig = itrig;
> +
> + itrig->ops = &bu27008_trigger_ops;
> + iio_trigger_set_drvdata(itrig, data);
> +
> + name = devm_kasprintf(dev, GFP_KERNEL, "%s-bu27008",
> + dev_name(dev));
> +
> + ret = devm_request_irq(dev, i2c->irq,
> + &bu27008_data_rdy_poll,
> + 0, name, itrig);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Could not request IRQ\n");
> +
> + ret = devm_iio_trigger_register(dev, itrig);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Trigger registration failed\n");
> +
> + /* set default trigger */
> + idev->trig = iio_trigger_get(itrig);
> + } else {
> + dev_info(dev, "No IRQ, buffered mode disabled\n");
> + }
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-05-04 14:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 9:44 [PATCH v4 0/5] Support ROHM BU27008 RGB sensor Matti Vaittinen
2023-05-03 9:48 ` [PATCH v4 1/5] dt-bindings: iio: light: ROHM BU27008 Matti Vaittinen
2023-05-03 9:48 ` [PATCH v4 2/5] iio: trigger: Add simple trigger_validation helper Matti Vaittinen
2023-05-07 14:34 ` Jonathan Cameron
2023-05-03 9:49 ` [PATCH v4 3/5] iio: kx022a: Use new iio_validate_own_trigger() Matti Vaittinen
2023-05-03 9:50 ` [PATCH v4 4/5] iio: light: ROHM BU27008 color sensor Matti Vaittinen
2023-05-04 14:33 ` Andy Shevchenko [this message]
2023-05-05 4:56 ` Vaittinen, Matti
2023-05-08 12:23 ` Andy Shevchenko
2023-05-08 12:40 ` Matti Vaittinen
2023-05-07 14:54 ` Jonathan Cameron
2023-05-08 6:32 ` Matti Vaittinen
2023-05-13 17:52 ` Jonathan Cameron
2023-05-15 12:31 ` Matti Vaittinen
2023-05-03 9:50 ` [PATCH v4 5/5] MAINTAINERS: Add ROHM BU27008 Matti Vaittinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZFPCUJ81aw/GkJgT@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=Zhigang.Shi@liteon.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.osipenko@collabora.com \
--cc=jic23@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=mazziesaccount@gmail.com \
--cc=paul@pgazz.com \
--cc=robh+dt@kernel.org \
--cc=shreeya.patel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).