Add devicetree binding for the NXP FXLS8962AF/FXLS8964AF
accelerometer sensor.
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
With CONFIG_ACPI=n and -Werror, 0-day reports:
drivers/iio/chemical/bme680_i2c.c:46:36: error:
'bme680_acpi_match' defined but not used
Apparently BME0680 is not a valid ACPI ID. Remove the ID.
Note the driver will still work with ACPI bindings that use the PRP0001
mechanism as that uses the of_device_id table instead.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
BME0680 is not an official ACPI ID, so let's remove it before someone
starts using it.
Note that ACPI can still be used with this driver via the PRP0001 method
which will use the of_device_id table to match.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
With CONFIG_ACPI=n, W=1 and -Werror, 0-day reports:
drivers/iio/accel/stk8312.c:644:36: error:
'stk8312_acpi_id' defined but not used
Apparently STK8312 is not a valid ACPI ID. Remove the ID table
as this is the only entry. If ACPI support is desired an explicit
of_device_id table should be added (rather than relying on the fallback
to the existing ID table).
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
With CONFIG_ACPI=n and -Werror, 0-day reports:
drivers/iio/humidity/am2315.c:259:36: error:
'am2315_acpi_id' defined but not used
According to Andy Shevchenko, the ACPI ID used in this driver is fake
and does not really exist. Remove it and with it ACPI support from
the driver.
Note that, if an explicit of_device_id table is added to the driver
it could support the PRP0001 based ACPI approach.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
indio_dev was both the macro input parameter and the field name
in this macro. That causes trouble if the instance of
struct iio_dev passed in is not called indio_dev.
Whilst a fix of sorts, no need to backport as it seems we never
hit this previously due to some very consistent naming in IIO.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426174911.397061-3-jic23@kernel.org
Continuing from Alexandru Ardelean's introduction of the split between
driver modifiable fields and those that should only be set by the core.
This could have been done in two steps to make the actual move after
introducing iio_device_id() but there seemed limited point to that
given how mechanical the majority of the patch is.
Includes fixup from Alex for missing mxs-lradc-adc conversion.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426174911.397061-2-jic23@kernel.org
Basically the TI TSC2046 touchscreen controller is 8 channel ADC optimized for
the touchscreen use case. By implementing it as an IIO ADC device, we can
make use of resistive-adc-touch and iio-hwmon drivers.
Polled readings are currently not implemented to keep this patch small, so
iio-hwmon will not work out of the box for now.
So far, this driver was tested with a custom version of resistive-adc-touch driver,
since it needs to be extended to make use of Z1 and Z2 channels. The X/Y
are working without additional changes.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210428073208.19570-4-o.rempel@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Commit 63cd35f34d ("iio: Documentation: update definitions for bufferY and scan_elements")
updated iio documentation in order to point to the newly
per-buffer API, as it is now possible to support multi buffers.
While the previous ABI will be kept forever, the best is
for applications to use the 5.11+ ABI. So, move the
legacy one ABI/obsolete.
This fixes an issue with scripts/get_abi.pl, that doesn't
accept two different Kernel version support for the same
API set.
Fixes: 63cd35f34d ("iio: Documentation: update definitions for bufferY and scan_elements")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/a2c802049adee6a5710a58082cfdc1132c5e4c11.1619532170.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
sps30 has gained support for serial communication so add example to the
binding file. While at it remove reg property from list of required
properties because it's no-op in case of serial communication.
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sensor has support for both i2c and serial communication interfaces.
Both offer very similar set of features. Minor differences don't impact
overall functionality like doing measurements, etc.
Support for i2c have already been added, this patch adds support
for the latter ie. serial interface.
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Move code responsible for handling i2c communication to a separate file.
Rationale for this change is preparation for adding support for serial
communication.
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The adf4371 has channels that are very closely coupled, so additional
documentation is needed to express these constraints.
Unfortunately having the same sysfs filename in multiple documentation
does not work well when generating automated documentation.
To avoid this issue, we add a new device specific description to the
main docs and remove the one in the device specific file.
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:0 ./Documentation/ABI/testing/sysfs-bus-iio:599
Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-8-jic23@kernel.org
This one is challenging as both the places this appears in specific drivers
are making 'unusual' uses of what looks like a simple output current
channel.
As a side note, this was particular bit of ABI occurs in other drivers
where the use is much more straight forward e.g. dac/ad5421
This patch attempts to make a best effort of adding it to the main docs but
retaining enough information. Both of these drivers probably need
specific documents being written to describe their unusual interfaces, but
those should be in the main documentation, not under Documentation/ABI.
That is a non trivial job so left for another time.
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als:43 ./Documentation/ABI/testing/sysfs-bus-iio-health-afe440x:38
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-5-jic23@kernel.org
The interface is standard and the extra info provided on exactly what is
being powered down is not of interest to most users. Hence this doesn't
need it's own documentation and can rely on the docs in sysfs-bus-iio
Fixes
$ scripts/get_abi.pl validate
Warning: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371:36 ./Documentation/ABI/testing/sysfs-bus-iio:588
Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-4-jic23@kernel.org
This device has the unusual characteristic that the calibbias values
have well defined units (more commonly they are tweaks to a DAC)
Unfortunately the previous approach of having more specific documentation
in sysfs-bus-iio-icm42600 results in warnings during the documentation
build and random ordering in the resulting documentation.
To avoid this, add a note to the main documentation on this special
characteristic for the icm42600. The _available for calibbias was
missing from the main sysfs-bus-iio docs so also add that, allowing
us to drop the icm42600 specific file.
Fixes
$ scripts/get_abi.pl validate warning:
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:0 ./Documentation/ABI/testing/sysfs-bus-iio:394
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:1 ./Documentation/ABI/testing/sysfs-bus-iio:395
Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:2 ./Documentation/ABI/testing/sysfs-bus-iio:396
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:3 ./Documentation/ABI/testing/sysfs-bus-iio:397
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:4 ./Documentation/ABI/testing/sysfs-bus-iio:398
Warning: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias is defined 2 times: ./Documentation/ABI/testing/sysfs-bus-iio-icm42600:5 ./Documentation/ABI/testing/sysfs-bus-iio:399
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210117153816.696693-2-jic23@kernel.org
With commit 3ba10e37371d ("iio: adis: add burst_max_speed_hz variable"), we
just need to define 'burst_max_speed_hz' and the adis core will take
care of setting up the spi transfers for burst mode. Hence, we fix
a potential race with the spi core where we could be left witn an
invalid 'max_speed_hz'.
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Fixes: 5eda3550a3 ("staging:iio:adis16400: Preallocate transfer message")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-7-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
With commit 3ba10e37371d ("iio: adis: add burst_max_speed_hz variable"), we
just need to define 'burst_max_speed_hz' and the adis core will take
care of setting up the spi transfers for burst mode. Hence, we fix
a potential race with the spi core where we could be left with an
invalid 'max_speed_hz'.
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Fixes: fff7352bf7 ("iio: imu: Add support for adis16475")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-6-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On an IRQ handler we should not return normal error codes as 'irqreturn_t'
is expected.
This is done by jumping to the 'check_burst32' label where we return
'IRQ_HANDLED'. Note that it is fine to do the burst32 check in this
error path. If we have proper settings to apply burst32, we might just
do the setup now so that the next sample already uses it.
Fixes: fff7352bf7 ("iio: imu: Add support for adis16475")
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210427085454.30616-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
