Tom Rix
f71e41e23e
iio:imu:st_lsm6dsx: check st_lsm6dsx_shub_read_output return
...
Potential error return is not checked. This can lead to use
of undefined data.
Detected by clang static analysis.
st_lsm6dsx_shub.c:540:8: warning: Assigned value is garbage or undefined
*val = (s16)le16_to_cpu(*((__le16 *)data));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: c91c1c844e ("iio: imu: st_lsm6dsx: add i2c embedded controller support")
Signed-off-by: Tom Rix <trix@redhat.com
Cc: <Stable@vger.kernel.org >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Link: https://lore.kernel.org/r/20200809175551.6794-1-trix@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 20:01:50 +01:00
Sergiu Cuciurean
d390ff735d
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.
This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com >
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com >
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org >
Link: https://lore.kernel.org/r/20200916093123.78954-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 20:01:50 +01:00
Mario Tesi
44a76de8ca
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.
Signed-off-by: Mario Tesi <mario.tesi@st.com >
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org >
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Link: https://lore.kernel.org/r/1600361236-2285-1-git-send-email-martepisa@gmail.com
2020-09-21 20:01:45 +01:00
Nuno Sá
0dfaa465fc
iio: adis16475: Drop adis_burst usage
...
Burst mode variables are now part of the `adis_data` struct. The driver
also has now to explicitly define the length of the burst buffer.
Signed-off-by: Nuno Sá <nuno.sa@analog.com >
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Link: https://lore.kernel.org/r/20200917155223.218500-4-nuno.sa@analog.com
2020-09-21 20:01:45 +01:00
Nuno Sá
f81d053bb4
iio: adis16400: Drop adis_burst usage
...
Burst mode variables are now part of the `adis_data` struct. The driver
also has now to explicitly define the length of the burst buffer.
Signed-off-by: Nuno Sá <nuno.sa@analog.com >
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Link: https://lore.kernel.org/r/20200917155223.218500-3-nuno.sa@analog.com
2020-09-21 20:01:45 +01:00
Nuno Sá
36e322ec5d
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.
Signed-off-by: Nuno Sá <nuno.sa@analog.com >
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Link: https://lore.kernel.org/r/20200917155223.218500-2-nuno.sa@analog.com
2020-09-21 20:01:45 +01:00
Jonathan Cameron
9e7c7d9274
iio:accel:bma180: Fix use of true when should be iio_shared_by enum
...
Given a value of 1 corresponds to IIO_SHARE_BY_TYPE I have replaced
it with that. Should cause no functional change.
Fixes: fdadbce0da ("iio: add Bosch BMA180 acceleration sensor driver")
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 >
Cc: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com >
Cc: Peter Meerwald <pmeerw@pmeerw.net >
Cc: Jonathan Bakker <xc-racer2@live.ca >
Link: https://lore.kernel.org/r/20200913121227.764626-1-jic23@kernel.org
2020-09-21 19:59:57 +01:00
Jonathan Cameron
e8a26c5b76
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: 7247645f68 ("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
2020-09-21 18:54:18 +01:00
Jonathan Cameron
cd7798cbd2
iio: Add __printf() attributes to various allocation functions
...
A partial set of these was added to IIO a long time back.
This fills in some gaps in coverage highlighted by building
with W=1
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Link: https://lore.kernel.org/r/20200913132115.800131-3-jic23@kernel.org
2020-09-21 18:54:18 +01:00
Jonathan Cameron
c9561fd21a
iio:core: Tidy up kernel-doc.
...
One comment isn't kernel-doc at all, but starts with /** and another
is simply missing a parameter that was introduced recently.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Acked-by: Alexandru Ardelean <alexandru.ardelean@analog.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Link: https://lore.kernel.org/r/20200913132115.800131-4-jic23@kernel.org
2020-09-21 18:54:18 +01:00
Alexandru Ardelean
c8bb10c50d
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.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com >
Link: https://lore.kernel.org/r/20200706110259.23947-3-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 18:54:18 +01:00
Alexandru Ardelean
b004fe3303
iio: dac: ad5592r: un-indent code-block for scale read
...
The next rework may require an unindentation of a code block in
ad5592r_read_raw(), which would make review a bit more difficult.
This change unindents the code block for reading the scale of the
non-temperature channels.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com >
Link: https://lore.kernel.org/r/20200706110259.23947-2-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 18:54:18 +01:00
Jonathan Cameron
5fe68a4d85
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: 56ca9db862 ("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
2020-09-21 18:53:23 +01:00
Lee Jones
ed33833ea8
iio: chemical: sgp30: Add description for sgp_read_cmd()'s 'duration_us'
...
Fixes the following W=1 kernel build warning(s):
drivers/iio/chemical/sgp30.c:236: warning: Function parameter or member 'duration_us' not described in 'sgp_read_cmd'
Signed-off-by: Lee Jones <lee.jones@linaro.org >
Cc: Andreas Brauchli <a.brauchli@elementarea.net >
Cc: Pascal Sachs <pascal.sachs@sensirion.com >
Link: https://lore.kernel.org/r/20200716135928.1456727-6-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 18:41:37 +01:00
Lee Jones
faeda91907
iio: gyro: adis16080: Fix formatting issue
...
Kerneldoc expects attributes/parameters to be in '@*.: ' format.
Fixes the following W=1 kernel build warning(s):
drivers/iio/gyro/adis16080.c:49: warning: Function parameter or member 'lock' not described in 'adis16080_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org >
Cc: Michael Hennerich <Michael.Hennerich@analog.com >
Cc: Barry Song <21cnbao@gmail.com >
Link: https://lore.kernel.org/r/20200716135928.1456727-13-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 18:41:37 +01:00
Lee Jones
ee21014b10
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'
Signed-off-by: Lee Jones <lee.jones@linaro.org >
Cc: Marc Zyngier <maz@kernel.org >
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com >
Link: https://lore.kernel.org/r/20200716135928.1456727-16-lee.jones@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 18:41:36 +01:00
Lee Jones
c5e6c649b4
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 >
2020-09-21 18:41:36 +01:00
Lee Jones
1536a8ee14
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 >
2020-09-21 18:41:36 +01:00
Lee Jones
6026292469
iio: dac: ad7303: Complete 'struct ad7303_state' doc
...
Fixes the following W=1 kernel build warning(s):
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 >
2020-09-21 18:41:36 +01:00
Sergiu Cuciurean
8a0f412fca
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.
This is part of a bigger cleanup.
Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com >
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com >
Link: https://lore.kernel.org/r/20200916092928.78026-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 18:41:35 +01:00
Ivan Drobyshevskyi
3cef2e31b5
iio: proximity: vl53l0x: Add IRQ support
...
VL53L0X can be configured to use interrupt pin (GPIO1)
to notify host about readiness of new measurement.
If interrupt pin is not specified, driver still uses polling.
Signed-off-by: Ivan Drobyshevskyi <drobyshevskyi@gmail.com >
Link: https://lore.kernel.org/r/20200916074458.873359-2-drobyshevskyi@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
2020-09-21 18:41:35 +01:00
Jonathan Cameron
322da39090
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-39-jic23@kernel.org
2020-09-21 18:41:35 +01:00
Jonathan Cameron
4231f9d166
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: David Barksdale <dbarksdale@uplogix.com >
Link: https://lore.kernel.org/r/20200910173242.621168-38-jic23@kernel.org
2020-09-21 18:41:34 +01:00
Jonathan Cameron
7f33a29a74
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com >
Link: https://lore.kernel.org/r/20200910173242.621168-37-jic23@kernel.org
2020-09-21 18:41:34 +01:00
Jonathan Cameron
2b4f0172ae
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Linus Walleij <linus.walleij@linaro.org >
Link: https://lore.kernel.org/r/20200910173242.621168-36-jic23@kernel.org
2020-09-21 18:41:34 +01:00
Jonathan Cameron
8e5a0426dd
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
2020-09-21 18:41:34 +01:00
Jonathan Cameron
03303e8425
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-34-jic23@kernel.org
2020-09-21 18:41:33 +01:00
Jonathan Cameron
00fa493b99
iio:proximity:as3935: Drop of_match_ptr and use generic fw accessors
...
This change allows the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-33-jic23@kernel.org
2020-09-21 18:41:33 +01:00
Jonathan Cameron
c457b7efa3
iio:proximity:as3935: Use local struct device pointer to simplify code.
...
This makes the existing code easier to read and will make the following
patch a little simpler.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-32-jic23@kernel.org
2020-09-21 18:41:33 +01:00
Jonathan Cameron
d136431430
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-31-jic23@kernel.org
2020-09-21 18:41:33 +01:00
Jonathan Cameron
b3fce99a57
iio:chemical:vz89x: Drop of_match_ptr protection and use generic fw accessors
...
This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
The handling of match_data uses a different approach as
device_get_match_data() doesn't distinguish between no match, and
a match but with NULL data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-30-jic23@kernel.org
2020-09-21 18:41:32 +01:00
Jonathan Cameron
e12b3a6150
iio:chemical:vz89x: Introduce local struct device pointer.
...
Avoids lots of repetition of &client->dev and will make the next
patch tidier.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-29-jic23@kernel.org
2020-09-21 18:41:32 +01:00
Jonathan Cameron
6ac282edd6
iio:chemical:sgp30: Drop of_match_ptr and use generic fw accessors
...
This change allow the driver to be used with ACPI PRP0001 and removes
an antipattern that I want to avoid being copied into new IIO drivers.
The handling of match_data uses a different approach as
device_get_match_data doesn't distinguish between no match, and
a match but with NULL data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com >
Link: https://lore.kernel.org/r/20200910173242.621168-28-jic23@kernel.org
2020-09-21 18:41:32 +01:00
Jonathan Cameron
cb26d23686
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Andreas Brauchli <andreas.brauchli@sensirion.com >
Link: https://lore.kernel.org/r/20200910173242.621168-27-jic23@kernel.org
2020-09-21 18:41:32 +01:00
Jonathan Cameron
a867e89867
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-26-jic23@kernel.org
2020-09-21 18:41:31 +01:00
Jonathan Cameron
4d36d4df68
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-25-jic23@kernel.org
2020-09-21 18:41:31 +01:00
Jonathan Cameron
184ac728db
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Link: https://lore.kernel.org/r/20200910173242.621168-24-jic23@kernel.org
2020-09-21 18:41:31 +01:00
Jonathan Cameron
b5c35aedf9
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Manivannan Sadhasivam <manivannanece23@gmail.com >
Link: https://lore.kernel.org/r/20200910173242.621168-23-jic23@kernel.org
2020-09-21 18:41:30 +01:00
Jonathan Cameron
c5b411bc9a
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com >
Link: https://lore.kernel.org/r/20200910173242.621168-22-jic23@kernel.org
2020-09-21 18:41:30 +01:00
Jonathan Cameron
a409d2b639
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Gregor Boirie <gregor.boirie@parrot.com >
Link: https://lore.kernel.org/r/20200910173242.621168-21-jic23@kernel.org
2020-09-21 18:41:30 +01:00
Jonathan Cameron
444f5f854b
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com >
Link: https://lore.kernel.org/r/20200910173242.621168-20-jic23@kernel.org
2020-09-21 18:41:30 +01:00
Jonathan Cameron
0e62470652
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Tomasz Duszynski <tduszyns@gmail.com >
Link: https://lore.kernel.org/r/20200910173242.621168-19-jic23@kernel.org
2020-09-21 18:41:29 +01:00
Jonathan Cameron
eb25d0aa4a
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com >
Link: https://lore.kernel.org/r/20200910173242.621168-18-jic23@kernel.org
2020-09-21 18:41:29 +01:00
Jonathan Cameron
4c55fb8c99
iio:potentiostat:lmp91000: Drop of_match_ptr and use generic fw accessors
...
This change allows use of this driver with ACPI via PRP0001 and removes
an example of an anti pattern I'm trying to remove from IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com >
Link: https://lore.kernel.org/r/20200910173242.621168-17-jic23@kernel.org
2020-09-21 18:41:29 +01:00
Jonathan Cameron
16723c6eaa
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk >
Link: https://lore.kernel.org/r/20200910173242.621168-16-jic23@kernel.org
2020-09-21 18:41:28 +01:00
Jonathan Cameron
40f84dd0e6
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Lukas Wunner <lukas@wunner.de >
Link: https://lore.kernel.org/r/20200910173242.621168-15-jic23@kernel.org
2020-09-21 18:41:28 +01:00
Jonathan Cameron
2de887b0cf
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.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com >
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com >
Cc: Peter Meerwald <pmeerw@pmeerw.net >
Link: https://lore.kernel.org/r/20200910173242.621168-14-jic23@kernel.org
2020-09-21 18:41:28 +01:00
Jonathan Cameron
34860a19a3
iio:dac:ad7303: Drop of_match_ptr protection
...
This prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Also add mod_devicetable.h include given struct of_device_id is
declared there.
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-13-jic23@kernel.org
2020-09-21 18:41:28 +01:00
Jonathan Cameron
fe506cc5af
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
2020-09-21 18:41:27 +01:00
Jonathan Cameron
23636b479a
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
2020-09-21 18:41:27 +01:00