As these exports are only relevant to core module and users in the
bus specific modules, move them out of the main kernel namespace.
Includes using EXPORT_NS_GPL_DEV_PM_OPS() and the simplifications that
brings by allowing the compiler to remove unused struct dev_pm_ops
and callbacks without needing explicit __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
--
EXPORT_NS_GPL_DEV_PM_OPS()
v2: Switch to Paul's more flexible version of the
Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Link: https://lore.kernel.org/r/20220925155719.3316280-5-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Includes using EXPORT_NS_GPL_DEV_PM_OPS() and the simplifications that
brings by allowing the compiler to remove unused struct dev_pm_ops
and callbacks without needing explicit __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
--
Dropped Rui's tag on basis this is rather different from v1 due to
the different macro implementation.
v2: Switch to Paul's more flexible approach to EXPORT_NS_GPL_DEV_PM_OPS()
Acked-by: Rui Miguel Silva <rui.silva@linaro.org>
Link: https://lore.kernel.org/r/20220925155719.3316280-4-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Using this macro allows the compiler to remove unused
structures and callbacks if we are not building with
CONFIG_PM* without needing __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Sean Nyekjaer <sean@geanix.com>
--
Switched to Paul Cercueil's more flexible implementation fo the macro.
Dropped Sean's Ack given new form of macro being used.
Acked-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20220925155719.3316280-3-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
MPL115 supports shutdown gpio which can be used to set the state
to low power mode. Power from all internal circuits and
registers is removed. This is done by pulling the SHDN pin to low.
This patch enables runtime PM on MPL115 to increase power savings.
According to spec., a wakeup time period of ~5 ms exists between
waking up and actually communicating with the device. This is
implemented using sleep delay.
Signed-off-by: Rajat Khandelwal <rajat.khandelwal@linux.intel.com>
Link: https://lore.kernel.org/r/20221010173720.568916-1-rajat.khandelwal@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Now that there are no more users accessing 'mlock' directly, we can move
it to the iio_dev private structure. Hence, it's now explicit that new
driver's should not directly use this lock.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20221012151620.1725215-5-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The pattern used in this device does not quite fit in the
iio_device_claim_direct_mode() typical usage. In this case, we want to
know if we are in buffered mode or not to know if the device is powered
(buffer mode) or not. And depending on that max30102_get_temp() will
power on the device if needed. Hence, in order to keep the same
functionality, we try to:
1. Claim Buffered mode;
2: If 1) succeeds call max30102_get_temp() without powering on the
device;
3: Release Buffered mode;
4: If 1) fails, Claim Direct mode;
5: If 4) succeeds call max30102_get_temp() with powering on the device;
6: Release Direct mode;
7: If 4) fails, goto to 1) and try again.
This dance between buffered and direct mode is not particularly pretty
(as well as the loop introduced by the goto statement) but it does allow
us to get rid of the mlock usage while keeping the same behavior.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20221012151620.1725215-4-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The pattern used in this device does not quite fit in the
iio_device_claim_direct_mode() typical usage. In this case,
iio_buffer_enabled() was being used not to prevent the raw
access but to allow it. Hence, let's make use of the new
iio_device_claim_buffer_mode() API to make sure we stay in
buffered mode during the complete read.
Note that we are shadowing the error code returned by
iio_device_claim_buffer_mode() so that we keep the original one
(-EAGAIN). The reason is that some userspace stack might already be
relying on this particular code so that we are not taking chances and
leave it alone.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221012151620.1725215-3-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These APIs are analogous to iio_device_claim_direct_mode() and
iio_device_release_direct_mode() but, as the name suggests, with the
logic flipped. While this looks odd enough, it will have at least two
users (in following changes) and it will be important to move the IIO
mlock to the private struct.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20221012151620.1725215-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Force minimum sampling time for all internal channels according
to datasheet requirement. This value can be increased through
DT st,min-sample-time-ns property.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/20221012142205.13041-5-olivier.moysan@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add STM32 ADC support for STM32MP13x SOCs family.
On STM32MP13x, each ADC peripheral has a single ADC block.
These ADC peripherals, ADC1 and ADC2, are fully independent.
This introduces changes in common registers handling.
Some features such as boost mode, channel preselection and
linear calibration are not supported by the STM32MP13x ADC.
Add diversity management for these features.
The STM32MP13x ADC introduces registers and bitfield variants
on existing features such as calibration factors and internal
channels. Add register diversity management.
Add also support for new internal channels VDDCPU and VDDQ_DDR.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20221012142205.13041-4-olivier.moysan@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add st,stm32mp13-adc-core and st,stm32mp13-adc compatibles
to support STM32MPU13 SoC.
On STM32MP13x, each ADC peripheral has a single ADC block.
These ADC peripherals, ADC1 and ADC2, are fully independent.
Main characteristics of STM32MP13x ADC:
- One interrupt line per ADC
- 6 to 12 bits resolution
- 19 channels
ADC2 instance supports two extra internal channels VDDCPU and VDDQ_DDR.
Add "vddcpu" and "vddq_ddr" internal channels names to the reserved
labels list.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221012142205.13041-3-olivier.moysan@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and PD
standards.
Add support for the MT6370 ADC driver for system monitoring, including
charger current, voltage, and temperature.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com>
Link: https://lore.kernel.org/r/81ec58ae89030e48508d6810396de2679c40d26c.1665488982.git.chiaen_wu@richtek.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Adding support for max11410 24-bit, 1.9ksps delta-sigma adc which
has 3 differential reference and 10 differential channel inputs.
Inputs and references can be buffered internally. Inputs can also
be amplified with internal PGA.
Device has four digital filter modes: FIR50/60, FIR50, FIR60 and SINC4.
FIR 50Hz and 60Hz rejections can be enabled/disabled separately.
Digital filter selection affects sampling frequency range so driver
has to consider the configured filter when configuring sampling frequency.
Signed-off-by: Ibrahim Tilki <Ibrahim.Tilki@analog.com>
Link: https://lore.kernel.org/r/20221003105903.229-2-Ibrahim.Tilki@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For devices connectable by SPI bus (e.g. already using
"spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
schema to allow using all SPI device properties, even these which device
bindings author did not tried yet.
While changing additionalProperties->unevaluatedProperties, put it in
typical place, just before example DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221004115642.63749-8-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For devices connectable by SPI bus (e.g. already using
"spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
schema to allow using all SPI device properties, even these which device
bindings author did not tried yet.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221004115642.63749-7-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For devices connectable by SPI bus (e.g. already using
"spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
schema to allow using all SPI device properties, even these which device
bindings author did not tried yet.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221004115642.63749-6-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For devices connectable by SPI bus (e.g. already using
"spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
schema to allow using all SPI device properties, even these which device
bindings author did not tried yet.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004115642.63749-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For devices connectable by SPI bus (e.g. already using
"spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
schema to allow using all SPI device properties, even these which device
bindings author did not tried yet.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221004115642.63749-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For devices connectable by SPI bus (e.g. already using
"spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
schema to allow using all SPI device properties, even these which device
bindings author did not tried yet.
While changing additionalProperties->unevaluatedProperties, put it in
typical place, just before example DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221004115642.63749-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Improve example by: dropping unrelated properties (status and cs-gpios)
and using generic node name.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221004115642.63749-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reference the spi-peripheral-props.yaml schema to allow using all
properties typical for SPI-connected devices, even these which device
bindings author did not tried yet.
While changing additionalProperties->unevaluatedProperties, put it in
typical place, just before example DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221004115642.63749-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As the maintainer email no longer exists, change it to myself.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221005085044.204701-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As the maintainer email no longer exists, change it to myself.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20221005085044.204701-1-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-13-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-12-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
In order to drop the internal lock usage we needed two different things:
1) The first place where 'mlock' was being used was a typical case where
iio_device_claim_direct_mode() fits perfectly.
2) In the second case, it was being used to prevent concurrent accesses
to the device and shared data but nothing was being enforced with
regards to buffering (i.e, there was nothing preventing from changing
the conversion mode while buffering). Hence, in this case, a new lock
was introduced in the state structure.
Note that the goal is not to introduce any functional change and that is
the reason why a new lock was introduced to guarantee 2).
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-11-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is a precursor change to make it simpler to remove the 'mlock'
usage. Having the code in it's own helper function, also makes it easier
to read the error paths.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-10-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-9-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20221004134909.1692021-8-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-7-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-6-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-5-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-4-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device lock is only meant for internal use. Hence define a
device local lock to protect against concurrent accesses.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-3-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
'mlock' was being grabbed when setting the device frequency. In order to
not introduce any functional change a new lock is added. With that in
mind, the lock also needs to be grabbed in the places where 'mlock' is
since it was also being used to protect st->config against the current
device state.
On the other places the lock was being used, we can just drop
it since we are only doing one i2c bus read/write which is already
safe.
While at it, properly include "mutex.h" for mutex related APIs.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221004134909.1692021-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba6 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver ad7124 has no spi_device_id for adi,ad7124-4
SPI driver ad7124 has no spi_device_id for adi,ad7124-8
Add spi_device_id entries to silence the warnings, and ensure driver
module autoloading works.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20220921163620.805879-6-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba6 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver ad7192 has no spi_device_id for adi,ad7190
SPI driver ad7192 has no spi_device_id for adi,ad7193
SPI driver ad7192 has no spi_device_id for adi,ad7195
Add spi_device_id entries to silence the warnings, and ensure driver
module autoloading works.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20220921163620.805879-5-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba6 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver ad9467 has no spi_device_id for adi,ad9265
SPI driver ad9467 has no spi_device_id for adi,ad9434
Add spi_device_id entries to silence the warnings, and ensure driver
module autoloading works.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20220921163620.805879-4-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba6 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver sca3300 has no spi_device_id for murata,scl3300
Add spi_device_id entries to silence the warning, and ensure driver
module autoloading works.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Tomas Melin <tomas.melin@vaisala.com>
Link: https://lore.kernel.org/r/20220921163620.805879-3-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba6 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver ads131e08 has no spi_device_id for ti,ads131e04
SPI driver ads131e08 has no spi_device_id for ti,ads131e06
Add spi_device_id entries to silence the warnings, and ensure driver
module autoloading works.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20220921163620.805879-2-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs. It's more simple in error path.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220927064841.319291-1-yangyingliang@huawei.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add read/write attribute for proximity integration time, and read
attribute for available proximity integration times for the vcnl4040
chip.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20220926091900.1724105-3-marten.lindahl@axis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As the vcnl4040 and vcnl4200 chip uses runtime power management for
turning the ambient light and proximity sensors on/off, it overwrites
the entire register each time. In ALS_CONF register bit fields ALS_IT,
ALS_PERS, ALS_INT_EN are overwritten. In PS_CONF1 register bit fields
PS_DUTY, PS_PERS, PS_IT, PS_HD, and PS_INT are overwritten.
Add functions for preserving the affected bit fields when changing power
state.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20220926091900.1724105-2-marten.lindahl@axis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
ADMV8818_SW_IN_WR0_MSK and ADMV8818_SW_OUT_WR0_MSK have 3 bits,
which means a length of 8, but freq_range_hpf and freq_range_lpf
array size is 4, may end up reading 4 elements beyond the end of
those arrays.
Check value first before access freq_range_hpf and freq_range_lpf
to harden against the hardware allowing out of range values.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Link: https://lore.kernel.org/r/20220922115848.1800021-1-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for setting the Programmable Gain Amplifiers by adjust the
scale value.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220922194639.1118971-1-marcus.folkesson@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The current EINVAL value is more applicable to embedded library, where
user can actually put the fixed value to the sensor. In case of the
driver if the value of the channel is invalid it is better in inform
userspace that Channel was out of range as that implies more to internal
driver error than invalid input. It also makes for easier debugging of
where the error comes from during the development.
Signed-off-by: Crt Mori <cmo@melexis.com>
Link: https://lore.kernel.org/r/565d4df2592d751dc0f40908f2569b7c9af8e56e.1663834141.git.cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
