Semtech SAR sensor SX9324 is an evolution of the SX9310:
It has 4 phases that can be configured to capture and process data
from any of 3 CS pins and provide independent detection:
proximity, table proximity or body proximity.
Gather antenna data:
echo sx9324-dev3 > trigger/current_trigger
echo 1 > scan_elements/in_proximity0_en
echo 1 > buffer/enable
od -v -An --endian=big -t d2 -w2 /dev/iio\:device3
(at 10Hz, the default).
Trigger events:
Setting:
thresh_falling_period: 2 (events)
thresh_rising_period: 2 (events)
in_proximity0_thresh_either_value: 300
in_proximity0_thresh_either_hysteresis: 72
using iio_event_monitor /dev/iio\:deviceX, approaching my hand to the
antenna pad, I see:
...
Event: time: 1634763907532035297, type: proximity, channel: 0, evtype:
thresh, direction: falling
Event: time: 1634763910138104640, type: proximity, channel: 0, evtype:
thresh, direction: rising
...
Datasheet: https://edit.wpgdadawant.com/uploads/news_file/program/2019/30184/tech_files/program_30184_suggest_other_file.pdf
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20220101203817.290512-4-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Before adding new Semtech sensors, move common logic to all Semtech SAR
sensor in its own file:
- interface with IIO subsystem,
- interrupt management,
- channel access conrol,
- event processing.
The change adds a bidirectional interface between sx93xx and sx_common.
The change is quite mechanical, as the impacted functions are moved
and renamed.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20220101203817.290512-3-gwendal@chromium.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Pull bitmap updates from Yury Norov:
- introduce for_each_set_bitrange()
- use find_first_*_bit() instead of find_next_*_bit() where possible
- unify for_each_bit() macros
* tag 'bitmap-5.17-rc1' of git://github.com/norov/linux:
vsprintf: rework bitmap_list_string
lib: bitmap: add performance test for bitmap_print_to_pagebuf
bitmap: unify find_bit operations
mm/percpu: micro-optimize pcpu_is_populated()
Replace for_each_*_bit_from() with for_each_*_bit() where appropriate
find: micro-optimize for_each_{set,clear}_bit()
include/linux: move for_each_bit() macros from bitops.h to find.h
cpumask: replace cpumask_next_* with cpumask_first_* where appropriate
tools: sync tools/bitmap with mother linux
all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate
cpumask: use find_first_and_bit()
lib: add find_first_and_bit()
arch: remove GENERIC_FIND_FIRST_BIT entirely
include: move find.h from asm_generic to linux
bitops: move find_bit_*_le functions from le.h to find.h
bitops: protect find_first_{,zero}_bit properly
Pull more power management updates from Rafael Wysocki:
"This is a continuation of the rework of device power management macros
used for declaring device power management callbacks (Paul Cercueil)"
* tag 'pm-5.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
iio: pressure: bmp280: Use new PM macros
PM: runtime: Add EXPORT[_GPL]_RUNTIME_DEV_PM_OPS macros
PM: runtime: Add DEFINE_RUNTIME_DEV_PM_OPS() macro
PM: core: Add EXPORT[_GPL]_SIMPLE_DEV_PM_OPS macros
PM: core: Remove static qualifier in DEFINE_SIMPLE_DEV_PM_OPS macro
PM: core: Remove DEFINE_UNIVERSAL_DEV_PM_OPS() macro
find_first{,_zero}_bit is a more effective analogue of 'next' version if
start == 0. This patch replaces 'next' with 'first' where things look
trivial.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Use the new EXPORT_RUNTIME_DEV_PM_OPS() macro. It allows the underlying
dev_pm_ops struct as well as the suspend/resume callbacks to be detected
as dead code in the case where CONFIG_PM is disabled, without having to
wrap everything inside #ifdef CONFIG_PM guards.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Clang static analysis reports this representative warning
sunrise_co2.c:410:9: warning: Assigned value is garbage or undefined
*val = value;
^ ~~~~~
The ealier call to sunrise_read_word can fail without setting
value. So defer setting val until we know the read was successful.
Fixes: c397894e24 ("iio: chemical: Add Senseair Sunrise 006-0-007 driver")
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20211224150833.3278236-1-trix@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan writes:
1st set of IIO new device support, features and cleanup for 5.17
Includes some fixes that were either late breaking, low priority or
complex enough to not be good to rush in late in the cycle.
Tree rebased today to fix up some trivial issues + pull in a fix that
was previously on the fixes-togreg branch. Vast majority have been
in linux-next for some time now.
New device support
* adi,ad7293
- New driver and bindings for this Power Amplifier drain current
controller. A complex device with various related monitoring functions.
* adi,ad75513R
- New driver and bindings for this combined ADC and DAC device.
- A few follow up fixes.
* adi,admv8818
- New driver (and type) for this 2-18GHz filter device. Includes
bindings and ABI documentation to allow clk_notifier based auto
adjustment of the filters in appropriate applications.
* liteon,ltr501
- Support for the ltr303. ID and chip specific info table.
* xilinx,ams
- New generic firmware function fwnode_iomap() as used in this driver.
- New driver and bindings for this ADC and on-chip sensors as found
in various Xilinx devices.
Core
* Introduced IIO_VAL_INT_64 which uses val and val2 in IIO callbacks to
form a 64 bit integer when higher precision needed.
* Allow IIO_ENUM_AVAILABLE to be used with different shared values.
* Fix a long term issue with scheduling whilst atomic when iio_trig_poll()
is called but no trigger consumers are actually enabled and hence the
trigger may be reenabled from the interrupt handler. Seen in the wild
on the tsc2046.
* Mark iio_device_type const.
* buffer: Use a separate index variable to simplify code.
* buffer-dma: Clear out unused struct iio_buffer_block
* buffer-dmaengine: Switch to cheaper round_down() as power of 2 values.
Tests/tools
* format_value
- Check against NULL returns from allocations in tests.
- Add IIO_VAL_INT_64 test case.
* event_monitor
- Flush the output after event to given more consistent latency
when tool output piped to other programs.
Driver Features
* axp20x
- Add support for NTC thermistor channel and document TS pin binding.
* arm,scmi
- Add reading of raw channel values (using IIO_VAL_INT_64)
* liteon,ltr501
- Add proximity-near-level support and dt-binding.
Tree wide cleanup
* Remove no-op trigger ops from multiple drivers.
* Stop using dev_get_drvdata() on the iio_dev->dev in various drivers
and then stop assigning it to allow this to be used for other purposes.
We can always get to the indio_dev using dev_to_iio_dev() which is
a container_of() based approach. Also cleanup up some related unnecessary
convoluted cases.
- atmel,at91-sam5d2
- nxp,imx7d
- meas,ms5611
- st,st_sensors
* Where available (or easy to introduce) use the scan_type.* values
in place of a second copy for read_raw and similar paths.
- adi,ad7266
- bosch,bma220
- fsl,mac3110
- fsl,mma7455
- fsl,mpl3115
- kionix,kcjk-1013
- sensortek,stk8ba50
- sensortek,stk8312
- ti,adc12138
- ti,ads1015
- vti,sca3000
- xilinx,xadc-core
* Switch drives over to generic firmware properties including appropriate
header changes to avoid including of.h
- Various DACs had false CONFIG_OF dependencies.
- dpot-dac
- envelope-detector
- adi,ad5755
- adi,ad5758
- capella,cm3605
- maxim,max9611
- microchip,mcp41010
- microchip,mcp3911
- ti,adc12138
* Trivial clang warning fixes for W=1 warnings.
Driver specific cleanup and minor fixes
* adi,ad7606
- Comment fixes.
* ams,ad3935
- Drop pointless cast to the same type.
* atmel,at91-sama5d2
- Fix wrong cast of iio_dev->dev to platform_device that happened to
be harmless.
* fsl,mma7660
- Stop i2c remove() function returning an error code. Part of a rework
to eventually stop returning anything from these.
* fsl,mma8452
- Use correct type for local irqreturn_t.
* nxp,imx8mq
- Maintainer email address update.
* nxp,lpc18xx_adc
- Ensure clk_prepare_enable() called before clk_get_rate().
- Switch of.h for mod_devicetable.h to reflect no of specific functions,
just the id table.
* renesas,rzg2l
- Drop a dev_err() that just duplicates error printed in platform_get_irq()
* sgx,vz89x
- Drop pointless cast.
* st,lsm6dsx
- Make it possible to disable the sensorhub from DT to avoid a corner
case where the address of a slave device many be accidentally modified.
* st,stm32-adc
- Stop leaking an of_node in an error path.
* st,stmp2
- Avoid wrong sized type for bit field which could result in
over-reading (harmless). Precursor to enabling -Warray-bounds.
* ti,adc081c
- Put back some ACPI support for non standards compliant ADC081C
ID because it is known to be in the wild on some Aaeon boards.
* ti,ads8688
- Cleanup redundant local ret variable assignment.
* ti,ina2xx-adc
- Use helper macro kthread_run() to replace some boilerplate.
- Avoid double reference counting.
- Drop pointless cast.
* xilinx,xadc
- Make the IRQ optional as not always wired to the host system.
* tag 'iio-for-5.17a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (103 commits)
iio: adc: ti-adc081c: Partial revert of removal of ACPI IDs
iio:addac:ad74413r: Fix uninitialized ret in a path that won't be hit.
MAINTAINERS: Add maintainer for xilinx-ams
dt-bindings: iio: adc: Add Xilinx AMS binding documentation
iio: adc: Add Xilinx AMS driver
device property: Add fwnode_iomap()
iio:accel:kxcjk-1013: Mark struct __maybe_unused to avoid warning.
iio:accel:bmc150: Mark structure __maybe_unused as only needed with for pm ops.
iio:dummy: Drop set but unused variable len.
iio:magn:ak8975: Suppress clang W=1 warning about pointer to enum conversion.
iio:imu:inv_mpu6050: Suppress clang W=1 warning about pointer to enum conversion.
iio:imu:inv_icm42600: Suppress clang W=1 warning about pointer to enum conversion.
iio:dac:mcp4725: Suppress clang W=1 warning about pointer to enum conversion.
iio:amplifiers:hmc425a: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:ti-ads1015: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:rcar: Suppress clang W=1 warning about pointer to enum conversion.
iio:adc:ina2xx-adc: Suppress clang W=1 warning about pointer to enum conversion.
iio:accel:bma180: Suppress clang W=1 warning about pointer to enum conversion.
drivers:iio:dac: Add AD3552R driver support
dt-bindings: iio: dac: Add adi,ad3552r.yaml
...
I don't believe it's possible to hit this, because we drop
out of __iio_update_buffers() earlier in the event of an empty
list. However, that is not visible to the compiler so lets
return an error if we do hit the loop with an empty bitmask.
Fixes: 5d97d9e9a7 ("iio: addac: ad74413r: fix off by one in ad74413r_parse_channel_config()")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20211220164726.3136307-1-jic23@kernel.org
The AMS includes an ADC as well as on-chip sensors that can be used to
sample external voltages and monitor on-die operating conditions, such
as temperature and supply voltage levels. The AMS has two SYSMON blocks.
PL-SYSMON block is capable of monitoring off chip voltage and
temperature.
PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring
from an external master. Out of these interfaces currently only DRP is
supported. Other block PS-SYSMON is memory mapped to PS.
The AMS can use internal channels to monitor voltage and temperature as
well as one primary and up to 16 auxiliary channels for measuring
external voltages.
The voltage and temperature monitoring channels also have event capability
which allows to generate an interrupt when their value falls below or
raises above a set threshold.
Co-developed-by: Manish Narani <manish.narani@xilinx.com>
Signed-off-by: Manish Narani <manish.narani@xilinx.com>
Signed-off-by: Anand Ashok Dumbre <anand.ashok.dumbre@xilinx.com>
Link: https://lore.kernel.org/r/20211203212358.31444-4-anand.ashok.dumbre@xilinx.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The case to u8 * is unnecessary here since the expression is already of
type u8 *.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
`buf` is cast to a const char *, but `buf` is already a const char *, so
the case is unnecessary.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
`buf` is cast to a const char *, but `buf` is already a const char *, so
the case is unnecessary.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The find.h APIs are designed to be used only on unsigned long arguments.
This can technically result in a over-read, but it is harmless in this
case. Regardless, fix it to avoid the warning seen under -Warray-bounds,
which we'd like to enable globally:
In file included from ./include/linux/bitmap.h:9,
from ./include/linux/cpumask.h:12,
from ./arch/x86/include/asm/cpumask.h:5,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/processor.h:22,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:60,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:78,
from ./include/linux/spinlock.h:55,
from ./include/linux/swait.h:7,
from ./include/linux/completion.h:12,
from drivers/iio/adc/stmpe-adc.c:10:
drivers/iio/adc/stmpe-adc.c: In function 'stmpe_adc_probe':
./include/linux/find.h:98:23: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Warray-bounds]
98 | val = *addr | ~GENMASK(size - 1, offset);
| ^~~~~
drivers/iio/adc/stmpe-adc.c:258:13: note: while referencing 'norequest_mask'
258 | u32 norequest_mask = 0;
| ^~~~~~~~~~~~~~
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Drvdata is typically used by drivers to attach driver specific data to a
device. It is used to retrieve driver specific information when only the
device to which the data is attached is available.
In the IIO core in the `iio_device_alloc()` function we call
`iio_device_set_drvdata(indio_dev, indio_dev)`. This sets the drvdata of
the IIO device to itself.
This is rather unnecessary since if we have a pointer to the IIO device to
call `iio_device_get_drvdata()` on it we don't need to call the function
since we already have the pointer. If we only have a pointer to the `struct
device` we can use `dev_to_iio_dev()` to get the IIO device from it.
Furthermore the drvdata is supposed to be reserved for drivers, so it
should not be used by the IIO core in the first place.
The `set_drvdata()` has been around from the very beginning of the IIO
framework and back then it was used in the IIO device sysfs attribute
handling code. But that was subsequently replaced with a `dev_to_iio_dev()`
in commit e53f5ac52e ("iio: Use dev_to_iio_dev()") and other cleanups.
The self `set_drvdata()` is now no longer needed and can be removed.
Verified that there no longer any users by checking for potential users
using the following two coccinelle scripts and reviewing that none of the
matches are problematic code.
<smpl>
@@
struct iio_dev *iio_dev;
expression dev;
identifier fn !~ "(remove|resume|suspend)";
@@
fn(...)
{
...
*iio_dev = dev_get_drvdata(dev)
...
}
</smpl>
<smpl>
@r1@
position p;
struct iio_dev *indio_dev;
identifier dev_fn =~ "^dev_";
identifier devm_fn =~ "^devm_";
@@
(
dev_fn
|
devm_fn
)
(&indio_dev@p->dev, ...)
@@
struct iio_dev *indio_dev;
position p != r1.p;
@@
*&indio_dev@p->dev</smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We could probably drop a lot more of these, but for now this removes
unnecessary restrictions on stand alone ADC devices.
For these 3 drivers the false dependency seems to date all
the way back to their initial introduction.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Nothing in this driver depends on OF firmware so drop the dependency
and update the headers to remove the false impression such a dependency
exists.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
