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: Andreas Klinger <ak@it-klinger.de>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20210804154641.GA3237@arbad
Signed-off-by: Jonathan 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: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20210613233041.128961-2-alexander.sverdlin@gmail.com
Signed-off-by: Jonathan 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: Théo Borém Fabris <theobf@usp.br>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210724220159.11998-1-theobf@usp.br
Signed-off-by: Jonathan 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: Christophe Branchereau <cbranchereau@gmail.com>
Link: https://lore.kernel.org/r/20210726082033.351533-5-cbranchereau@gmail.com
Signed-off-by: Jonathan 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: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210717233718.332267-2-martin.blumenstingl@googlemail.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-4-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-3-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-2-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210720074642.223293-1-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Jonathan 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: Linus 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: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-4-stephan@gerhold.net
Signed-off-by: Jonathan 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: 6259551cf1 ("iio: accel: bmc150-accel: Add DT bindings")
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210614163150.7774-2-stephan@gerhold.net
Signed-off-by: Jonathan 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: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210618123005.49867-3-paul@crapouillou.net
Signed-off-by: Jonathan 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: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210618123005.49867-2-paul@crapouillou.net
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080441.8710-1-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080534.9209-1-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624080641.9953-1-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624081924.15897-2-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210624081924.15897-1-aardelean@deviqon.com
Signed-off-by: Jonathan 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: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625140137.362282-2-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change converts the driver to use devm_iio_triggered_buffer_setup()
and devm_iio_device_register() for initializing and registering the IIO
device.
The bma220_deinit() is converted into a callback for a
devm_add_action_or_reset() hook, so that the device is put in stand-by when
the driver gets uninitialized.
The return value of the bma220_deinit() function isn't used as it does not
add any value. On the error path of the probe function, this can just
override the actual error with -EBUSY, or can even return 0 (no error), on
the error path.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625140137.362282-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This binding covers the ad5744, ad5744r, ad5764 and ad5764r DACs.
Note that the driver currently assumes the internal reference is used for
the r parts. The binding as defined relaxes this constraint.
There is no support in the binding or driver for the two digital IO
signals. I do not propose to add that until we have a means to
test any such binding.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-13-jic23@kernel.org
The naming of the regulator is problematic. VCC is usually a supply
voltage whereas these devices have a separate VREF pin.
Secondly, the regulator core might have provided a stub regulator if
a real regulator wasn't provided. That would in turn have failed to
provide a voltage when queried. So reality was that there was no way
to use the internal reference.
In order to avoid breaking any dts out in the wild, make sure to fallback
to the original vcc naming if vref is not available.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210627163244.1090296-9-jic23@kernel.org
