From: "Shen Jianping (ME-SE/EAD2)" <Jianping.Shen@de.bosch.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "lars@metafoo.de" <lars@metafoo.de>,
"robh@kernel.org" <robh@kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"dima.fedrau@gmail.com" <dima.fedrau@gmail.com>,
"marcelo.schmitt1@gmail.com" <marcelo.schmitt1@gmail.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Lorenz Christian (ME-SE/EAD2)" <Christian.Lorenz3@de.bosch.com>,
"Frauendorf Ulrike (ME/PJ-SW3)" <Ulrike.Frauendorf@de.bosch.com>,
"Dolde Kai (ME-SE/PAE-A3)" <Kai.Dolde@de.bosch.com>
Subject: AW: [PATCH v2 2/2] iio: imu: smi330: Add driver
Date: Thu, 26 Jun 2025 09:31:19 +0000 [thread overview]
Message-ID: <AM8PR10MB4721C0BBFBAE160FB494482CCD7AA@AM8PR10MB4721.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20250525175157.2446f878@jic23-huawei>
Hi Jonathan,
most findings are already fixed. For 3 findings we still have something unclear. It will be nice if you can give us little bit more indication.
>> +
>> +static const struct iio_chan_spec smi330_channels[] = {
>> + SMI330_ACCEL_CHANNEL(IIO_ACCEL, X, SMI330_SCAN_ACCEL_X),
>> + SMI330_ACCEL_CHANNEL(IIO_ACCEL, Y, SMI330_SCAN_ACCEL_Y),
>> + SMI330_ACCEL_CHANNEL(IIO_ACCEL, Z, SMI330_SCAN_ACCEL_Z),
>> + SMI330_GYRO_CHANNEL(IIO_ANGL_VEL, X, SMI330_SCAN_GYRO_X),
>> + SMI330_GYRO_CHANNEL(IIO_ANGL_VEL, Y, SMI330_SCAN_GYRO_Y),
>> + SMI330_GYRO_CHANNEL(IIO_ANGL_VEL, Z, SMI330_SCAN_GYRO_Z),
>> + SMI330_TEMP_CHANNEL(SMI330_TEMP_OBJECT),
>> + IIO_CHAN_SOFT_TIMESTAMP(SMI330_SCAN_TIMESTAMP),
>> +};
>> +
>> +static const struct smi330_sysfs_attr smi330_accel_scale_attr = {
>> + .reg_vals = (int[]){ SMI330_ACCEL_RANGE_2G,
>SMI330_ACCEL_RANGE_4G,
>> + SMI330_ACCEL_RANGE_8G,
>SMI330_ACCEL_RANGE_16G },
>
>Do we need the (int[]) part here?
Remove it will lead to a compiler warning.
>> +
>> + if (*indio_dev->active_scan_mask == SMI330_ALL_CHAN_MSK) {
>> + ret = regmap_bulk_read(data->regmap, SMI330_ACCEL_X_REG,
>> + data->buf, ARRAY_SIZE(smi330_channels));
>> + if (ret)
>> + goto out;
>> + } else {
>> + iio_for_each_active_channel(indio_dev, chan) {
>> + ret = regmap_read(data->regmap,
>> + SMI330_ACCEL_X_REG + chan, &sample);
>
>Given there is always a trade off between the efficiency of a bulk read and reading
>just the channels enabled, we often just set available_scan_masks, read the lot and
>let the IIO core worry about resorting the data as needed.
Is any IIO API available to take care the resorting data?
>
>For example, if you want all but 1 channel that is almost certainly quicker and that is
>more likely to be the common case than you want 1 channel only using the buffer.
>
>So I'd like some more explanation here on why this path is needed.
We try to read the data just for activated channel and put them in buffer. If just one channel activated, reading data for all channels leads to unnecessary data transfer on bus.
>
>> + if (ret)
>> + goto out;
>> + data->buf[i++] = sample;
>> + }
>> + }
>> +
>> + iio_push_to_buffers_with_timestamp(indio_dev, data->buf,
>> + data->current_timestamp);
>> +
>> +out:
>> + iio_trigger_notify_done(indio_dev->trig);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +static irqreturn_t smi330_irq_handler(int irq, void *p) {
>> + struct iio_dev *indio_dev = p;
>> + struct smi330_data *data = iio_priv(indio_dev);
>> +
>> + atomic64_set(&data->irq_timestamp, iio_get_time_ns(indio_dev));
>
>Why do you need the atomic here? If there is a top half / thread race then you could
>get garbage data anyway.
The atomic here is used to prevent simultaneous read (in bottom half) / write (in top half) to the "data->irq_timestamp"
This happens if the next interrupt comes too early when the current bottom half is still reading "data->irq_timestamp".
The next top half will interrupt the execution of current bottom half and change the "data->irq_timestamp".
Finally, the current bottom half get a wrong value.
next prev parent reply other threads:[~2025-06-26 9:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-13 15:00 [PATCH v2 0/2] iio: imu: smi330: add bosch smi330 driver Jianping.Shen
2025-05-13 15:00 ` [PATCH v2 1/2] dt-bindings: iio: imu: smi330: Add binding Jianping.Shen
2025-05-14 16:19 ` Conor Dooley
2025-05-13 15:00 ` [PATCH v2 2/2] iio: imu: smi330: Add driver Jianping.Shen
2025-05-25 16:51 ` Jonathan Cameron
2025-06-26 9:31 ` Shen Jianping (ME-SE/EAD2) [this message]
2025-06-28 16:59 ` 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=AM8PR10MB4721C0BBFBAE160FB494482CCD7AA@AM8PR10MB4721.EURPRD10.PROD.OUTLOOK.COM \
--to=jianping.shen@de.bosch.com \
--cc=Christian.Lorenz3@de.bosch.com \
--cc=Kai.Dolde@de.bosch.com \
--cc=Ulrike.Frauendorf@de.bosch.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dima.fedrau@gmail.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.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®