iio: buffer-dmaengine: Report buffer length requirements

The dmaengine buffer has some length alignment requirements that can differ
from platform to platform. If the length alignment requirements are not met
unexpected behavior like dropping of samples can occur.

Currently these requirements are not reported and applications need to know
the requirements of the platform by some out-of-band means.

Add a new buffer attribute that reports the length alignment requirements
called `length_align_bytes`. The reported length alignment is in bytes that
means the buffer length alignment in sample sets depends on the number of
enabled channels and the bytes per channel. Applications using this
attribute to determine the buffer size requirements need to consider this.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

bindings: iio: pressure: Add documentation for dlh driver

Add a device tree binding documentation for DLH series pressure
sensors.

Signed-off-by: Tomislav Denis <tomislav.denis@avl.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: Add asc vendor

All Sensors Corporation is a manufacturer of MEMS piezoresitive
ultra low pressure sensors and pressure transducers.

Signed-off-by: Tomislav Denis <tomislav.denis@avl.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: pressure: Add driver for DLH pressure sensors

All Sensors DLH is series of low voltage digital pressure sensors.
Additionally to pressure value sensors deliver a temperature value.
Sensors can be accessed over I2C and SPI, this driver supports
only I2C access.

Signed-off-by: Tomislav Denis <tomislav.denis@avl.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer-dmaengine: Add module information

Make sure that the industrialio-buffer-dmaengine has proper license
information so it can be build as a module and loaded without tainting the
kernel.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: bma180: Use explicit member assignment

This uses the C99 explicit .member assignment for the
variant data in struct bma180_part_info. This makes it
easier to understand and add new variants.

Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: bma180: Basic regulator support

This brings up the VDD and VDDIO regulators using the
regulator framework. Platforms that do not use regulators
will provide stubs or dummy regulators.

Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: bma180: Add dev helper variable

Having a shorthand "dev" instead of &client->dev everywhere
makes the code easier to read (more compact).

Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: enable sensor-hub support for lsm6dsm

Enabled i2c master controller support for LSM6DSM sensor. Enable
ext_sensor0 for lsm6dsm. This series has been tested using LIS2MDL as
slave device connected to the i2c controller of the LSM6DSM

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: rename st_lsm6dsx_shub_read_reg in st_lsm6dsx_shub_read_output

Rename st_lsm6dsx_shub_read_reg routine in st_lsm6dsx_shub_read_output
since it is used to read from sensorhub channel0 output register

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: check if shub_output reg is located in primary page

Check if the sensor hub output register is located in the primary or in the
secondary memory page. This is a preliminary patch to support i2c master
controller on lsm6dsm devices

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: check if pull_up is located in primary page

Check if the pull up register is located in the primary or in the
secondary memory page. This is a preliminary patch to support i2c master
controller on lsm6dsm devices

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: check if master_enable is located in primary page

Check if the master enable register is located in the primary or in the
secondary memory page. This is a preliminary patch to support i2c master
controller on lsm6dsm devices

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: export max num of slave devices in st_lsm6dsx_shub_settings

Export max number of slave devices supported by the i2c master
controller in st_lsm6dsx_shub_settings data structure.
This is a preliminary patch to support i2c master controller
on lsm6dsm sensors

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: remove unneeded semicolon

Fixes coccicheck warning:

./drivers/iio/light/lm3533-als.c:745:2-3: Unneeded semicolon

Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: chemical: atlas-ph-sensor: rename atlas-ph-sensor to atlas-sensor

Since the orginal scope of the driver was to only support
the pH product from Atlas it has evolved to other sensors.

Rename the file, driver name, and regmap to atlas-sensor which
reflects this, although keep CONFIG_ATLAS_PH_SENSOR to not cause
regressions with current configurations.

Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: st_sensors: Describe function parameters in kernel-doc

Kernel documentation script complains that some of the function parameters
are not described:

.../common/st_sensors/st_sensors_trigger.c:29: warning: Function parameter or member 'indio_dev' not described in 'st_sensors_new_samples_available'
.../common/st_sensors/st_sensors_trigger.c:29: warning: Function parameter or member 'sdata' not described in 'st_sensors_new_samples_available'

Describe function parameters where it's appropriate.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: pressure: st_press: Mark default_press_pdata with __maybe_unused

Since we put static variable to a header file it's copied to each module
that includes the header. But not all of them are actually used it.

Mark default_press_pdata with __maybe_unused to calm a compiler down:

In file included from drivers/iio/pressure/st_pressure_spi.c:18:
drivers/iio/pressure/st_pressure.h:40:46: warning: ‘default_press_pdata’ defined but not used [-Wunused-const-variable=]
   40 | static const struct st_sensors_platform_data default_press_pdata = {
      |                                              ^~~~~~~~~~~~~~~~~~~
...

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: st_accel: Mark default_accel_pdata with __maybe_unused

Since we put static variable to a header file it's copied to each module
that includes the header. But not all of them are actually used it.

Mark default_accel_pdata with __maybe_unused to calm a compiler down:

In file included from drivers/iio/accel/st_accel_i2c.c:19:
drivers/iio/accel/st_accel.h:67:46: warning: ‘default_accel_pdata’ defined but not used [-Wunused-const-variable=]
   67 | static const struct st_sensors_platform_data default_accel_pdata = {
      |                                              ^~~~~~~~~~~~~~~~~~~
...

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: gyro: st_gyro: Mark gyro_pdata with __maybe_unused

Since we put static variable to a header file it's copied to each module
that includes the header. But not all of them are actually used it.

Mark gyro_pdata with __maybe_unused to calm a compiler down:

In file included from drivers/iio/gyro/st_gyro_i2c.c:18:
drivers/iio/gyro/st_gyro.h:31:46: warning: ‘gyro_pdata’ defined but not used [-Wunused-const-variable=]
   31 | static const struct st_sensors_platform_data gyro_pdata = {
      |                                              ^~~~~~~~~~
...

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: pressure: st_press: Drop unnecessary #else branch for ACPI

ACPI_PTR() takes care of the argument in case of !CONFIG_ACPI.
Remove unnecessary #else branch.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: st_accel: Drop unnecessary #else branch for ACPI

ACPI_PTR() takes care of the argument in case of !CONFIG_ACPI.
Remove unnecessary #else branch.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: st_uvis25: Drop unneeded header inclusion

There is no evidence that the driver supports or needs ACPI APIs.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: st_lsm6dsx: Make use of device properties

Device property API allows to gather device resources from different sources,
such as ACPI. Convert the drivers to unleash the power of device property API.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: st_lsm6dsx: Drop unneeded OF code

There is no need to have OF guard against ID table.
Drop it for good.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: st_lsm6dsx: Mark predefined constants with __maybe_unused

Since we put static variable to a header file it's copied to each module
that includes the header. But not all of them are actually used it.

Mark predefined constants with __maybe_unused to calm a compiler down:

In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c:17:
.../st_lsm6dsx/st_lsm6dsx.h:399:28: warning: ‘st_lsm6dsx_available_scan_masks’ defined but not used [-Wunused-const-variable=]
  399 | static const unsigned long st_lsm6dsx_available_scan_masks[] = {0x7, 0x0};
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../st_lsm6dsx/st_lsm6dsx.h:392:36: warning: ‘st_lsm6dsx_event’ defined but not used [-Wunused-const-variable=]
  392 | static const struct iio_event_spec st_lsm6dsx_event = {
      |                                    ^~~~~~~~~~~~~~~~
...

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928

The ad7928 is software compatible with the ad7923.
The ad7908 and ad7918 are the 8 and 10-bit versions of the ad7928.

Signed-off-by: Daniel Junho <djunho@gmail.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7923: Add of_device_id table

Accomplish device tree compatibility to driver AD7923
by adding of_device_id table and making a subsequent call to
MODULE_DEVICE_TABLE.

Signed-off-by: Daniel Junho <djunho@gmail.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7923: Fix checkpatch warning

Fix checkpatch warning:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
+static int ad7923_scan_direct(struct ad7923_state *st, unsigned ch)

Signed-off-by: Daniel Junho <djunho@gmail.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7923: Remove the unused defines

Removes the unused define AD7923_CHANNEL_x from the code.

Signed-off-by: Daniel Junho <djunho@gmail.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: bma400: basic regulator support

Add support for the VDD and VDDIO regulators using the regulator
framework.

Signed-off-by: Dan Robertson <dan@dlrobertson.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: Add driver for the BMA400

Add a IIO driver for the Bosch BMA400 3-axes ultra-low power accelerometer.
The driver supports reading from the acceleration and temperature
registers. The driver also supports reading and configuring the output data
rate, oversampling ratio, and scale.

Signed-off-by: Dan Robertson <dan@dlrobertson.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: accel: bma400: add bindings

Add devicetree binding for the Bosch BMA400 3-axes ultra-low power
accelerometer sensor.

Signed-off-by: Dan Robertson <dan@dlrobertson.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: accel: add binding documentation for ADIS16240

This patch add device tree binding documentation for ADIS16240.

Signed-off-by: Rodrigo Carvalho <rodrigorsdc@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

staging: iio: accel: adis16240: enforce SPI mode on probe function

According to the datasheet, this driver supports only SPI mode 3,
so we should enforce it on probe function.

Signed-off-by: Rodrigo Carvalho <rodrigorsdc@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: new driver to support Linear technology's ltc2496

This chip is similar to the LTC2497 ADC, it just uses SPI instead of I2C
and so has a slightly different protocol. Only the actual hardware
access is different. The spi protocol is different enough to not be able
to map the differences via a regmap.

Also generalize the entry in MAINTAINER to cover the newly introduced
file.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ltc2497: split protocol independent part in a separate module

This allows to share most of this driver for the ltc2496 driver added in
the next commit that is an SPI variant of the ltc2497. Initially I named
the generic part ltc249x, but wild card names are frowned upon, so the
generic part is called ltc2497-core even though it's not obvious that
this is then to be reused for the ltc2496 driver.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ltc2496: provide device tree binding document

The ADC only requires the standard stuff for spi devices and a reference
voltage.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ti-ads1015: Make use of device property API

Make use of device property API in this driver so that both OF based
system and ACPI based system can use this driver.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ti-ads1015: Get rid of legacy platform data

Platform data is a legacy interface to supply device properties
to the driver. In this case we even don't have in-kernel users
for it. Just remove it for good.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ti-ads7950: Fix a typo in an error message

Fix a typo:
   s/get get/to get/

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: humidity: hts221: move register definitions to sensor structs

Move some register definitions to hts221_avg_list, hts221_avg_list and
hts221_channels since they are used only there and simplify driver code

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: stm32-adc: Add check on overrun interrupt

Enable overrun interrupt on STM32 ADC. In case data register hasn't been
read (by CPU or DMA), overrun condition is detected when there's new
conversion data available. Stop grabbing data and log an error message.
Use a threaded irq to avoid printing the error message from hard irq
context.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ssp_sensors: Convert to use GPIO descriptors

These three GPIO lines used by the Samsung sensor hub is pretty
straight-forward to convert to use GPIO descriptors.

Cc: Karol Wrona <k.wrona@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Move AD7091R5 entry in a alphabetical order in Makefile

Ad7091R5 was added in a non alphabetical order after AD7124 in Makefile and
KConfig. This patch fixes that and place Ad7091R5 before AD7124.

Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: atlas-ph-sensor: Drop GPIO include

The driver includes <linux/gpio.h> yet fails to use symbols
from any the header so drop the include.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ad7266: Convert to use GPIO descriptors

The AD7266 have no in-tree users making use of the platform
data mechanism to pass address GPIO lines when not using
a fixed address, so we can easily convert this to use
GPIO descriptors instead of the platform data integers
currently passed.

Lowercase the labels "ad0".."ad2" as this will make a better
fit for platform descriptions like device tree that prefer
lowercase names such as "ad0-gpios" rather than "AD0-gpios".

Board files and other static users of this device can pass
the same GPIO descriptors using machine descriptor
tables if need be.

Cc: Alison Schofield <amsfield22@gmail.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ad5592r: Drop surplus GPIO header

This driver uses all the modern GPIO APIs from
<linux/gpio/driver.h> and <linux/gpio/consumer.h> so
just drop the unused legacy header <linux/gpio.h>.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adf4350: Convert to use GPIO descriptor

The lock detect GPIO line is better to grab using
a GPIO descriptor. We drop the pdata for this: clients using board
files can use machine descriptor tables to pass this GPIO from
static data.

Cc: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: itg3200: Drop GPIO include

The driver include <linux/gpio.h> yet does not use any
of the symbols from the header, so drop the include.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: apds9960: Drop GPIO includes

The driver includes <linux/gpio.h> and <linux/of_gpio.h> yet
fails to use symbols from any of the include files, so drop
these includes.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ad2s1200: Drop legacy include

This driver is using the GPIO descriptor API but yet includes
the legacy <linux/gpio.h> header for no reason. Drop the
surplus include.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: si1145: Drop GPIO include

The driver include <linux/gpio.h> yet does not use any
of the symbols from the header, so drop the include.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: as3935: Drop GPIO includes

The driver includes <linux/gpio.h> and <linux/of_gpio.h> yet
fails to use symbols from any of the include files, so drop
these includes.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: st_lsm6dsx: fix checkpatch warning

Fix following checkpatch warning:

CHECK: Alignment should match open parenthesis
+static int st_lsm6dsx_read_event(struct iio_dev *iio_dev,
+                                  const struct iio_chan_spec *chan,

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ak8975: Convert to use GPIO descriptor

The end-of-conversion (EOC) GPIO line is better to grab using
a GPIO descriptor. We drop the pdata for this: clients using board
files can use machine descriptor tables to pass this GPIO from
static data.

Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad799x: add pm_ops to disable the device completely

The device is always in a low-power state due to the hardware design. It
wakes up upon a conversion request and goes back into the low-power
state. The pm ops are added to disable the device completely and to free
the regulator. Disbaling the device completely should be not that
notable but freeing the regulator is important. Because if it is a shared
power-rail the regulator won't be disabled during suspend-to-ram/disk
and so all devices connected to that rail keeps on.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_mpu6050: Select I2C_MUX again

commit f7072198f217 ("iio: imu: Fix inv_mpu6050 dependencies")
undid the explicit selection of I2C_MUX previously
done by the driver, because I2C_MUX implicitly depended
on HAS_IOMEM.

However commit 93d710a65ef0 ("i2c: mux: fix up dependencies")
cleared up the situation properly and drivers that need
to select I2C_MUX can now do so again.

It makes a lot of sense for a driver to select the driver
infrastructure it needs so restore the natural order of
things.

Cc: Richard Weinberger <richard@nod.at>
Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7887: Cleanup channel assignment

The channels specification assignment in chip info was simplified.
This patch makes supporting other devices by this driver easier.

Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ping: add parallax ping sensors

Add support for parallax ping and laser ping sensors with just one pin
for trigger and echo signal.

This driver is based on srf04. In contrast to it it's necessary to
change direction of the pin and to request the irq just for the period
when the echo is rising and falling. Because this adds a lot of cases
there is this individual driver for handling this type of sensors.

Add a new configuration variable CONFIG_PING to Kconfig and Makefile.

Julia reported an issue with failing to unlock a mutex in some error
paths.

Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: trigger: stm32-timer: remove unnecessary update event

There is no need to explicitly generate update event to update
timer master mode.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: Fix Kconfig indentation

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^        /\t/' -i */Kconfig

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

MAINTAINERS: add maintainer for ping iio sensors

Add a maintainer for the new parallax PING))) and LaserPING IIO sensors

Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: add parallax ping sensors

Add dt-bindings for parallax PING))) and LaserPING iio sensors, which
are used for measuring distances.

Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: add vendor prefix parallax

Add new vendor prefix parallax for newly created ping iio sensors.

Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: dac: ad7303: use regulator get optional to check for ext supply

Previously, the code was using the of_read_property_bool() to check if
an external regulator was provided. However, this is redundant, as it's
more simple/direct to just ask the regulator is provided, via a
`devm_regulator_get_optional()` call.

Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: maxim_thermocouple: document new 'compatible' strings

Now the maxim_thermocouple has new, more specific, 'compatible' strings for
better distinguish the various supported chips.

This patch updates the DT bindings documentation accordingly

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: maxim_thermocouple: add thermocouple_type sysfs attribute

We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.

This driver supports actually several chips:
 - max6675
 - max31855[k/j/n/s/t/e/r]asa family

Max6675 supports only K-type thermocouples, so we can just report that.

Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).

This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.

The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.

Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).

RFT because I have no real HW to test this.

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: max31856: add support for runtime-configuring the thermocouple type

The sensor support various thermocouple types (e.g. J, K, N, ...). The
driver allows to configure this parameter using a DT property.

This is useful when i.e. the thermocouple is physically tied to the sensor
and it is usually not removed, or when it is at least known in advance
which sensor will be connected to the circuit.

However, if the user can randomly connect any kind of thermocouples (i.e.
the device exposes a connector, and the user is free to connect its own
sensors), it would be more appropriate to provide a mechanism to
dynamically switch from one thermocouple type to another. This can be i.e.
handled in userspace by a GUI, a configuration file or a program that
detects the thermocouple type by reading a GPIO, or a eeprom on the probe,
or whatever.

This patch adds a IIO attribute that can be used to override, at run-time,
the DT-provided setting (which serves as default).

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Documentation: ABI: document IIO thermocouple_type file

IIO core layer gained a new sysfs standard attribute "thermocouple_type".
This patch adds it to the list of documented ABI for sysfs-bus-iio

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: add thermocouple_type standard attribute

We have a couple of thermocouple IIO drivers, supporting several chips.
Some of them support only one specific thermocouple type (e.g. "K", "J"),
one of them can be configured to work with several different thermocouple
types.

In certain applications thermocouples could be externally connected to the
chip by the user.

This patch introduces a new IIO standard attribute to report the supported
thermocouple type and, where applicable, to allow it to be dynamically set
using sysfs.

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: add char type for sysfs attributes

This patch introduces IIO_VAL_CHAR type for standard IIO attributes to
allow for attributes that needs to be represented by character rather
than a number. This is preparatory for introducing a new attribute whose
purpose is to describe thermocouple type, that can be i.e. "J", "K", etc..

The char-type value is stored in the first "value" integer that is passed
to the .[read/write]_raw() callbacks.

Note that in order to make it possible for the IIO core to correctly parse
this type (actually, to avoid integer parsing), it became mandatory for
any driver that wish to use IIO_VAL_CHAR on a writable attribute to
implement .write_raw_get_fmt().

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: max31856: add support for configuring the HW averaging

This sensor can perform samples averaging in hardware, but currently the
driver leaves this setting alone (default is no averaging).

This patch binds this HW setting to the "oversampling_ratio" IIO attribute
and allows the user to set the averaging as desired (the HW supports
averaging of 2, 5, 8 or 16 samples; in-between values are rounded up).

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Documentation: ABI: document IIO in_temp_filter_notch_center_frequency file

max31856 IIO driver introduced a new attribute
"in_temp_filter_notch_center_frequency".
This patch adds it to the list of documented ABI for sysfs-bus-iio

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: max31856: add option for setting mains filter rejection frequency

This sensor has an embedded notch filter for reducing interferences caused
by the power mains. This filter can be tuned to reject either 50Hz or 60Hz
(and harmonics).

Currently the said setting is left alone (the sensor defaults to 60Hz).
This patch introduces a IIO attribute that allows the user to set the said
filter to the desired frequency.

NOTE: this has been intentionally not tied to any DT property to allow
the configuration of this setting from userspace, e.g. with a GUI or by
reading a configuration file, or maybe reading a GPIO tied to a physical
switch or accessing some device that can autodetect the line frequency.

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: gyro: adis16260: replace mlock with ADIS lib's state_lock

This change uses the ADIS library's state_lock to protect the state of the
`max_speed_hz` change that is done during the set of the sampling
frequency.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis16480: use state lock for filter freq set

It's the only operation that does 2 operations (a read & a write), so the
unlocked functions can be used under a single state lock.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: gyro: adis16136: rework locks using ADIS library's state lock

This replaces indio_dev's mlock with the state lock/mutex from the ADIS
library.

The __adis16136_get_freq() function has been prefixed to mark it as
unlocked. The adis16136_{set,get}_filter() functions now hold the state
lock for all the ops that they do.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis16400: rework locks using ADIS library's state lock

This change removes the use of indio_dev's mlock in favor using the state
lock from the ADIS library.

The set_freq() & get_freq() hooks are unlocked, so they require specific
locking. That is because in some cases the get_freq() hook is used in
combination with adis16400_set_filter().

In cases where only one read/write is done, the functions that hold the
state lock are used.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis: group single conversion under a single state lock

The single conversion function does a series of reads + writes. This change
extends the use of the state_lock for the entire set of operations.
Previously, indio_dev's mlock was used. This change also removes the use of
this lock.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis: protect initial startup routine with state lock

The initial startup routine is called by some ADIS drivers during probe,
and before registering with IIO. Normally, userspace should not be able to
do any access to the device (as there shouldn't be any available).

This change extends the state lock to the entire initial-startup routine.
Behaviourally nothing should change, but this should make the library
function a bit more robust.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis: create an unlocked version of adis_reset()

The reset routine may also be important to be protected by the state-lock
and grouped with other operations, so create an unlocked version, so that
this can be done.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis: create an unlocked version of adis_check_status()

This one also gets re-used in certain operations, so it makes sense to
have an unlocked version of this to group it with other
reads/writes/operations to have a single lock for the whole state change.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis[16480]: group RW into a single lock in adis_enable_irq()

The adis_enable_irq() does a read & a write. This change keeps a lock for
the duration of both operations vs for each op.

The change is also needed in adis16480, since that has it's own
implementation for adis_enable_irq().

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis: add unlocked read/write function versions

This will allow more flexible control to group reads & writes into a single
lock (particularly the state_lock).

The end-goal is to remove the indio_dev->mlock usage, and the simplest fix
would have been to just add another lock, which would not be a good idea on
the long-run.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: adis: rename txrx_lock -> state_lock

The lock can be extended a bit to protect other elements that are not
particular to just TX/RX. Another idea would have been to just add a new
`state_lock`, but that would mean 2 locks which would be redundant, and
probably cause more potential for dead-locks.

What will be done in the next patches, will be to add some unlocked
versions for read/write_reg functions.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: max9611: Make enum relations more future proof

The relations between enum values and array indices values are currently
not enforced by the code, which makes them fragile w.r.t. future
changes.

Fix this by:
  1. Using designated array initializers, to make sure array indices and
     enums values match,
  2. Linking max9611_csa_gain enum values to the corresponding
     max9611_conf_ids enum values, as the latter is cast to the former
     in max9611_read_csa_voltage().

No change in generated code.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_mpu6050: add support of MPU9150 magnetometer

Add support for driving MPU9150 magnetometer (AK8975) from mpu.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: imu: inv_mpu6050: delete not existing MPU9150 spi support

MPU9150 is i2c only.
Update Kconfig to delete in description chips that are i2c or
spi only.

Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

MAINTAINERS: add entry for AD7091R5 driver

Add Beniamin Bia as a maintainer for AD7091R5 ADC.

Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-binding: iio: Add documentation for AD7091R5

Documentation for AD7091R5 ADC was added.

Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7091r5: Add scale and external VREF support

The scale can now be obtained with the "in_voltage_scale" file.
By default, the scale returned corresponds to the internal VREF of 2.5V.

It is possible to use an external VREF (through the REFIN/REFOUT pin of
the chip), by passing a regulator to the driver. The scale will then be
calculated according to the voltage reported by the regulator.

Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Co-developed-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: Add support for AD7091R5 ADC

AD7091R5 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.

This driver will also support AD7091R2/4/8 in the future.

Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Co-developed-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer-dmaengine: Use dma_request_chan() directly for channel request

dma_request_slave_channel_reason() is:
dma_request_chan(dev, name)

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

staging: vchiq: Refactor indentation in vchiq_platform_conn_state_changed()

Reducing the indentation level helps a bit with
the readability of this function. There's also a checkpatch
fix here, moving the first argument to kthread_create() onto
the same line, as well as a relocation of the statement
"char threadname[16];" to the top of the function to avoid
a declaration in the middle of code.

Signed-off-by: Marcelo Diop-Gonzalez <marcgonzalez@google.com>
Link: https://lore.kernel.org/r/20191114232801.71458-1-marcgonzalez@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: exfat: fix spelling mistake "maont" -> "mount"

There is a spelling mistake in a kernel info message. Fix it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191114221509.10728-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: exfat: remove two unused functions

Fix sparse warnings:

drivers/staging/exfat/exfat_core.c:2045:4: warning: symbol 'calc_checksum_1byte' was not declared. Should it be static?
drivers/staging/exfat/exfat_core.c:2080:5: warning: symbol 'calc_checksum_4byte' was not declared. Should it be static?

The two functions has no caller in tree, so remove it.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191114140348.46088-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: rtl8723bs: fix indentation issue

There is a block of statements that are indented
too deeply, remove the extraneous tabs.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191114095747.132407-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: rtl8192u: fix indentation issue

There is a block of statements that are indented
too deeply, remove the extraneous tabs.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191114095430.132120-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: ralink: enable PCI support only if driver for mt7621 SoC is selected

Some versions of SoC MT7621 have three PCI express hosts. Some boards
make use of those PCI through the staging driver mt7621-pci. Recently
PCI support has been removed from MT7621 Soc kernel configuration due
to a build error. This makes imposible to compile staging driver and
produces a regression for gnubee based boards. Enable support for PCI
again but enable it only if staging mt7621-pci driver is selected.

Fixes: c4d48cf5e2f0 ("MIPS: ralink: deactivate PCI support for SOC_MT7621")
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: ralf@linux-mips.org
Cc: jhogan@kernel.org
Cc: john@phrozen.org
Cc: NeilBrown <neil@brown.name>
Cc: linux-mips@vger.kernel.org
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20191019081233.7337-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>