mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
To: Muhammad Abu Bakar <m.abubakar365@yahoo.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Andy Shevchenko <andriy.shevchenko@intel.com>
Subject: Re: [PATCH v6 2/2] iio: pressure: add Sensirion SDP31 driver
Date: Mon, 12 Oct 2026 12:09:47 -0300	[thread overview]
Message-ID: <asz4O0zceqa5lz8m@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20261007205104.4694-3-m.abubakar365@yahoo.com>

On 10/08, Muhammad Abu Bakar wrote:
> Add an IIO driver for the Sensirion SDP3x family of differential pressure
> sensors (SDP31, SDP32 and SDP33). The devices are accessed over I2C and
> report differential pressure and temperature. Each measurement is
> validated using the sensor's CRC-8 checksum. The scale factor is read
> from the sensor at runtime, so all three parts are supported.
> 
> Tested on an SDP31 connected to a Raspberry Pi 4 I2C bus.
> 
> Assisted-by: LLM
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Muhammad Abu Bakar <m.abubakar365@yahoo.com>
> ---
...
> +static int sdp31_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct iio_dev *indio_dev;
> +	struct sdp31_data *data;
> +	int ret;
> +
> +	ret = devm_regulator_get_enable(dev, "vdd");
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to enable regulator\n");
> +
> +	msleep(SDP31_POWERUP_TIME_MS);
> +
> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	data = iio_priv(indio_dev);
> +	data->client = client;
> +
> +	ret = devm_mutex_init(dev, &data->lock);
> +	if (ret)
> +		return ret;
> +
> +	DO_ONCE(crc8_populate_msb, sdp31_crc8_table, SDP31_CRC8_POLY);
> +
> +	ret = sdp31_read_scale(data, &data->dp_scale);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to read from sensor\n");
> +	if (!data->dp_scale)
> +		return dev_err_probe(dev, -EINVAL, "invalid scale factor\n");
> +
> +	indio_dev->name = "sdp31";
Hmm, I'm not sure whether it is a big deal or not but, the hardcoded name might
cause confusion if the part connected is sdp32 or sdp33. That's because the
device name will be sdp31, but the scale will be SDP32 scale for differential
pressure (or SDP33 scale if one of those would be connected). The full
disambiguation solution would probably be to read the product identifier bits
and match those against a table of supported devices. It could have some sort of
chip_info struct to hold the device name and maybe the pressure scale as well.
That will probably require some boilerplate code that might not have been
necessary otherwise.

The other parts of the device driver look good to me. So, if the naming thing is
not needed,

Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>

> +	indio_dev->info = &sdp31_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = sdp31_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(sdp31_channels);
> +
> +	return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static const struct i2c_device_id sdp31_id[] = {
> +	{ .name = "sdp31" },
> +	{ }
> +};

  reply	other threads:[~2026-10-12 15:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20261007205104.4694-1-m.abubakar365.ref@yahoo.com>
2026-10-07 20:51 ` [PATCH v6 0/2] " Muhammad Abu Bakar
2026-10-07 20:51   ` [PATCH v6 1/2] dt-bindings: iio: pressure: add Sensirion SDP31 Muhammad Abu Bakar
2026-10-07 20:51   ` [PATCH v6 2/2] iio: pressure: add Sensirion SDP31 driver Muhammad Abu Bakar
2026-10-12 15:09     ` Marcelo Schmitt [this message]
2026-10-14 19:45       ` Muhammad Abu Bakar
2026-10-18 18:31         ` Jonathan Cameron
2026-10-18 18:37   ` [PATCH v6 0/2] " Jonathan Cameron

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=asz4O0zceqa5lz8m@debian-BULLSEYE-live-builder-AMD64 \
    --to=marcelo.schmitt1@gmail.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.abubakar365@yahoo.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    /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

all inboxes | Powered by JetHome®