- 16 Dec, 2021 16 commits
-
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-2-jic23@kernel.org
-
Mihail Chindris authored
The AD3552R-16 is a low drift ultrafast, 16-bit accuracy, current output digital-to-analog converter (DAC) designed to generate multiple output voltage span ranges. The AD3552R-16 operates with a fixed 2.5V reference. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdfSigned-off-by:
Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211213110825.244347-3-mihail.chindris@analog.comSigned-off-by:
-
Mihail Chindris authored
Add documentation for ad3552r and ad3542r Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Antoniu Miclaus authored
Add initial ABI documentation for admv8818 filter sysfs interfaces. Signed-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by:
-
Antoniu Miclaus authored
Add device tree bindings for the ADMV8818 Filter. Signed-off-by:
-
Antoniu Miclaus authored
The ADMV8818-EP is a fully monolithic microwave integrated circuit (MMIC) that features a digitally selectable frequency of operation. The device features four independently controlled high- pass filters (HPFs) and four independently controlled low-pass filters (LPFs) that span the 2 GHz to 18 GHz frequency range. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/admv8818-ep.pdfSigned-off-by:
-
Antoniu Miclaus authored
Add filter subfolder for IIO devices that handle filter functionality. Signed-off-by:
-
Lars-Peter Clausen authored
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:
-
Lars-Peter Clausen authored
`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 authored
`buf` is cast to a const char *, but `buf` is already a const char *, so the case is unnecessary. Signed-off-by:
-
Kees Cook authored
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:
-
Minghao Chi authored
Return value from ads8688_prog_write() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
-
Dan Carpenter authored
The > needs to be >= to prevent accessing one element beyond the end of the st->channel_configs[] array. Fixes: fea251b6 ("iio: addac: add AD74413R driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Cosmin Tanislav <cosmin.tanislav@analog.com> Signed-off-by:
-
Xiang wangx authored
Delete the redundant word 'the'. Signed-off-by:
Xiang wangx <wangxiang@cdjrlc.com> Signed-off-by:
-
Zach DeCook authored
By flushing the output, iio_event_monitor can be more useful to programs chained along with it. iio_event_monitor stk3310 | awk '/rising/{system("my_unlockscreen.sh")} /falling/{system("my_lockscreen.sh")}' Without this flush, the above example would buffer a number of events, then after a while run the lock/unlock scripts several times. Signed-off-by:Zach DeCook <zachdecook@librem.one> Signed-off-by:
-
Lars-Peter Clausen authored
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 e53f5ac5 ("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:
-
- 12 Dec, 2021 19 commits
-
-
Jonathan Cameron authored
Probably a cut and paste error, but the binding header used in the example is for the wrong device and nothing from it is used. Signed-off-by:
-
Jonathan Cameron authored
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:
Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
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 authored
There is nothing directly using of specific interfaces in this driver, so lets not include the headers. Signed-off-by:
Peter Rosin <peda@axentia.se> Reviewed-by:
-
Jonathan Cameron authored
This enables using the driver with other firmware types such as ACPI via PRP0001. Also part of a general attempt to move IIO drivers over to generic properties to avoid opportunities for cut and paste. Signed-off-by:
-
Jonathan Cameron authored
This allows use of the driver with other types of firmware such as ACPI PRP0001 based probing. Also part of a general attempt to remove direct use of of_ specific accessors from IIO. Added an include for mod_devicetable.h whilst here to cover the struct of_device_id definition. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com>
-
Jonathan Cameron authored
Note the handling of the device tree node in this driver was somewhat unusual. I have cleaned that up whilst also moving over to generic properties. Part of a general attempt to move all IIO drivers over to generic firmware properties both as a general improvement and to avoid sources of cut and paste into future drivers. Signed-off-by:
-
Jonathan Cameron authored
This enables use of other firmware types with minimal driver changes. Part of an ongoing effort to move all IIO drivers over to generic accessors in order to reduce the chance of of_* versions being copied into new drivers. Also updated the headers to reflect this change including using mod_devicetable.h for struct of_device_id definition rather than going via of.h Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Jonathan Cameron authored
In this case it was only of_device_get_match_data() + header update. This enables use of other firmware types with no other changes, such as ACPI via the PRP0001 route. Signed-off-by:
-
Jonathan Cameron authored
This driver never used anything from the of specific headers. mod_devicetable.h provides the struct of_device_id definition. Signed-off-by:
-
Jonathan Cameron authored
This driver never used anything in the of specific header. It just wants the struct of_device_id from mod_devicetable.h. Signed-off-by:
-
Jonathan Cameron authored
These have never been used in this driver. What is used is in mod_devicetable.h so add that include (struct of_device_id) Signed-off-by:
-
Jonathan Cameron authored
Lars pointed out that platform data can also be supported via the generic properties interface, so there is no point in continuing to support it separately. Hence squish the linux/platform_data/ad5755.h header into the c file and drop accessing the platform data directly. Done by inspection only. Mostly completely mechanical with the exception of a few places where default value handling is cleaner done by first setting the value, then calling the firmware reading function but and not checking the return value, as opposed to reading firmware then setting the default if an error occurs. Part of general attempt to move all of IIO over to generic device properties, both to enable other firmware types and to remove drivers that can be the source of of_ specific behaviour in new drivers. Suggested-by:
-
Jonathan Cameron authored
IIO triggers are software IRQ chips that split an incoming IRQ into separate IRQs routed to all devices using the trigger. When all consumers are done then a trigger callback reenable() is called. There are a few circumstances under which this can happen in atomic context. 1) A single user of the trigger that calls the iio_trigger_done() function from interrupt context. 2) A race between disconnecting the last device from a trigger and the trigger itself sucessfully being disabled. To avoid a resulting scheduling whilst atomic, close this second corner by using schedule_work() to ensure the reenable is not done in atomic context. Note that drivers must be careful to manage the interaction of set_state() and reenable() callbacks to ensure appropriate reference counting if they are relying on the same hardware controls. Deliberately taking this the slow path rather than via a fixes tree because the error has hard to hit and I would like it to soak for a while before hitting a release kernel. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211017172209.112387-1-jic23@kernel.org
-
Cosmin Tanislav authored
The AD74412R and AD74413R are quad-channel, software configurable, input/output solutions for building and process control applications. They contain functionality for analog output, analog input, digital input, resistance temperature detector, and thermocouple measurements integrated into a single chip solution with an SPI interface. The devices feature a 16-bit ADC and four configurable 13-bit DACs to provide four configurable input/output channels and a suite of diagnostic functions. The AD74413R differentiates itself from the AD74412R by being HART-compatible. When configured with channel 0 as voltage output, channel 1 as current output, channel 2 as voltage input and channel 3 as current input, the following structure is created under the corresponding IIO device. . ├── in_current0_offset ├── in_current0_raw ├── in_current0_sampling_frequency ├── in_current0_sampling_frequency_available ├── in_current0_scale ├── in_voltage1_offset ├── in_voltage1_raw ├── in_voltage1_sampling_frequency ├── in_voltage1_sampling_frequency_available ├── in_voltage1_scale ├── in_voltage2_offset ├── in_voltage2_raw ├── in_voltage2_sampling_frequency ├── in_voltage2_sampling_frequency_available ├── in_voltage2_scale ├── in_current3_offset ├── in_current3_raw ├── in_current3_sampling_frequency ├── in_current3_sampling_frequency_available ├── in_current3_scale ├── out_voltage0_raw ├── out_voltage0_scale ├── out_current1_raw ├── out_current1_scale ├── name ├── buffer │ ├── data_available │ ├── enable │ ├── length │ └── watermark └── scan_elements ├── in_current0_en ├── in_current0_index ├── in_current0_type ├── in_voltage1_en ├── in_voltage1_index ├── in_voltage1_type ├── in_voltage2_en ├── in_voltage2_index ├── in_voltage2_type ├── in_current3_en ├── in_current3_index └── in_current3_type Signed-off-by:
-
Cosmin Tanislav authored
The AD74412R and AD74413R are quad-channel, software configurable, input/output solutions for building and process control applications. They contain functionality for analog output, analog input, digital input, resistance temperature detector, and thermocouple measurements integrated into a single chip solution with an SPI interface. The devices feature a 16-bit ADC and four configurable 13-bit DACs to provide four configurable input/output channels and a suite of diagnostic functions. The AD74413R differentiates itself from the AD74412R by being HART-compatible. Signed-off-by:
-
Cosmin Tanislav authored
For IIO devices that expose both ADC and DAC functionality. Signed-off-by:
-
Cai Huoqing authored
Update my email address to use developer mail address, because the old address will be dropped soon. And change the status from 'Supported' to 'Maintained' for me to look after this code without any payment now. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20211201083100.1587-1-caihuoqing@baidu.comSigned-off-by:
-
Antoniu Miclaus authored
Add device tree bindings for the AD7293 Power Amplifier. Signed-off-by:
-
- 04 Dec, 2021 5 commits
-
-
Antoniu Miclaus authored
The AD7293 is a Power Amplifier drain current controller containing functionality for general-purpose monitoring and control of current, voltage, and temperature, integrated into a single chip solution with an SPI-compatible interface. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/AD7293.pdfSigned-off-by:
Cai Huoqing <cai.huoqing@linux.dev> Link: https://lore.kernel.org/r/20211202150819.24832-1-antoniu.miclaus@analog.comSigned-off-by:
-
Nikita Travkin authored
Userspace tools like iio-sensor-proxy need to know the proximity level that should be considered "near". This value is hardware-specific and can be defined via the devicetree. Allow the driver to export the near level. Signed-off-by:
Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20211125125646.54831-2-nikita@trvn.ruSigned-off-by:
-
Nikita Travkin authored
This value inidcates the proximity level that should be considered "close". Signed-off-by:
-
Evgeny Boger authored
Most AXPxxx-based reference designs place a 10k NTC thermistor on a TS pin. axp20x IIO driver now report the voltage of this pin via additional IIO channel. Add new "ts_v" channel to the channel description. Signed-off-by:
Evgeny Boger <boger@wirenboard.com> Acked-by:
Quentin Schulz <foss+kernel@0leil.net> Link: https://lore.kernel.org/r/20211118141233.247907-3-boger@wirenboard.comSigned-off-by:
-
Evgeny Boger authored
Most AXPxxx-based reference designs place a 10k NTC thermistor on a TS pin. When appropriately configured, AXP PMICs will inject fixed current (80uA by default) into TS pin and measure the voltage across a thermistor. The PMIC itself will by default compare this voltage with predefined thresholds and disable battery charging whenever the battery is too hot or too cold. Alternatively, the TS pin can be configured as general-purpose ADC input. This mode is not supported by the driver. This patch allows reading the voltage on the TS pin. It can be then either processed by userspace or used by kernel consumer like hwmon ntc thermistor driver. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
-
