Jonathan Cameron [Wed, 22 Jul 2020 15:50:53 +0000 (16:50 +0100)]
iio:imu:inv_mpu6050 Fix dma and ts alignment and data leak issues.
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> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722155103.979802-18-jic23@kernel.org
Jonathan Cameron [Wed, 22 Jul 2020 15:51:01 +0000 (16:51 +0100)]
iio:adc:ti-adc12138 Fix alignment issue with timestamp
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.
We move 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. Note that previously
no leak at all could occur, but previous readings should never
be a problem.
In this case the timestamp location depends on what other channels
are enabled. As such we can't use a structure without misleading
by suggesting only one possible timestamp location.
Fixes: 50a6edb1b6e0 ("iio: adc: add ADC12130/ADC12132/ADC12138 ADC driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722155103.979802-26-jic23@kernel.org
Jonathan Cameron [Wed, 22 Jul 2020 15:51:00 +0000 (16:51 +0100)]
iio:adc:ti-adc0832 Fix alignment issue with timestamp
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.
We fix this 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.
Note that previously no data could leak 'including' previous readings
but I don't think it is an issue to potentially leak them like
this now does.
In this case the postioning of the timestamp is depends on what
other channels are enabled. As such we cannot use a structure to
make the alignment explicit as it would be missleading by suggesting
only one possible location for the timestamp.
Fixes: 815bbc87462a ("iio: ti-adc0832: add triggered buffer support") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Akinobu Mita <akinobu.mita@gmail.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722155103.979802-25-jic23@kernel.org
Jonathan Cameron [Wed, 22 Jul 2020 15:50:52 +0000 (16:50 +0100)]
iio:imu:st_lsm6dsx Fix alignment and data leak issues
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 an array of suitable structures in the iio_priv() data.
This data is allocated with kzalloc so no data can leak apart from
previous readings.
For the tagged path the data is aligned by using __aligned(8) for
the buffer on the stack.
There has been a lot of churn in this driver, so likely backports
may be needed for stable.
Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722155103.979802-17-jic23@kernel.org
Jonathan Cameron [Wed, 22 Jul 2020 15:50:44 +0000 (16:50 +0100)]
iio:light:si1145: Fix timestamp alignment and prevent data leak.
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 24 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 array in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.
Depending on the enabled channels, the location of the timestamp
can be at various aligned offsets through the buffer. As such we
any use of a structure to enforce this alignment would incorrectly
suggest a single location for the timestamp. Comments adjusted to
express this clearly in the code.
Fixes: ac45e57f1590 ("iio: light: Add driver for Silabs si1132, si1141/2/3 and si1145/6/7 ambient light, uv index and proximity sensors") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722155103.979802-9-jic23@kernel.org
Jonathan Cameron [Wed, 22 Jul 2020 15:50:41 +0000 (16:50 +0100)]
iio:gyro:itg3200: Fix timestamp alignment and prevent data leak.
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.
This is fixed by using an explicit c structure. As there are no
holes in the structure, there is no possiblity of data leakage
in this case.
The explicit alignment of ts is not strictly necessary but potentially
makes the code slightly less fragile. It also removes the possibility
of this being cut and paste into another driver where the alignment
isn't already true.
Fixes: 36e0371e7764 ("iio:itg3200: Use iio_push_to_buffers_with_timestamp()") Reported-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722155103.979802-6-jic23@kernel.org
iio: adc: exynos_adc: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock, to protect potential concurrent access to the
completion callback during a conversion.
Fairly straight conversion. The one oddity in the original binding
is that spi-cpha and spi-cpol were not marked as required, but were
in the example. Looking at the datasheet, there isn't any documented
flexibility in the possible SPI modes, so I have moved these to requires.
For spi-max-frequency I have gone the other way. I absolutely agree
that it is good to specify this in the dt-binding, but it's not
strictly required.
As Stefan's email is bouncing I have gone with Michael as maintainer
of this one as it falls under the ADI catch all entry in MAINTAINERS.
Simple SPI driver. I've added the #io-channel-cells
as an optional parameter to allow use of this device as a provider
of ADC capabilities to other devices.
Renamed to remove the wild cards. These go wrong far too often so
in general preferred to use the name of a specific part. As this
binding only provides one compatible, I went with that.
This binding has a few corners that would have been done different today
but hopefully the yaml schema captures the constraints correctly.
The child node names are not constrained hence the fairly open regexp.
I've also documented the defaults for the two references that the
driver seems to use and copied the value descriptions from the header
because I think they should be in the dt-binding itself.
This is part of a general effort to convert all the IIO bindings
over to yaml
Unfortunately I don't have a current address for Markus, so
have put myself as the maintainer for this binding until someone else
steps up!
Renamed the file to reflect the only compatible.
Added #io-channel-cells to make it easier to support consumers of the
ADC channels this device provides.
A simple conversion from txt file to yaml. I added the #io-channel-cells
property as optional to allow the channels of this ADCs to be used
to provide services to other drivers, for example if an analog
accelerometer is connected.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20200909175946.395313-8-jic23@kernel.org
I changed the name to reflect a specific part in line with normal
naming conventions. If there is a particularly strong reason to
keep the wild cards let me know.
Otherwise this was a fairly simple conversion as part of converting
all the IIO bindings to yaml.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang7@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lore.kernel.org/r/20200909175946.395313-7-jic23@kernel.org
Simple txt to yaml conversion. Part of a general move to convert
all the IIO bindings over to yaml.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Joel Stanley <joel@jms.id.au> Cc: Rick Altherr <raltherr@google.com> Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20200909175946.395313-5-jic23@kernel.org
Conversion from freeform text to yaml.
One oddity in this binding is that, for historical reasons it requires
the node name to be stmpe_adc. I've put that in the decription field
but I'm not sure if there is a better way to specify this?
dt-bindings:iio:adc:fsl,vf610-adc conversion to yaml.
A simple conversion of this freescale ADC binding from txt to yaml.
For maintainer I went with Fugang Duan as the original author of the
binding. Would be great to have confirmation of this.
Mario Tesi [Thu, 17 Sep 2020 16:47:16 +0000 (18:47 +0200)]
iio: imu: st_lsm6dsx: Scaling factor type set to IIO_VAL_INT_PLUS_NANO
Scaling factor values for Acc lead to an unacceptable rounding of the
full scale (FS) calculated by some SensorHAL on Android devices. For examples
setting FS to 4g the in_accel_x_scale, in_accel_y_scale and in_accel_z_scale
are 0.001196 on 6 decimal digits and the FS is
0.001196 × ((2^15) − 1) ~= 39.1893 m/s^2.
Android CTS R10 SensorParameterRangeTest test expects a value greater than
39.20 m/s^2 so this test fails (ACCELEROMETER_MAX_RANGE = 4 * 9.80).
Using 9 decimal digits the new scale factor is 0.001196411 and the FS now
is 0.001196411 × ((2^15)−1) ~= 39.2028 m/s^2.
This patch extends to IIO_VAL_INT_PLUS_NANO type the scaling factor to all
IMU devices where SensorParameterRangeTest CTS test fails.
Nuno Sá [Thu, 17 Sep 2020 15:52:20 +0000 (17:52 +0200)]
iio: adis: Move burst mode into adis_data
Add burst mode variables in the per device specific data structure. As
some drivers support multiple devices with different burst sizes it
makes sense this data to be in `adis_data`. While moving the variables,
there are two main differences:
1. The `en`variable is dropped. If a device supports burst mode, it will
just use it as it will has better performance for almost all real use
cases.
2. Replace `extra_len` by `burst_len`. Users should now explicitly
define the length of the burst buffer as it is typically constant. This
also allows to remove the following line from the library:
```
/* All but the timestamp channel */
burst_length = (indio_dev->num_channels - 1) * sizeof(u16);
```
The library should not assume that a timestamp channel is defined.
Moreover, most parts also include some diagnostic data, crc, etc.. in
the burst buffer that needed to be included in an `extra_len` variable
which is not that nice. On top of this, some devices already start to
have some 32bit size channels ...
This patch is also a move to completely drop the `struct adis_burst`
from the library.
Jonathan Cameron [Sun, 13 Sep 2020 11:25:46 +0000 (12:25 +0100)]
iio:magn:hmc5843: Fix passing true where iio_shared_by enum required.
So it's obvious that the code is wrong in passing true, but I'm assuming
that will actually evaluate to 1 and hence IIO_SHARED_BY_TYPE.
The documentation however has this attribute as IIO_SHARED_BY_ALL.
My current assumption is the documentation is wrong.
If anyone knows otherwise please shout out!
Fixes: 7247645f6865 ("iio: hmc5843: Move hmc5843 out of staging") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/20200913112546.715624-1-jic23@kernel.org
iio: dac: ad5592r: localize locks only where needed in ad5592r_read_raw()
Since there was a recently discovered issue with these locks, it probably
makes sense to cleanup the code a bit, to prevent it from being used as an
example/reference.
This change moves the lock only where it is explicitly needed to protect
resources from potential concurrent accesses.
It also reworks the switch statements to do direct returns vs caching the
return value on a variable.
Jonathan Cameron [Wed, 22 Jul 2020 14:25:15 +0000 (15:25 +0100)]
iio:dac:ad5592r: Fix use of true for IIO_SHARED_BY_TYPE
struct iio_chan_spec_ext_info shared element is of type
enum iio_shared_by, not boolean. It's like the enum value
will for IIO_SHARED_BY_TYPE == 1 == true, hence no actual
problem has been observed.
CC [M] drivers/iio/dac/ad5592r-base.o
491 | .shared = true,
|
Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200722142515.897378-1-jic23@kernel.org
Lee Jones [Thu, 16 Jul 2020 13:59:13 +0000 (14:59 +0100)]
iio: dummy: iio_dummy_evgen: Demote file header and supply description for 'irq_sim_domain'
File headers are not good candidates for kerneldoc.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dummy/iio_dummy_evgen.c:30: warning: Cannot understand * @regs: irq regs we are faking
on line 30 - I thought it was a doc line
drivers/iio/dummy/iio_dummy_evgen.c:42: warning: Function parameter or member 'irq_sim_domain' not described in 'iio_dummy_eventgen'
Lee Jones [Thu, 16 Jul 2020 13:59:15 +0000 (14:59 +0100)]
iio: adc: ad7949: Fix misspelling issue
Fixes the following W=1 kernel build warning(s):
drivers/iio/adc/ad7949.c:58: warning: Function parameter or member 'indio_dev' not described in 'ad7949_adc_chip'
Signed-off-by: Lee Jones <lee.jones@linaro.org> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Charles-Antoine Couret <charles-antoine.couret@essensium.com> Link: https://lore.kernel.org/r/20200716135928.1456727-18-lee.jones@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Lee Jones [Thu, 16 Jul 2020 13:59:17 +0000 (14:59 +0100)]
iio: dac: ad5064: Fix a few kerneldoc misdemeanours
Misspelling, missing description.
Fixes the following W=1 kernel build warning(s):
drivers/iio/dac/ad5064.c:71: warning: bad line: internal vref.
drivers/iio/dac/ad5064.c:83: warning: Function parameter or member 'channels' not described in 'ad5064_chip_info'
drivers/iio/dac/ad5064.c:125: warning: Function parameter or member 'lock' not described in 'ad5064_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200716135928.1456727-20-lee.jones@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vdd_reg' not described in 'ad7303_state'
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'vref_reg' not described in 'ad7303_state'
drivers/iio/dac/ad7303.c:49: warning: Function parameter or member 'lock' not described in 'ad7303_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200716135928.1456727-31-lee.jones@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio: adc: fsl-imx25-gcq: Replace indio_dev->mlock with own device lock
As part of the general cleanup of indio_dev->mlock, this change replaces
it with a local lock, to protect against any other accesses during the
reading of sample. Reading a sample requires multiple consecutive regmap
operations and a completion callback, so this requires that no other
read occurs until it completes.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:42 +0000 (18:32 +0100)]
iio:health:max30102: Drop of_match_ptr and use generic fw accessors
This enables use of the driver with ACPI PRP0001 and also removes
an antipattern that I am trying to clear out of IIO to avoid
it being copied into new drivers.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:41 +0000 (18:32 +0100)]
iio:humidity:si7020: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:40 +0000 (18:32 +0100)]
iio:humidity:htu21: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:39 +0000 (18:32 +0100)]
iio:magn:ak8974: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:38 +0000 (18:32 +0100)]
iio:magn:ak8975: Drop of_match_ptr and ACPI_PTR protections.
Both would result in only a small size saving. For simplicity it
is best to remove them. I also wish to remove both these antipatterns
from IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Jonathan Albrieux <jonathan.albrieux@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Jonathan Albrieux <jonathan.albrieux@gmail.com> Link: https://lore.kernel.org/r/20200910173242.621168-35-jic23@kernel.org
Jonathan Cameron [Thu, 10 Sep 2020 17:32:37 +0000 (18:32 +0100)]
iio:proximity:pulsedlight: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:34 +0000 (18:32 +0100)]
iio:humidity:hdc100x: Drop of_match_ptr protection.
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:30 +0000 (18:32 +0100)]
iio:chemical:sgp30: Use local variable dev to simplify code
This cleans up the code at bit, but is primarily here as a precusor
to the next patch. I've only done this for the two functions
which use the dev pointer repeatedly.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:29 +0000 (18:32 +0100)]
iio:chemical:atlas-sensor: Drop of_match_ptr and use generic fw accessors
of_match_ptr() prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver and use generic fw accessors to check
if there is a fw_node and get the id.
It might be neater to use pointers rather than indexes for
the device_data but that is another issue and should be handled
separately.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:28 +0000 (18:32 +0100)]
iio:chemical:ams-iaq-core: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:27 +0000 (18:32 +0100)]
iio:resolver:ad2s1200: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:26 +0000 (18:32 +0100)]
iio:temperature:tmp007: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:25 +0000 (18:32 +0100)]
iio:temperature:tsys01: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:24 +0000 (18:32 +0100)]
iio:pressure:zpa2326: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:23 +0000 (18:32 +0100)]
iio:pressure:ms5637: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:22 +0000 (18:32 +0100)]
iio:pressure:ms5611: Drop of_match_ptr and CONFIG_OF protections
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:21 +0000 (18:32 +0100)]
iio:pressure:icp10100: Drop of_match_ptr and CONFIG_OF protections
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:19 +0000 (18:32 +0100)]
iio:dac:ti-dac5571: Drop of_match_ptr and CONFIG_OF protections
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:18 +0000 (18:32 +0100)]
iio:dac:ti-dac082s085: Drop of_match_ptr and CONFIG_OF protections
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:17 +0000 (18:32 +0100)]
iio:dac:mcp4725: drop of_match_ptr and use generic fw properties
This enables use of ACPI PRP0001 and removes an antipattern I am
trying to stop people copying in IIO.
This particular case is more complex than most because it allowed
probing via sysfs with out a fwnode but would presumably always
have then failed. Now the code will assume that properties are
the defaults if not specified or the firmware node is not present.
This relaxation of the constraints should not break any existing
cases and may enable some new ones.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:15 +0000 (18:32 +0100)]
iio:dac:ad5593r: Drop of_match_ptr and ACPI_PTR protections.
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20200910173242.621168-12-jic23@kernel.org
Jonathan Cameron [Thu, 10 Sep 2020 17:32:14 +0000 (18:32 +0100)]
iio:dac:ad5592r: Drop of_match_ptr and ACPI_PTR protections.
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20200910173242.621168-11-jic23@kernel.org
Jonathan Cameron [Thu, 10 Sep 2020 17:32:13 +0000 (18:32 +0100)]
iio:dac:ad5446: Drop of_match_ptr and CONFIG_OF protections
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:12 +0000 (18:32 +0100)]
iio:potentiometer:mcp4531: Drop of_match_ptr and CONFIG_OF protections.
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Also switch to device_get_match_data() from of_ variant and adjust
headers to reflect the change.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:11 +0000 (18:32 +0100)]
iio:potentiometer:mcp4131: Drop of_match_ptr and use generic fw interfaces.
This change allows the use of the driver with ACPI via PRP0001
and remove an example of an anti pattern I'm trying to remove from IIO.
Also adjust includes to reflect this change.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:10 +0000 (18:32 +0100)]
iio:potentiometer:mcp4018: Drop of_match_ptr and CONFIG_OF protections.
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Also use device_get_match_data() rather than devicetree only version.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:08 +0000 (18:32 +0100)]
iio:potentiometer:max5481: Drop of_match_ptr and CONFIG_OF protections.
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Whilst this driver has an ACPI binding, it is not of a form
that is valid under ACPI so will be dropped shortly.
Also switch to device_get_match_data() and switch headers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Maury Anderson <maury.anderson@rockwellcollins.com> Cc: Matthew Weber <matthew.weber@rockwellcollins.com> Cc: Slawomir Stepien <sst@poczta.fm> Link: https://lore.kernel.org/r/20200910173242.621168-5-jic23@kernel.org
Jonathan Cameron [Thu, 10 Sep 2020 17:32:07 +0000 (18:32 +0100)]
iio:potentiometer:max5432: Drop of_match_ptr and use generic fw accessors
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:06 +0000 (18:32 +0100)]
iio:potentiometer:ds1803: Drop of_match_ptr and CONFIG_OF protections
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.
Also switch of.h for mod_devicetable.h include given use of
struct of_device_id which is defined in that header.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:05 +0000 (18:32 +0100)]
iio:potentiometer:ad5272: Drop of_match_ptr and CONFIG_OF protections.
These prevent use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Drop them to remove this restriction.
Also added mod_devicetable.h include given use of struct of_device_id
which is defined in that header.
Jonathan Cameron [Sun, 13 Sep 2020 13:21:13 +0000 (14:21 +0100)]
iio:imu:adis16400: Sort out missing kernel doc.
I'd like to be enable W=1 for all IIO builds as it catches real issues as well
as more minor documentation issues such as this (also good to fix though!)
drivers/iio/imu/adis16400.c:183: warning: Function parameter or member 'avail_scan_mask' not described in 'adis16400_state'
iio: buffer: split buffer sysfs creation to take buffer as primary arg
Currently the iio_buffer_{alloc,free}_sysfs_and_mask() take 'indio_dev' as
primary argument. This change splits the main logic into a private function
that takes an IIO buffer as primary argument.
That way, the functions can be extended to configure the sysfs for multiple
buffers.
iio: adc: meson-saradc: Make the of_device_id array style consistent
Use only one line for the closing bracket of the last entry and the
opening bracket for the next one to keep the style across the whole
array consistent. Also add a "sentinel" comment to the last entry and
remove the comma to ensure that there won't be any entry after it.
No functional changes.
There are no remaining light drivers in staging/iio.
The content of this file are either included in the non staging
ABI docs, or don't seem to be used in any current driver.
Whilst there is some useful info in here, it can be easily
obtained from datasheets. Some of the info should perhaps
be incorporated into a device tree bindings doc.
As this didn't move out of staging with the driver, I'm suggesting
we just drop it. We don't generally carry per driver documentation
with the exception of non standard ABI which is not the case here.
Nuno Sá [Tue, 15 Sep 2020 12:02:58 +0000 (14:02 +0200)]
iio: adis: Drop non Managed device functions
Drop `adis_setup_buffer_and_trigger()`. All users were updated to use
the devm version of this function. This avoids having almost the same
code repeated.
Nuno Sá [Tue, 15 Sep 2020 12:02:57 +0000 (14:02 +0200)]
staging: iio: adis16240: Use Managed device functions
Use the adis managed device functions to setup the buffer and the trigger.
The ultimate goal will be to completely drop the non devm version from
the lib.
Since we are here, drop the `.remove` callback by further using devm
functions.
projects / thirdparty / kernel / linux.git / log
