linux.git/drivers/iio/magnetometer, branch v5.4.131 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git iio:magnetometer:mag3110: Fix alignment and data leak issues. 2020-12-30T10:51:44+00:00 Jonathan Cameron Jonathan.Cameron@huawei.com 2020-09-20T11:27:37+00:00 9607d22e71d18ed6d9f6792fef418fab98d6fa4c commit 89deb1334252ea4a8491d47654811e28b0790364 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it. Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 89deb1334252ea4a8491d47654811e28b0790364 upstream.

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here.  We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc() so no data can leak apart from
previous readings.

The explicit alignment of ts is not necessary in this case but
does make the code slightly less fragile so I have included it.

Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio:magnetometer:ak8975 Fix alignment and data leak issues. 2020-09-17T11:47:50+00:00 Jonathan Cameron Jonathan.Cameron@huawei.com 2020-07-22T15:50:49+00:00 176fb9423ab8e91ff4776483b81fcc56567f0347 commit 02ad21cefbac4d89ac443866f25b90449527737b upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case as by coincidence the padding will end up the same, however I consider it to make the code less fragile and have included it. Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Gregor Boirie <gregor.boirie@parrot.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 02ad21cefbac4d89ac443866f25b90449527737b upstream.

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here.  We close both issues by
moving to a suitable structure in the iio_priv() data.

This data is allocated with kzalloc so no data can leak apart from
previous readings.

The explicit alignment of ts is not necessary in this case as by
coincidence the padding will end up the same, however I consider
it to make the code less fragile and have included it.

Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Gregor Boirie <gregor.boirie@parrot.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: magnetometer: ak8974: Fix runtime PM imbalance on error 2020-07-22T07:32:54+00:00 Dinghao Liu dinghao.liu@zju.edu.cn 2020-05-26T10:47:17+00:00 ead750685280f60a24c3ca954aa89abfbffadff0 commit 0187294d227dfc42889e1da8f8ce1e44fc25f147 upstream. When devm_regmap_init_i2c() returns an error code, a pairing runtime PM usage counter decrement is needed to keep the counter balanced. For error paths after ak8974_set_power(), ak8974_detect() and ak8974_reset(), things are the same. However, When iio_triggered_buffer_setup() returns an error code, there will be two PM usgae counter decrements. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 0187294d227dfc42889e1da8f8ce1e44fc25f147 upstream.

When devm_regmap_init_i2c() returns an error code, a pairing
runtime PM usage counter decrement is needed to keep the
counter balanced. For error paths after ak8974_set_power(),
ak8974_detect() and ak8974_reset(), things are the same.

However, When iio_triggered_buffer_setup() returns an error
code, there will be two PM usgae counter decrements.

Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio:magnetometer:ak8974: Fix alignment and data leak issues 2020-07-22T07:32:53+00:00 Jonathan Cameron Jonathan.Cameron@huawei.com 2020-06-07T15:53:49+00:00 7cc8cad2bef94917a3d0b133afeb9626852385c9 commit 838e00b13bfd4cac8b24df25bfc58e2eb99bcc70 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc so no data can leak appart from previous readings. Fixes: 7c94a8b2ee8cf ("iio: magn: add a driver for AK8974") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 838e00b13bfd4cac8b24df25bfc58e2eb99bcc70 upstream.

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here.  We close both issues by
moving to a suitable structure in the iio_priv() data.

This data is allocated with kzalloc so no data can leak appart from
previous readings.

Fixes: 7c94a8b2ee8cf ("iio: magn: add a driver for AK8974")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: magnetometer: ak8974: Fix negative raw values in sysfs 2020-03-25T07:25:53+00:00 Stephan Gerhold stephan@gerhold.net 2020-02-14T11:03:24+00:00 a79f53a2f5afd490f39e226ed82728c2dc5f15cb commit b500c086e4110829a308c23e83a7cdc65b26228a upstream. At the moment, reading from in_magn_*_raw in sysfs tends to return large values around 65000, even though the output of ak8974 is actually limited to ±32768. This happens because the value is never converted to the signed 16-bit integer variant. Add an explicit cast to s16 to fix this. Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Waleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b500c086e4110829a308c23e83a7cdc65b26228a upstream.

At the moment, reading from in_magn_*_raw in sysfs tends to return
large values around 65000, even though the output of ak8974 is actually
limited to ±32768. This happens because the value is never converted
to the signed 16-bit integer variant.

Add an explicit cast to s16 to fix this.

Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Waleij <linus.walleij@linaro.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio:st_sensors: remove buffer allocation at each buffer enable 2019-08-11T08:26:04+00:00 Denis Ciocca denis.ciocca@st.com 2019-08-05T18:57:11+00:00 e031d5f558f1535968df1ecae8d734b84c17f78d This patch is removing the buffer allocation at each buffer enable. We just allocate enough memory in the main structure during probe to cover maximum size needed (that anyway is pretty small) [16bytes]. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
This patch is removing the buffer allocation at each buffer enable.
We just allocate enough memory in the main structure during probe
to cover maximum size needed (that anyway is pretty small) [16bytes].

Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: remove get_irq_data_ready() function pointer and use IRQ number directly 2019-08-05T15:50:08+00:00 Denis Ciocca denis.ciocca@st.com 2019-08-02T17:59:13+00:00 9cd15d521a3adcb687a0f9a312e32caaa94f44c2 Not even sure why it was there since the beginning. Just use IRQ number in the sensor_data struct. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Not even sure why it was there since the beginning. Just use IRQ
number in the sensor_data struct.

Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio:magn: preenable/postenable/predisable fixup for ST magn buffer 2019-08-05T14:49:18+00:00 Denis Ciocca denis.ciocca@st.com 2019-07-31T21:48:59+00:00 6ee19af415c55f8fee565613a2fa7892030ca9ac This patch is trying to cleanup for good the buffers operation functions. Let's rename the goto label using operation to perform and not where it fails. Not stable material as not fixing a 'bug' but rather bringing the driver in line with general 'patterns' to allow a subsystem wide cleanup. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
This patch is trying to cleanup for good the buffers operation functions.
Let's rename the goto label using operation to perform and not
where it fails.

Not stable material as not fixing a 'bug' but rather bringing the
driver in line with general 'patterns' to allow a subsystem wide
cleanup.

Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: magnetometer: mmc35240: Fix a typo in the name of a constant 2019-07-27T21:52:07+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2019-07-21T21:35:33+00:00 3f2cde742632226a86b54b2f8ed9cf5c4f50638c Everything is about mmc35240_ except MMC53240_WAIT_SET_RESET (3 and 5 switched). This is likely a typo. Define and use MMC35240_WAIT_SET_RESET instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
Everything is about mmc35240_ except MMC53240_WAIT_SET_RESET (3 and 5
switched).

This is likely a typo. Define and use MMC35240_WAIT_SET_RESET instead.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: make st_sensors drivers use regmap 2019-07-27T21:52:06+00:00 Denis Ciocca denis.ciocca@st.com 2019-07-18T22:53:53+00:00 062809ef7733209312562e87cefc84a470430929 This patch is meant to replace the i2c/spi transfer functions with regmap. SPI framework requires DMA safe buffers so let's add GFP_DMA flag for memory allocation used by bulk_read functions. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> 
This patch is meant to replace the i2c/spi transfer functions with
regmap. SPI framework requires DMA safe buffers so let's add GFP_DMA
flag for memory allocation used by bulk_read functions.

Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>