BMC156 is very smilar to BMC150, but it has only one accelerometer
interrupt pin. It would make sense if only INT1 was exposed but someone
at Bosch decided to only have an INT2 pin.

In this case, it does not make sense if the first interrupt pin is
treated as INT1 (since that pin does not exist). Add a note to the
bindings that the first interrupt pin is treated as INT2 for BMC156.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210802155657.102766-3-stephan@gerhold.netSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The binding already allows specifying both interrupt pins, but there
is currently no way to describe a board where (for whatever reason)
only INT2 is connected. Make it possible to use "interrupt-names"
to make it explicit which interrupt pin is meant in the interrupts.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210802155657.102766-2-stephan@gerhold.netSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add an of_device_id table to explicitly support the Capella cm3323
Ambient Light Sensor rather than relying on matching against the
i2c_device_id table.
Signed-off-by: NSiddharth Manthan <siddharth.manthan@gmail.com>
Link: https://lore.kernel.org/r/20210728110048.14593-2-siddharth.manthan@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Update trivial-devices.yaml with Capella cm3323 Ambient Light Sensor
description.
Signed-off-by: NSiddharth Manthan <siddharth.manthan@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210728110048.14593-1-siddharth.manthan@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

sgp40 is a gas sensor used for measuring the air quality.

This driver is reading the raw resistance value which can be passed to
an userspace algorithm for further calculation.

The raw value is also used to calculate an estimated absolute voc index
in the range from 0 to 500. For this purpose the raw_mean value of the
resistance for which the index value is 250 might be set up as a
calibration step. This can be done with in_resistance_calibbias.

Compensation of relative humidity and temperature is supported and can
be used by writing to output values of out_humidityrelative_raw and
out_temp_raw.

There is a predecesor sensor type (sgp30) already existing. This driver
module was not extended because the new sensor is quite different in its
i2c telegrams.
Signed-off-by: NAndreas Klinger <ak@it-klinger.de>
Reported-by: Nkernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20210804154641.GA3237@arbadSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add devicetree binding for Sensirion sgp40 gas sensor to trivial
devices.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndreas Klinger <ak@it-klinger.de>
Link: https://lore.kernel.org/r/20210804154549.GA3223@arbadSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Use clk_prepare_enable()/clk_disable_unprepare() in preparation for switch
to Common Clock Framework, otherwise the following is visible:

WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:1011 clk_core_enable+0x9c/0xbc
Enabling unprepared ep93xx-adc
CPU: 0 PID: 1 Comm: swapper Not tainted 5.13.0-rc5-... #1
Hardware name: Cirrus Logic EDB9302 Evaluation Board
[<c000d5b0>] (unwind_backtrace) from [<c000c590>] (show_stack+0x10/0x18)
[<c000c590>] (show_stack) from [<c03a5f38>] (dump_stack+0x20/0x2c)
[<c03a5f38>] (dump_stack) from [<c03a2098>] (__warn+0x98/0xc0)
[<c03a2098>] (__warn) from [<c03a2150>] (warn_slowpath_fmt+0x90/0xc0)
[<c03a2150>] (warn_slowpath_fmt) from [<c01d8358>] (clk_core_enable+0x9c/0xbc)
[<c01d8358>] (clk_core_enable) from [<c01d8698>] (clk_core_enable_lock+0x18/0x30)
[<c01d8698>] (clk_core_enable_lock) from [<c0266560>] (ep93xx_adc_probe+0xe4/0x1a0)
[<c0266560>] (ep93xx_adc_probe) from [<c02126e0>] (platform_probe+0x34/0x80)
[<c02126e0>] (platform_probe) from [<c0210bf8>] (really_probe+0xe8/0x394)
[<c0210bf8>] (really_probe) from [<c0211464>] (device_driver_attach+0x5c/0x64)
[<c0211464>] (device_driver_attach) from [<c02114e8>] (__driver_attach+0x7c/0xec)
[<c02114e8>] (__driver_attach) from [<c020f1b4>] (bus_for_each_dev+0x78/0xc4)
[<c020f1b4>] (bus_for_each_dev) from [<c0211570>] (driver_attach+0x18/0x24)
[<c0211570>] (driver_attach) from [<c020fab4>] (bus_add_driver+0x140/0x1cc)
[<c020fab4>] (bus_add_driver) from [<c0211c44>] (driver_register+0x74/0x114)
[<c0211c44>] (driver_register) from [<c02134f8>] (__platform_driver_register+0x18/0x24)
[<c02134f8>] (__platform_driver_register) from [<c0470148>] (ep93xx_adc_driver_init+0x10/0x1c)
[<c0470148>] (ep93xx_adc_driver_init) from [<c045ce88>] (do_one_initcall+0x7c/0x1a4)
[<c045ce88>] (do_one_initcall) from [<c045d184>] (kernel_init_freeable+0x17c/0x1fc)
[<c045d184>] (kernel_init_freeable) from [<c03a64d0>] (kernel_init+0x8/0xf8)
[<c03a64d0>] (kernel_init) from [<c00082d8>] (ret_from_fork+0x14/0x3c)
...
ep93xx-adc ep93xx-adc: Cannot enable clock
ep93xx-adc: probe of ep93xx-adc failed with error -108
Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20210613233041.128961-2-alexander.sverdlin@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

For the function of platform_get_irq(), the example in platform.c is
 *	int irq = platform_get_irq(pdev, 0);
 *	if (irq < 0)
 *		return irq;
the return value of zero is unnecessary to check, so make the right
check and simplify code.

Note that platform_get_irq() is documented as never returning 0
so this is a minor optmization rather than a fix.
Co-developed-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: NTang Bin <tangbin@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20210802120929.33760-1-tangbin@cmss.chinamobile.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add a device managed hook, via devm_add_action_or_reset() and
max5821_regulator_disable(), to disable voltage regulator on device
detach.
Replace iio_device_register() by devm_iio_device_register() and remove
the max5821_remove() function used to unregister the device and disable the
voltage regulator.
Remove i2c_set_clientdata() from the probe function, since
i2c_get_clientdata() is not used anymore.
Remove regulator_disable() calls from the probe function.
Signed-off-by: NThéo Borém Fabris <theobf@usp.br>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210724220159.11998-1-theobf@usp.brSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add both the jz4760 and jz4760b, plus a property to use the internal
divider on the b variant and document it.
Signed-off-by: NChristophe Branchereau <cbranchereau@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210726082033.351533-6-cbranchereau@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The JZ4760B variant differs slightly from the JZ4760: it has a bit called VBAT_SEL in the CFG register.

In order to correctly sample the battery voltage on existing handhelds using this SOC, the bit must be cleared.

We leave the possibility to set the bit, by using the "ingenic,use-internal-divider" in the devicetree.
Signed-off-by: NChristophe Branchereau <cbranchereau@gmail.com>
Link: https://lore.kernel.org/r/20210726082033.351533-5-cbranchereau@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The jz4760 sadc is very similar to the jz4770 one, but has a VREF of 2.5V
and 3 aux channels.

modify ingenic_adc_read_chan_info_raw() needs a change to account for it.
Signed-off-by: NChristophe Branchereau <cbranchereau@gmail.com>
Reviewed-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210726082033.351533-4-cbranchereau@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The JZ4760(B) socs have 3 AUX inputs, add an entry to prepare including the one named AUX in the sadc driver.
Leaving the rest untouched as it's ABI.
Signed-off-by: NChristophe Branchereau <cbranchereau@gmail.com>
Reviewed-by: NPaul Cercueil <paul@crapouillou.net>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210726082033.351533-3-cbranchereau@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The jz4760(b) socs have 3 aux channels.

The purpose of has_aux2 is to set the MD bits used to select
the AUX channel to be sampled, not to describe the hardware.

Rename it to a more appropriate name.
Signed-off-by: NChristophe Branchereau <cbranchereau@gmail.com>
Reviewed-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210726082033.351533-2-cbranchereau@gmail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Use device_property_read_... to support both device tree and ACPI
bindings.
Simplify the logic for reading "combined-sensors" array, as we assume
it has been vetted at firmware build time.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210728181757.187627-1-gwendal@chromium.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Align the function arguments after a line-break with the opening
parenthesis on the previous line. No functional changes intended.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210717233718.332267-4-martin.blumenstingl@googlemail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add a missing space between if and the opening parenthesis to make the
coding style consistent across the whole driver. No functional changes
intended.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210717233718.332267-3-martin.blumenstingl@googlemail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

G12A and newer don't use the SAR ADC to read the SoC temperature from
within the firmware. Instead there's now a dedicated thermal sensor.
Disable the BL30 integration for G12A and newer SoCs to save a few CPU
cycles when reading samples.
Adding a separate struct meson_sar_adc_data is a good idea anyways
because starting with G12A there's some extra registers to read the
samples in a simplified way.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210717233718.332267-2-martin.blumenstingl@googlemail.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The st_gyro_allocate_ring() function calls iio_triggered_buffer_setup() to
allocate a triggered buffer.

But the same can be done with devm_iio_triggered_buffer_setup() and then
the st_gyro_common_remove() no longer needs to manually deallocate it.

We know that the parent of the IIO device is used to manage other instances
of the devm unwind, so it can be used in the st_gyro_allocate_ring() as
well.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-4-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The st_magn_allocate_ring() function calls iio_triggered_buffer_setup() to
allocate a triggered buffer.

But the same can be done with devm_iio_triggered_buffer_setup() and then
the st_magn_common_remove() no longer needs to manually deallocate it.

We know that the parent of the IIO device is used to manage other instances
of the devm unwind, so it can be used in the st_magn_allocate_ring() as
well.

This change also removes some omitted st_magn_{probe,remove}_trigger()
inline hooks.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-3-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The st_accel_allocate_ring() function calls iio_triggered_buffer_setup() to
allocate a triggered buffer.

But the same can be done with devm_iio_triggered_buffer_setup() and then
the st_accel_common_remove() no longer needs to manually deallocate it.

We know that the parent of the IIO device is used to manage other instances
of the devm unwind, so it can be used in the st_accel_allocate_ring() as
well.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-2-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The st_press_allocate_ring() function calls iio_triggered_buffer_setup() to
allocate a triggered buffer.

But the same can be done with devm_iio_triggered_buffer_setup() and then
the st_press_common_remove() no longer needs to manually deallocate it.

We know that the parent of the IIO device is used to manage other instances
of the devm unwind, so it can be used in the st_press_allocate_ring() as
well.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-1-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Use the defined variable "dev" to make the code cleaner.
Co-developed-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: NTang Bin <tangbin@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20210720125945.11548-1-tangbin@cmss.chinamobile.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Remove iio_claim/release and change it on mutex accordingly in
vcnl3020_write_proxy_samp_freq.
Signed-off-by: NIvan Mikhaylov <i.mikhaylov@yadro.com>
Link: https://lore.kernel.org/r/20210722154420.915082-4-i.mikhaylov@yadro.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add the possibility to run proximity sensor in periodic measurement
mode with thresholds.

Reported-by: kernel test robot <lkp@intel.com> #repeated include
Signed-off-by: NIvan Mikhaylov <i.mikhaylov@yadro.com>
Link: https://lore.kernel.org/r/20210722154420.915082-3-i.mikhaylov@yadro.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add DMA safe buffer for bulk transfers.
Signed-off-by: NIvan Mikhaylov <i.mikhaylov@yadro.com>
Link: https://lore.kernel.org/r/20210722154420.915082-2-i.mikhaylov@yadro.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The st-sensors drivers have changed in structure over time, and includes
have not always kept up with this.  Let's bring them back to nearer
the ideal.

Identified with the  include-what-you-use tool and careful checking of
its suggestions.

Note I haven't been particularly aggressive here, so this is just the
cases where the include obviously isn't needed rather than the more
subtle corners.

Note I took the opportunity to add mod_devicetable.h as I generally
prefer to see that when acpi or of match tables are present.
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210608175149.4019289-1-jic23@kernel.org

In Linux the bma180 and bmc150-accel driver cover fairly similar chips
from Bosch (just with minor register differences). For the DT schema,
this does not make any difference: They both represent I2C/SPI devices,
have one or two interrupts plus a vdd/vddio-supply.

This means there is no need to duplicate the schema, we can just
document the compatibles for both drivers in a single DT schema.
Suggested-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-4-stephan@gerhold.netSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Similar to recent rework in the bmc150-accel driver, sort the compatible
list in the DT schema so there is a consistent order.
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-3-stephan@gerhold.netSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Bosch accelerometers similar to BMA255 are initially configured to
emit an active-high interrupt signal. This is currently not re-configured
in the bmc150-accel driver so the interrupt should most certainly be
IRQ_TYPE_EDGE_RISING (or potentially IRQ_TYPE_LEVEL_HIGH).
(Unless there is some kind of inverter installed on the board...)

At the moment the bmc150-accel driver forcefully requests the IRQ
using IRQF_TRIGGER_RISING, which means that the IRQ type is currently
ignored in all existing device trees.

Fixes: 6259551c ("iio: accel: bmc150-accel: Add DT bindings")
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-2-stephan@gerhold.netSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The continue statement at the end of a for-loop has no effect,
remove it.

Addresses-Coverity: ("Continue has no effect")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210617081312.151746-1-colin.king@canonical.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The point of this new change is to make the IIO tree actually parsable.

Before, given this attribute as a filename:
in_voltage0_aux_sample_rate

Userspace had no way to know if the attribute name was
"aux_sample_rate" with no extended name, or "sample_rate" with "aux" as
the extended name, or just "rate" with "aux_sample" as the extended
name.

This was somewhat possible to deduce when there was more than one
attribute present for a given channel, e.g:
in_voltage0_aux_sample_rate
in_voltage0_aux_frequency

There, it was possible to deduce that "aux" was the extended name. But
even with more than one attribute, this wasn't very robust, as two
attributes starting with the same prefix (e.g. "sample_rate" and
"sample_size") would result in the first part of the prefix being
interpreted as being part of the extended name.

To address the issue, knowing that channels will never have both a label
and an extended name, set the channel's label to the extended name.
In this case, the label's attribute will also have the extended name in
its filename, but we can live with that - userspace can open
in_voltage0_<prefix>_label and verify that it returns <prefix> to obtain
the extended name.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210618123005.49867-3-paul@crapouillou.netSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Extended names are a problem for user-space as they make the filenames
in sysfs sometimes not parsable. They are now deprecated in favor of
labels.

This change makes sure that a device driver won't provide both labels
and extended names for its channels. It has never been the case and we
don't want it to happen.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Reviewed-by: NAlexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210618123005.49867-2-paul@crapouillou.netSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

Add startup time for each chip familly. This allows a better behaviour of
the gyro and the accel. The gyro has now the time to stabilise itself
thus making initial data discarding for gyro irrelevant.
Signed-off-by: NBaptiste Mansuy <bmansuy@invensense.com>
Acked-by: NJean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20210621085731.9212-1-bmansuy@invensense.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This driver has two parts, one for i2c and one for spi, since the chip can
operate with both wire protocols.

The core file has a common adxl345_core_remove() function which puts the
chip into a powerdown state. This can be implemented with a
devm_add_action_or_reset() hook.

Doing that means we can register the IIO device with
devm_iio_device_register() and get rid of the adxl345_core_remove()
function.

The dev_set_drvdata() call can be removed as there is no other user of this
private data anymore.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080441.8710-1-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This change converts the driver to use only device-managed init routines in
the probe function of the driver.

This way, we no longer need the tcs3414_remove() hook.
We still need to keep the i2c_set_clientdata() call, as that's being used
for the PM routines.

And lastly, a devm_add_action_or_reset() hook is added to call the
powerdown handler when the chip is uninitialized or the probe fails.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080534.9209-1-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The change converts the probe function to use the
devm_iio_device_register() function.

Before calling that, we need to register an action to store the wiper back
to non-volatile memory when the device is de-registered.

We don't need to do this if the probe fails, because the only place where
the probe can fail now is devm_iio_device_register() and that shouldn't
create an IIO device (for userspace to poke at) if it fails.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080641.9953-1-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

When the device is probed, there's no guarantee that the device is not in
power-down mode. This can happen if the driver is unregistered and
re-probed.

To make sure this doesn't happen, the value of the TMP006_CONFIG register
(which is read in the probe function and stored in the device's private
data) is being checked to see if the MOD bits have the correct value.

This is a fix for a somewhat-rare corner case. As it stands, this doesn't
look like a high priority to go into the Fixes route.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624081924.15897-2-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

This change converts the driver to register via devm_iio_device_register().
For the tmp006_powerdown() hook, this uses a devm_add_action() hook to put
the device in powerdown mode when it's unregistered.

With these changes, the remove hook can be removed.

The i2c_set_clientdata() call is staying around as the private data is used
in the PM routines.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624081924.15897-1-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>

The datasheet mentions that the suspend mode is toggled by reading the
suspend register. The reading returns value 0xFF if the system was in
suspend mode, otherwise it returns value 0x00.

The bma220_deinit() function does up to 2 reads, in case the device was in
suspend mode, which suggests a level of paranoia that makes the logic in
bma220_suspend() and bma220_resume() look insufficient.

This change implements a bma220_power() function which does up to 2 reads
of the suspend register to make sure that the chip enters a desired
(suspended or normal) mode.

If the transition fails, then -EBUSY is returned.

Since only a reference to SPI device is required, we can remove the
spi_set_drvdata() call and get the SPI device object from the base device
object in the suspend/resume routines.
Signed-off-by: NAlexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625140137.362282-2-aardelean@deviqon.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>