| 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
| ||
|
Message-ID: <20251021-54542-354166@bhairav-test.ee.iitb.ac.in>
Date: Tue, 21 Oct 2025 11:15:42 +0530
From: Akhilesh Patil <akhilesh@...iitb.ac.in>
To: Jonathan Cameron <jic23@...nel.org>
Cc: dlechner@...libre.com, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, nuno.sa@...log.com, andy@...nel.org,
marcelo.schmitt1@...il.com, vassilisamir@...il.com,
salah.triki@...il.com, skhan@...uxfoundation.org,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, akhileshpatilvnit@...il.com
Subject: Re: [PATCH v2 2/2] iio: pressure: adp810: Add driver for adp810
sensor
On Sat, Oct 18, 2025 at 05:47:46PM +0100, Jonathan Cameron wrote:
> On Mon, 13 Oct 2025 22:32:35 +0530
> Akhilesh Patil <akhilesh@...iitb.ac.in> wrote:
>
> > Add driver for Aosong adp810 differential pressure and temperature sensor.
> > This sensor provides an I2C interface for reading data.
> > Calculate CRC of the data received using standard crc8 library to verify
> > data integrity.
> >
> > Tested on TI am62x sk board with sensor connected at i2c-2.
> >
> > Signed-off-by: Akhilesh Patil <akhilesh@...iitb.ac.in>
>
> A few comments inline and it seems your rebase when wrong and you've
> picked up unrelated build file changes.
>
> Thanks
>
> Jonathan
Hi Jonathan, Thanks for the review, I will share v3 addressing these comments.
Regards,
Akhilesh
>
> > diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile
> > index 6482288e07ee..a21443e992b9 100644
> > --- a/drivers/iio/pressure/Makefile
> > +++ b/drivers/iio/pressure/Makefile
> > @@ -5,6 +5,7 @@
> >
> > # When adding new entries keep the list in alphabetical order
> > obj-$(CONFIG_ABP060MG) += abp060mg.o
> > +obj-$(CONFIG_ADP810) += adp810.o
> > obj-$(CONFIG_ROHM_BM1390) += rohm-bm1390.o
> > obj-$(CONFIG_BMP280) += bmp280.o
> > bmp280-objs := bmp280-core.o bmp280-regmap.o
> > @@ -15,6 +16,7 @@ obj-$(CONFIG_DPS310) += dps310.o
> > obj-$(CONFIG_IIO_CROS_EC_BARO) += cros_ec_baro.o
> > obj-$(CONFIG_HID_SENSOR_PRESS) += hid-sensor-press.o
> > obj-$(CONFIG_HP03) += hp03.o
> > +obj-$(CONFIG_HP206C) += hp206c.o
> > obj-$(CONFIG_HSC030PA) += hsc030pa.o
> > obj-$(CONFIG_HSC030PA_I2C) += hsc030pa_i2c.o
> > obj-$(CONFIG_HSC030PA_SPI) += hsc030pa_spi.o
> > @@ -34,11 +36,9 @@ obj-$(CONFIG_SDP500) += sdp500.o
> > obj-$(CONFIG_IIO_ST_PRESS) += st_pressure.o
> > st_pressure-y := st_pressure_core.o
> > st_pressure-$(CONFIG_IIO_BUFFER) += st_pressure_buffer.o
> > +obj-$(CONFIG_IIO_ST_PRESS_I2C) += st_pressure_i2c.o
> > +obj-$(CONFIG_IIO_ST_PRESS_SPI) += st_pressure_spi.o
> > obj-$(CONFIG_T5403) += t5403.o
> > -obj-$(CONFIG_HP206C) += hp206c.o
>
> Rebase gone wrong I assume.
These are intentional changes.
This addresses Andy's suggestion in v1, to keep entries alphabetically
arranged in Makefile. Along with adp810 location, fixed other files as well
hp206 and st_pressure_* to make entries alphabetically arranged in
the entire Makefile.
>
> > obj-$(CONFIG_ZPA2326) += zpa2326.o
> > obj-$(CONFIG_ZPA2326_I2C) += zpa2326_i2c.o
> > obj-$(CONFIG_ZPA2326_SPI) += zpa2326_spi.o
> > -
> > -obj-$(CONFIG_IIO_ST_PRESS_I2C) += st_pressure_i2c.o
> > -obj-$(CONFIG_IIO_ST_PRESS_SPI) += st_pressure_spi.o
> > diff --git a/drivers/iio/pressure/adp810.c b/drivers/iio/pressure/adp810.c
> > new file mode 100644
> > index 000000000000..c2f3b5f7a1f9
> > --- /dev/null
> > +++ b/drivers/iio/pressure/adp810.c
> > @@ -0,0 +1,212 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2025 Akhilesh Patil <akhilesh@...iitb.ac.in>
> > + *
> > + * Driver for adp810 pressure and temperature sensor
> > + * Datasheet:
> > + * https://aosong.com/userfiles/files/media/Datasheet%20ADP810-Digital.pdf
> > + */
> > +
> > +#include <linux/crc8.h>
> > +#include <linux/delay.h>
> > +#include <linux/i2c.h>
> > +#include <linux/module.h>
> > +#include <linux/unaligned.h>
> This is a very small set of includes. Please follow include what you use (IWYU)
> principles (loosely - there are a few headers that never make sense to include
> directly). So I'd definitely expect things like mutex.h here.
> dev_printk.h etc.
ACK.
Added mutex.h, dev_printk.h along with other includes - cleanup.h,
device.h, iio/types.h, mod_devicetable.h to follow IWYU.
>
> > +
> > +#include <linux/iio/iio.h>
>
> > +
> > +static int adp810_measure(struct adp810_data *data, struct adp810_read_buf *buf)
> > +{
> > + struct i2c_client *client = data->client;
> > + struct device *dev = &client->dev;
> > + int ret;
> > + u16 trig_cmd = ADP810_TRIGGER_COMMAND;
> > +
> > + /* Send trigger to the sensor for measurement */
> > + ret = i2c_master_send(client, (char *)&trig_cmd, sizeof(u16));
>
> sizeof(trig_cmd)
>
> I think it is vanishingly unlikely to matter but in theory i2c_master_send()
> could return 1 and only one byte made it to device.
> So it's common to have
> if (ret < 0)...
> ....
> if (ret != sizeof(trig_cmd))
> ....
>
Agree. This is a good corner case. Handled as per the suggestion above.
> > + if (ret < 0) {
> > + dev_err(dev, "Error sending trigger command\n");
> > + return ret;
> > + }
> > +
> > + /*
> > + * Wait for the sensor to acquire data. As per datasheet section 5.3.1,
> > + * wait for at least 10ms before reading measurements from the sensor.
> > + */
> > + msleep(ADP810_MEASURE_LATENCY_MS);
> > +
> > + /* Read sensor values */
> > + ret = i2c_master_recv(client, (char *)buf, sizeof(*buf));
> > + if (ret < 0) {
>
> Same potential issue for short reads as for the write above.
>
> I don't recall seeing anything to say we either got full length or
> error code but maybe that changed at somepoint to make this interface easier to use.
ACK. Did similar implementation as _send() for error handling.
>
>
> > + dev_err(dev, "Error reading from sensor\n");
> > + return ret;
> > + }
> > +
> > + /* CRC checks */
> > + crc8_populate_msb(crc_table, ADP810_CRC8_POLYNOMIAL);
> > + if (buf->dp_crc != crc8(crc_table, (u8 *)&buf->dp, 0x2, CRC8_INIT_VALUE)) {
> > + dev_err(dev, "CRC error for pressure\n");
> > + return -EIO;
> > + }
> > +
> > + if (buf->tmp_crc != crc8(crc_table, (u8 *)&buf->tmp, 0x2, CRC8_INIT_VALUE)) {
> > + dev_err(dev, "CRC error for temperature\n");
> > + return -EIO;
> > + }
> > +
> > + if (buf->sf_crc != crc8(crc_table, (u8 *)&buf->sf, 0x2, CRC8_INIT_VALUE)) {
> > + dev_err(dev, "CRC error for scale\n");
> > + return -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int adp810_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int *val, int *val2, long mask)
> > +{
> > + struct adp810_data *data = iio_priv(indio_dev);
> > + struct device *dev = &data->client->dev;
> > + struct adp810_read_buf buf = {0};
>
> Not a big thing but slight preference for { }.
Sure. Will use { } insteaed of {0}.
> It's a messy thing wrt to the c spec which never talked about holes
> and this construct until recently. However the kernel has build tests
> that verify that all compilers will zero the holes with the { }
> syntax and that is what the C standards folk have put in the spec now
> as meaning whole structure including holes.
Good to know the background of this. Thanks.
>
> > + int ret;
> > +
> > + scoped_guard(mutex, &data->lock) {
> > + ret = adp810_measure(data, &buf);
> > + if (ret) {
> > + dev_err(dev, "Failed to read from device\n");
> > + return ret;
> > + }
> > + }
> > +
> > + switch (mask) {
>
Powered by blists - more mailing lists