From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jean-Baptiste Maneyrol <JManeyrol@invensense.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH 13/25] iio:imu:inv_mpu6050 Fix dma and ts alignment and data leak issues.
Date: Tue, 26 May 2020 17:59:45 +0100 [thread overview]
Message-ID: <20200526175945.00002dbe@Huawei.com> (raw)
In-Reply-To: <MN2PR12MB44223FFD85B9FBEADEA8368BC4B30@MN2PR12MB4422.namprd12.prod.outlook.com>
On Mon, 25 May 2020 18:44:41 +0000
Jean-Baptiste Maneyrol <JManeyrol@invensense.com> wrote:
> Hi Jonathan,
>
> the driver is also doing other regmap_bulk_read and regmap_bulk_write for getting sensor data from registers and for setting hardware offsets.
> But there are numerous IIO drivers supporting SPI that are doing the same (IMU ST driver for example).
>
> Are you sure this is really required? It seems to just call standard SPI transfers behind (I don't know if DMA can be implicitly call there)
> This is very inconvenient to deal with if there is no easy way to read/write multiple registers on the stack.
It's rare for this to be a problem on modern spi controllers, but there
are still some out there that will occasionally have trouble with
this.
Personally I only ran into the problem in the wild once and it is really
really evil to track down.
We should clear the other cases out but it's not something I'd consider
urgent given no one is screaming about it.
>
> Another thing I have in mind, the read for the FIFO should be replaced by a regmap_noinc_read, since this is a virtual register reading the FIFO, not the register map.
Good point.
Jonathan
>
> Thanks,
> JB
>
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Monday, May 25, 2020 19:06
> To: linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>; Lars-Peter Clausen <lars@metafoo.de>; Jean-Baptiste Maneyrol <JManeyrol@invensense.com>
> Subject: [PATCH 13/25] iio:imu:inv_mpu6050 Fix dma and ts alignment and data leak issues.
>
> CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> This case is a bit different to the rest of the series. The driver
> was doing a regmap_bulk_read into a buffer that wasn't dma safe
> as it was on the stack with no guarantee of it being in a cacheline
> on it's own. Fixing that also dealt with the data leak and
> alignment issues that Lars-Peter pointed out.
>
> Also removed some unaligned handling as we are now aligned.
>
> Fixes tag is for the dma safe buffer issue. Potentially we would
> need to backport timestamp alignment futher but that is a totally
> different patch.
>
> Fixes: fd64df16f40e ("iio: imu: inv_mpu6050: Add SPI support for MPU6000")
> Reported-by: Lars-Peter Clausen <lars@metafoo.de>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> ---
> drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 8 +++++---
> drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 12 ++++++------
> 2 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> index cd38b3fccc7b..e4df2d51b689 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> @@ -122,6 +122,9 @@ struct inv_mpu6050_chip_config {
> u8 user_ctrl;
> };
>
> +/* 6 + 6 + 2 + 7 (for MPU9x50) = 21 round up to 24 and plus 8 */
> +#define INV_MPU6050_OUTPUT_DATA_SIZE 32
> +
> /**
> * struct inv_mpu6050_hw - Other important hardware information.
> * @whoami: Self identification byte from WHO_AM_I register
> @@ -165,6 +168,7 @@ struct inv_mpu6050_hw {
> * @magn_raw_to_gauss: coefficient to convert mag raw value to Gauss.
> * @magn_orient: magnetometer sensor chip orientation if available.
> * @suspended_sensors: sensors mask of sensors turned off for suspend
> + * @data: dma safe buffer used for bulk reads.
> */
> struct inv_mpu6050_state {
> struct mutex lock;
> @@ -190,6 +194,7 @@ struct inv_mpu6050_state {
> s32 magn_raw_to_gauss[3];
> struct iio_mount_matrix magn_orient;
> unsigned int suspended_sensors;
> + u8 data[INV_MPU6050_OUTPUT_DATA_SIZE] ____cacheline_aligned;
> };
>
> /*register and associated bit definition*/
> @@ -334,9 +339,6 @@ struct inv_mpu6050_state {
> #define INV_ICM20608_TEMP_OFFSET 8170
> #define INV_ICM20608_TEMP_SCALE 3059976
>
> -/* 6 + 6 + 2 + 7 (for MPU9x50) = 21 round up to 24 and plus 8 */
> -#define INV_MPU6050_OUTPUT_DATA_SIZE 32
> -
> #define INV_MPU6050_REG_INT_PIN_CFG 0x37
> #define INV_MPU6050_ACTIVE_HIGH 0x00
> #define INV_MPU6050_ACTIVE_LOW 0x80
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> index 9511e4715e2c..554c16592d47 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c
> @@ -13,7 +13,6 @@
> #include <linux/interrupt.h>
> #include <linux/poll.h>
> #include <linux/math64.h>
> -#include <asm/unaligned.h>
> #include "inv_mpu_iio.h"
>
> /**
> @@ -121,7 +120,6 @@ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p)
> struct inv_mpu6050_state *st = iio_priv(indio_dev);
> size_t bytes_per_datum;
> int result;
> - u8 data[INV_MPU6050_OUTPUT_DATA_SIZE];
> u16 fifo_count;
> s64 timestamp;
> int int_status;
> @@ -160,11 +158,12 @@ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p)
> * read fifo_count register to know how many bytes are inside the FIFO
> * right now
> */
> - result = regmap_bulk_read(st->map, st->reg->fifo_count_h, data,
> + result = regmap_bulk_read(st->map, st->reg->fifo_count_h,
> + st->data,
> INV_MPU6050_FIFO_COUNT_BYTE);
> if (result)
> goto end_session;
> - fifo_count = get_unaligned_be16(&data[0]);
> + fifo_count = be16_to_cpup((__be16 *)&st->data[0]);
>
> /*
> * Handle fifo overflow by resetting fifo.
> @@ -182,7 +181,7 @@ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p)
> inv_mpu6050_update_period(st, pf->timestamp, nb);
> for (i = 0; i < nb; ++i) {
> result = regmap_bulk_read(st->map, st->reg->fifo_r_w,
> - data, bytes_per_datum);
> + st->data, bytes_per_datum);
> if (result)
> goto flush_fifo;
> /* skip first samples if needed */
> @@ -191,7 +190,8 @@ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p)
> continue;
> }
> timestamp = inv_mpu6050_get_timestamp(st);
> - iio_push_to_buffers_with_timestamp(indio_dev, data, timestamp);
> + iio_push_to_buffers_with_timestamp(indio_dev, st->data,
> + timestamp);
> }
>
> end_session:
next prev parent reply other threads:[~2020-05-26 17:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 17:06 [PATCH 00/25] IIO: 2nd set of timestamp alignment fixes Jonathan Cameron
2020-05-25 17:06 ` [PATCH 01/25] iio:light:si1145: Fix timestamp alignment and prevent data leak Jonathan Cameron
2020-05-25 17:06 ` [PATCH 02/25] iio:light:max44000 " Jonathan Cameron
2020-05-25 17:06 ` [PATCH 03/25] iio:light:rpr0521 " Jonathan Cameron
2020-05-25 17:06 ` [PATCH 04/25] iio:light:st_uvis25 " Jonathan Cameron
2020-05-26 7:55 ` Lorenzo Bianconi
2020-05-26 16:53 ` Jonathan Cameron
2020-06-07 14:37 ` Jonathan Cameron
2020-05-25 17:06 ` [PATCH 05/25] iio:light:ltr501 Fix timestamp alignment issue Jonathan Cameron
2020-05-25 17:06 ` [PATCH 06/25] iio:magnetometer:ak8974: Fix alignment and data leak issues Jonathan Cameron
2020-05-26 9:24 ` Linus Walleij
2020-06-07 14:43 ` Jonathan Cameron
2020-05-25 17:06 ` [PATCH 07/25] iio:magnetometer:ak8975 " Jonathan Cameron
2020-05-26 9:24 ` Andy Shevchenko
2020-05-26 16:50 ` Jonathan Cameron
2020-05-25 17:06 ` [PATCH 08/25] iio:magnetometer:mag3110 " Jonathan Cameron
2020-05-25 17:06 ` [PATCH 09/25] iio:humidity:hdc100x " Jonathan Cameron
2020-05-26 19:31 ` Matt Ranostay
2020-06-07 14:51 ` Jonathan Cameron
2020-05-25 17:06 ` [PATCH 10/25] iio:humidity:hts221 " Jonathan Cameron
2020-05-26 7:52 ` Lorenzo Bianconi
2020-06-07 14:55 ` Jonathan Cameron
2020-05-25 17:06 ` [PATCH 11/25] iio:imu:bmi160 " Jonathan Cameron
2020-05-25 17:06 ` [PATCH 12/25] iio:imu:st_lsm6dsx " Jonathan Cameron
2020-05-26 7:58 ` Lorenzo Bianconi
2020-06-07 15:07 ` Jonathan Cameron
2020-05-25 17:06 ` [PATCH 13/25] iio:imu:inv_mpu6050 Fix dma and ts " Jonathan Cameron
2020-05-25 18:44 ` Jean-Baptiste Maneyrol
2020-05-26 16:59 ` Jonathan Cameron [this message]
2020-05-25 17:06 ` [PATCH 14/25] iio:pressure:ms5611 Fix buffer element alignment Jonathan Cameron
2020-05-25 17:06 ` [PATCH 15/25] iio:pressure:mpl3115 Force alignment of buffer Jonathan Cameron
2020-05-25 17:06 ` [PATCH 16/25] iio:adc:ti-adc081c Fix alignment and data leak issues Jonathan Cameron
2020-05-25 17:06 ` [PATCH 17/25] iio:adc:ti-adc084s021 " Jonathan Cameron
2020-05-25 17:06 ` [PATCH 18/25] iio:adc:ti-adc084s021 Tidy up endian types Jonathan Cameron
2020-05-25 17:06 ` [PATCH 19/25] iio:adc:ti-ads1015 Fix buffer element alignment Jonathan Cameron
2020-05-25 17:52 ` Andy Shevchenko
2020-05-26 8:11 ` Lars-Peter Clausen
2020-05-26 9:15 ` Andy Shevchenko
2020-05-26 16:43 ` Jonathan Cameron
2020-05-26 17:06 ` Andy Shevchenko
2020-05-26 19:17 ` Jonathan Cameron
2020-05-26 21:03 ` Andy Shevchenko
2020-05-27 11:41 ` Jonathan Cameron
2020-05-27 12:37 ` Andy Shevchenko
2020-05-27 14:06 ` Andy Shevchenko
2020-05-27 14:43 ` Jonathan Cameron
2020-05-25 17:06 ` [PATCH 20/25] iio:adc:ti-ads124s08 Fix alignment and data leak issues Jonathan Cameron
2020-05-25 17:06 ` [PATCH 21/25] iio:adc:ti-ads8688 Fix alignment and potential data leak issue Jonathan Cameron
2020-05-25 17:06 ` [PATCH 22/25] iio:adc:ti-adc0832 Fix alignment issue with timestamp Jonathan Cameron
2020-05-25 17:06 ` [PATCH 23/25] iio:adc:ti-adc12138 " Jonathan Cameron
2020-05-25 17:06 ` [PATCH 24/25] iio:adc:ina2xx Fix timestamp alignment issue Jonathan Cameron
2020-05-25 17:06 ` [PATCH 25/25] iio:adc:max1118 Fix alignment of timestamp and data leak issues Jonathan Cameron
2020-05-26 17:02 ` [PATCH 00/25] IIO: 2nd set of timestamp alignment fixes 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=20200526175945.00002dbe@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=JManeyrol@invensense.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.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;
as well as URLs for NNTP newsgroup(s).