linux-kernel - Re: [PATCH v7 2/2] iio: light: Add support for ltrf216a sensor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Jul 2022 15:06:42 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Shreeya Patel <shreeya.patel@...labora.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>, Zhigang.Shi@...eon.com,
        krisman@...labora.com, linux-iio <linux-iio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Collabora Kernel ML <kernel@...labora.com>,
        alvaro.soliverez@...labora.com, dmitry.osipenko@...labora.com
Subject: Re: [PATCH v7 2/2] iio: light: Add support for ltrf216a sensor

On Mon, Jul 11, 2022 at 1:30 PM Shreeya Patel
<shreeya.patel@...labora.com> wrote:
>
> From: Zhigang Shi <Zhigang.Shi@...eon.com>
>
> Add initial support for ltrf216a ambient light sensor.
>
> Datasheet: https://gitlab.steamos.cloud/shreeya/iio/-/blob/main/LTRF216A.pdf
> Co-developed-by: Shreeya Patel <shreeya.patel@...labora.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@...labora.com>
> Signed-off-by: Zhigang Shi <Zhigang.Shi@...eon.com>

Submitter's SoB always has to be last among SoBs in the proposed change.
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

...

> +static int ltrf216a_set_power_state(struct ltrf216a_data *data, bool on)
> +{
> +       struct device *dev = &data->client->dev;
> +       int ret;
> +
> +       if (on) {
> +               ret = pm_runtime_resume_and_get(dev);
> +               if (ret < 0) {
> +                       dev_err(dev, "Failed to resume runtime PM: %d\n", ret);
> +                       return ret;
> +               }

> +

Unneeded blank line.

> +       } else {
> +               pm_runtime_mark_last_busy(dev);
> +               ret = pm_runtime_put_autosuspend(dev);
> +       }
> +
> +       return ret;
> +}

...

> +       ret = regmap_read_poll_timeout(data->regmap, LTRF216A_MAIN_STATUS,
> +                                      val, val & LTRF216A_ALS_DATA_STATUS,
> +                                      LTRF216A_ALS_READ_DATA_DELAY_US,
> +                                      LTRF216A_ALS_READ_DATA_DELAY_US * 50);
> +       if (ret) {
> +               dev_err(dev, "Timed out waiting for valid data from LTRF216A_MAIN_STATUS reg: %d\n",
> +                       ret);

THe message is a bit misleading. The loop might be broken by the I/O error.

> +               return ret;
> +       }
> +
> +       ret = regmap_bulk_read(data->regmap, addr, buf, sizeof(buf));
> +       if (ret < 0) {
> +               dev_err(dev, "Error reading measurement data: %d\n", ret);
> +               return ret;
> +       }

...

> +static const struct regmap_config ltrf216a_regmap_config = {
> +       .name = LTRF216A_DRV_NAME,
> +       .reg_bits = 8,
> +       .val_bits = 8,
> +       .max_register = LTRF216A_MAX_REG,

Why do you use regmap locking? What for?

> +};

...

> +       data->regmap = devm_regmap_init_i2c(client, &ltrf216a_regmap_config);
> +       if (IS_ERR(data->regmap)) {
> +               dev_err(&client->dev, "Regmap initialization failed.\n");
> +               return PTR_ERR(data->regmap);

return dev_err_probe(...);

> +       }

...

> +       ret = devm_pm_runtime_enable(&client->dev);
> +       if (ret < 0) {
> +               dev_err_probe(&client->dev, ret, "Failed to enable runtime PM\n");
> +               return ret;

Ditto.

> +       }

...

> +               ret = ltrf216a_init(indio_dev);
> +               if (ret) {
> +                       dev_err_probe(&client->dev, ret, "Failed to enable the sensor\n");
> +                       return ret;

Ditto.

> +               }

...

> +       if (ret < 0)

For all these  ' < 0', please explain what positive return value means
there, if any, and why it's being ignored.

...

> +static const struct i2c_device_id ltrf216a_id[] = {
> +       { LTRF216A_DRV_NAME, 0 },

Please, use the string literal directly since it's kinda an ABI,
defining above for potential changes is not a good idea. Also you may
drop the ', 0' part.

> +       {}
> +};

...

> +static struct i2c_driver ltrf216a_driver = {
> +       .driver = {

> +               .name = LTRF216A_DRV_NAME,

Ditto.

> +               .pm = pm_ptr(&ltrf216a_pm_ops),
> +               .of_match_table = ltrf216a_of_match,
> +       },
> +       .probe_new      = ltrf216a_probe,
> +       .id_table       = ltrf216a_id,
> +};

-- 
With Best Regards,
Andy Shevchenko