08 Oct, 2020
1 commit
-
* tag 'v5.4.70': (3051 commits)
Linux 5.4.70
netfilter: ctnetlink: add a range check for l3/l4 protonum
ep_create_wakeup_source(): dentry name can change under you...
...Conflicts:
arch/arm/mach-imx/pm-imx6.c
arch/arm64/boot/dts/freescale/imx8mm-evk.dts
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
drivers/crypto/caam/caamalg.c
drivers/gpu/drm/imx/dw_hdmi-imx.c
drivers/gpu/drm/imx/imx-ldb.c
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
drivers/mmc/host/sdhci-esdhc-imx.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/net/ethernet/freescale/enetc/enetc.c
drivers/net/ethernet/freescale/enetc/enetc_pf.c
drivers/thermal/imx_thermal.c
drivers/usb/cdns3/ep0.c
drivers/xen/swiotlb-xen.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.cSigned-off-by: Jason Liu
07 Oct, 2020
1 commit
-
commit fdb29f4de1374483291232ae7515e5e7bb464762 upstream.
Remove superfluous '.c' from qcom-spmi-adc5 device driver name.
Fixes: e13d757279bb ("iio: adc: Add QCOM SPMI PMIC5 ADC driver")
Signed-off-by: Dmitry Baryshkov
Acked-by: Manivannan Sadhasivam
Cc:
Link: https://lore.kernel.org/r/20200910140000.324091-2-dmitry.baryshkov@linaro.org
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
17 Sep, 2020
17 commits
-
commit 89226a296d816727405d3fea684ef69e7d388bd8 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 a 16 byte u8 array 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 with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.The additional forcing of the 8 byte alignment of the timestamp
is not strictly necessary but makes the code less fragile by
making this explicit.Fixes: c7eeea93ac60 ("iio: Add Freescale MMA8452Q 3-axis accelerometer driver")
Reported-by: Lars-Peter Clausen
Cc: Peter Meerwald
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 7e5ac1f2206eda414f90c698fe1820dee873394d 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 a 16 byte u8 array 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 with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.The force alignment of ts is not strictly necessary in this particularly
case but does make the code less fragile.Fixes: a84ef0d181d9 ("iio: accel: add Freescale MMA7455L/MMA7456L 3-axis accelerometer driver")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Cc:
Reviewed-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
commit 95ad67577de4ea08eb8e441394e698aa4addcc0b upstream.
iio_push_to_buffers_with_timestamp assumes 8 byte alignment which
is not guaranteed by an array of smaller elements.Note that whilst in this particular case the alignment forcing
of the ts element is not strictly necessary it acts as good
documentation. Doing this where not necessary should cut
down on the number of cut and paste introduced errors elsewhere.Fixes: 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit eb1a148ef41d8ae8d9201efc3f1b145976290331 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 with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.The explicit alignment of ts is necessary to ensure consistent
padding for x86_32 in which the ts would otherwise be 4 byte aligned.Fixes: 283d26917ad6 ("iio: chemical: ccs811: Add triggered buffer support")
Reported-by: Lars-Peter Clausen
Cc: Narcisa Ana Maria Vasile
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 523628852a5f5f34a15252b2634d0498d3cfb347 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 a 16 byte 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().
This data is allocated with kzalloc so no data can leak appart
from previous readings.It is necessary to force the alignment of ts to avoid the padding
on x86_32 being different from 64 bit platorms (it alows for
4 bytes aligned 8 byte types.Fixes: 06ad7ea10e2b ("max44000: Initial triggered buffer support")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
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
Cc: Gregor Boirie
Cc: Linus Walleij
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 54f82df2ba86e2a8e9cbf4036d192366e3905c89 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().This data is allocated with kzalloc so no data can leak apart
from previous readings.The eplicit alignment of ts is necessary to ensure correct padding
on x86_32 where s64 is only aligned to 4 bytes.Fixes: 08e05d1fce5c ("ti-adc081c: Initial triggered buffer support")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit db8f06d97ec284dc018e2e4890d2e5035fde8630 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 necessary to ensure correct padding
on architectures where s64 is only 4 bytes aligned such as x86_32.Fixes: a9e9c7153e96 ("iio: adc: add max1117/max1118/max1119 ADC driver")
Reported-by: Lars-Peter Clausen
Cc: Akinobu Mita
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit f8cd222feb82ecd82dcf610fcc15186f55f9c2b5 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 a 32 byte 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 with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak apart from previous readings. The explicit alignment
isn't technically needed here, but it reduced fragility and avoids
cut and paste into drivers where it will be needed.If we want this in older stables will need manual backport due to
driver reworks.Fixes: c43a102e67db ("iio: ina2xx: add support for TI INA2xx Power Monitors")
Reported-by: Lars-Peter Clausen
Cc: Stefan Brüns
Cc: Marc Titinger
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit a661b571e3682705cb402a5cd1e970586a3ec00f 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().This data is allocated with kzalloc so no data can leak apart from
previous readings.The force alignment of ts is not strictly necessary in this case
but reduces the fragility of the code.Fixes: 3691e5a69449 ("iio: adc: add driver for the ti-adc084s021 chip")
Reported-by: Lars-Peter Clausen
Cc: Mårten Lindahl
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit a6f86f724394de3629da63fe5e1b7a4ab3396efe 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 a 16 byte 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 with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.Fixes tag is beyond some major refactoring so likely manual backporting
would be needed to get that far back.Whilst the force alignment of the ts is not strictly necessary, it
does make the code less fragile.Fixes: 3bbec9773389 ("iio: bmc150_accel: add support for hardware fifo")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Acked-by: Srinivas Pandruvada
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit f60e8bb84282b8e633956cfe74b4f0d64ca73cec 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 a 16 byte s16 array 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 with alignment
ensured by use of an explicit c structure. This data is allocated
with kzalloc so no data can leak appart from previous readings.In this case the forced alignment of the ts is necessary to ensure
correct padding on x86_32 where the s64 would only be 4 byte aligned.Fixes: 16b05261537e ("mb1232.c: add distance iio sensor with i2c")
Reported-by: Lars-Peter Clausen
Cc: Andreas Klinger
Signed-off-by: Jonathan Cameron
Cc:
Reviewed-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
commit 2684d5003490df5398aeafe2592ba9d4a4653998 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.
Here we use a structure on the stack. The driver already did an
explicit memset so no data leak was possible.Forced alignment of ts is not strictly necessary but probably makes
the code slightly less fragile.Note there has been some rework in this driver of the years, so no
way this will apply cleanly all the way back.Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 336306790b2bbf7ce837625fa3b24ba724d05838 upstream.
BMI160 Minimium gyroscope frequency in normal mode is 25Hz.
When older EC firmware do not report their sensors frequencies,
use 25Hz as the minimum for gyroscope to be sure it works on BMI160.Fixes: ae7b02ad2f32d ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou
Reviewed-by: Enric Balletbo i Serra
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit e71e6dbe96ac80ac2aebe71a6a942e7bd60e7596 upstream.
To stop conversion ads1015_set_power_state() function call unimplemented
function __pm_runtime_suspend() from pm_runtime_put_autosuspend()
if CONFIG_PM is not set.
In case of CONFIG_PM is not set: __pm_runtime_suspend() returns -ENOSYS,
so ads1015_read_raw() failed because ads1015_set_power_state() returns an
error.If CONFIG_PM is disabled, there is no need to start/stop conversion.
Fix it by adding return 0 function variant if CONFIG_PM is not set.Signed-off-by: Maxim Kochetkov
Fixes: ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support")
Tested-by: Maxim Kiselev
Reviewed-by: Andy Shevchenko
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 3f1093d83d7164e4705e4232ccf76da54adfda85 upstream.
Locking should be held for the entire reading sequence involving setting
the channel, waiting for the channel switch and reading from the
channel.
If not, reading from a channel can result mixing with the reading from
another channel.Fixes: 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC")
Signed-off-by: Angelo Compagnucci
Link: https://lore.kernel.org/r/20200819075525.1395248-1-angelo.compagnucci@gmail.com
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a139ffa40f0c24b753838b8ef3dcf6ad10eb7854 ]
Reading from the chip should be unlocked on error path else the lock
could never being released.Fixes: 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC")
Fixes: 3f1093d83d71 ("iio: adc: mcp3422: fix locking scope")
Acked-by: Jonathan Cameron
Signed-off-by: Angelo Compagnucci
Link: https://lore.kernel.org/r/20200901093218.1500845-1-angelo.compagnucci@gmail.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
21 Aug, 2020
1 commit
-
commit 65afb0932a81c1de719ceee0db0b276094b10ac8 upstream.
There are 2 exit paths where the lock isn't held, but try to unlock the
mutex when exiting. In these places we should just return from the
function.A neater approach would be to cleanup the ad5592r_read_raw(), but that
would make this patch more difficult to backport to stable versions.Fixes 56ca9db862bf3: ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
Reported-by: Charles Stanhope
Signed-off-by: Alexandru Ardelean
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2020
11 commits
-
[ Upstream commit b0536f9826a5ed3328d527b4fc1686867a9f3041 ]
If 'ad7780_init_gpios()' fails, we must not release some resources that
have not been allocated yet. Return directly instead.Fixes: 5bb30e7daf00 ("staging: iio: ad7780: move regulator to after GPIO init")
Fixes: 9085daa4abcc ("staging: iio: ad7780: add gain & filter gpio support")
Signed-off-by: Christophe JAILLET
Acked-by: Renato Lui Geh
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
[ Upstream commit f88ecccac4be348bbcc6d056bdbc622a8955c04d ]
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 a 40 byte 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 with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.Fixes: 87aec56e27ef ("iio: health: Add driver for the TI AFE4404 heart monitor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Acked-by: Andrew F. Davis
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
commit 3f9c6d38797e9903937b007a341dad0c251765d6 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 a 32 byte 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 with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.Fixes: eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Acked-by: Andrew F. Davis
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 8db4afe163bbdd93dca6fcefbb831ef12ecc6b4d 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.
Here there is no data leak possibility so use an explicit structure
on the stack to ensure alignment and nice readable fashion.The forced alignment of ts isn't strictly necessary in this driver
as the padding will be correct anyway (there isn't any). However
it is probably less fragile to have it there and it acts as
documentation of the requirement.Fixes: 713bbb4efb9dc ("iio: pressure: ms5611: Add triggered buffer support")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Acked-by: Tomasz Duszynski
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 5c49056ad9f3c786f7716da2dd47e4488fc6bd25 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.Explicit alignment of ts needed to ensure consistent padding
on all architectures (particularly x86_32 with it's 4 byte alignment
of s64)Fixes: e4a70e3e7d84 ("iio: humidity: add support to hts221 rh/temp combo device")
Reported-by: Lars-Peter Clausen
Acked-by: Lorenzo Bianconi
Signed-off-by: Jonathan Cameron
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit d88de040e1df38414fc1e4380be9d0e997ab4d58 upstream.
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count. Call pm_runtime_put if
pm_runtime_get_sync fails.Signed-off-by: Navid Emamdoost
Fixes: 03b262f2bbf4 ("iio:pressure: initial zpa2326 barometer support")
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit d7369ae1f4d7cffa7574d15e1f787dcca184c49d upstream.
The function iio_device_register() was called in mma8452_probe().
But the function iio_device_unregister() was not called after
a call of the function mma8452_set_freefall_mode() failed.
Thus add the missed function call for one error case.Fixes: 1a965d405fc6 ("drivers:iio:accel:mma8452: added cleanup provision in case of failure.")
Signed-off-by: Chuhong Yuan
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 25f02d3242ab4d16d0cee2dec0d89cedb3747fa9 upstream.
Add missing strings to iio_modifier_names[] for proper modification
of channels.Fixes: b170f7d48443d (iio: Add modifiers for ethanol and H2 gases)
Signed-off-by: Matt Ranostay
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
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
Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Reviewed-by: Linus Walleij
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit ea5e7a7bb6205d24371373cd80325db1bc15eded 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.Fixes: 16bf793f86b2 ("iio: humidity: hdc100x: add triggered buffer support for HDC100X")
Reported-by: Lars-Peter Clausen
Acked-by: Matt Ranostay
Cc: Alison Schofield
Signed-off-by: Jonathan Cameron
Cc:
Signed-off-by: Greg Kroah-Hartman -
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
Reviewed-by: Linus Walleij
Signed-off-by: Jonathan Cameron
Cc:
Signed-off-by: Greg Kroah-Hartman
24 Jun, 2020
2 commits
-
[ Upstream commit dee2dabc0e4115b80945fe2c91603e634f4b4686 ]
Limit the output of humidity compensation to the range between 0 and 100
percent.Depending on the calibration parameters of the individual sensor it
happens, that a humidity above 100 percent or below 0 percent is
calculated, which don't make sense in terms of relative humidity.Add a clamp to the compensation formula as described in the datasheet of
the sensor in chapter 4.2.3.Although this clamp is documented, it was never in the driver of the
kernel.It depends on the circumstances (calibration parameters, temperature,
humidity) if one can see a value above 100 percent without the clamp.
The writer of this patch was working with this type of sensor without
noting this error. So it seems to be a rare event when this bug occures.Signed-off-by: Andreas Klinger
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
[ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ]
With DEBUG_SHIRQ enabled we have a kernel crash
[ 116.482696] BUG: kernel NULL pointer dereference, address: 0000000000000000
...
[ 116.606571] Call Trace:
[ 116.609023]
[ 116.611047] complete+0x34/0x50
[ 116.614206] bmp085_eoc_irq+0x9/0x10 [bmp280]because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers
ought to be able to handle an interrupt happening before request_irq() returns.Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
19 Jun, 2020
1 commit
-
* tag 'v5.4.47': (2193 commits)
Linux 5.4.47
KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
...Conflicts:
arch/arm/boot/dts/imx6qdl.dtsi
arch/arm/mach-imx/Kconfig
arch/arm/mach-imx/common.h
arch/arm/mach-imx/suspend-imx6.S
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
arch/powerpc/include/asm/cacheflush.h
drivers/cpufreq/imx6q-cpufreq.c
drivers/dma/imx-sdma.c
drivers/edac/synopsys_edac.c
drivers/firmware/imx/imx-scu.c
drivers/net/ethernet/freescale/fec.h
drivers/net/ethernet/freescale/fec_main.c
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
drivers/net/phy/phy_device.c
drivers/perf/fsl_imx8_ddr_perf.c
drivers/usb/cdns3/gadget.c
drivers/usb/dwc3/gadget.c
include/uapi/linux/dma-buf.hSigned-off-by: Jason Liu
11 Jun, 2020
4 commits
-
commit 10134ec3f8cefa6a40fe84987f1795e9e0da9715 upstream.
A wrong error message is printed out currently, like on STM32MP15:
- stm32-adc-core 48003000.adc: IRQ index 2 not found.This is seen since commit 7723f4c5ecdb ("driver core: platform: Add an
error message to platform_get_irq*()").
The STM32 ADC core driver wrongly requests up to 3 interrupt lines. It
should request only the necessary IRQs, based on the compatible:
- stm32f4/h7 ADCs share a common interrupt
- stm32mp1, has one interrupt line per ADC.
So add the number of required interrupts to the compatible data.Fixes: d58c67d1d851 ("iio: adc: stm32-adc: add support for STM32MP1")
Signed-off-by: Fabrice Gasnier
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 13e945631c2ffb946c0af342812a3cd39227de6e 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 with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.Fixes: a1d642266c14 ("iio: chemical: add support for Plantower PMS7003 sensor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Cc:
Acked-by: Tomasz Duszynski
Signed-off-by: Greg Kroah-Hartman -
commit 18dfb5326370991c81a6d1ed6d1aeee055cb8c05 upstream.
The bytes returned by the i2c reading need to be swapped
unconditionally. Otherwise, on be16 platforms, an incorrect value will be
returned.Taking the slow path via next merge window as its been around a while
and we have a patch set dependent on this which would be held up.Fixes: 62a1efb9f868 ("iio: add vcnl4000 combined ALS and proximity sensor")
Signed-off-by: Mathieu Othacehe
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit a5bf6fdd19c327bcfd9073a8740fa19ca4525fd4 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.Fixes: 232e0f6ddeae ("iio: chemical: add support for Sensirion SPS30 sensor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Cc:
Acked-by: Tomasz Duszynski
Signed-off-by: Greg Kroah-Hartman
27 May, 2020
2 commits
-
[ Upstream commit b455d06e6fb3c035711e8aab1ca18082ccb15d87 ]
DMA channel request should use device struct from platform device struct.
Currently it's using iio device struct. But at this stage when probing,
device struct isn't yet registered (e.g. device_register is done in
iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create
symlinks between DMA channels and slaves"), a warning message is printed
as the links in sysfs can't be created, due to device isn't yet registered:
- Cannot create DMA slave symlink
- Cannot create DMA dma:rx symlinkFix this by using device struct from platform device to request dma chan.
Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone")
Signed-off-by: Fabrice Gasnier
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
[ Upstream commit a9ab624edd9186fbad734cfe5d606a6da3ca34db ]
dma_request_slave_channel() is a wrapper on top of dma_request_chan()
eating up the error code.By using dma_request_chan() directly the driver can support deferred
probing against DMA.Signed-off-by: Peter Ujfalusi
Acked-by: Olivier Moysan
Acked-by: Fabrice Gasnier
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
