- 16 Dec, 2021 2 commits
-
-
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:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
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:
Lars-Peter Clausen <lars@metafoo.de> 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:
Rob Herring <robh@kernel.org>
-
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 <cosmin.tanislav@analog.com> Reviewed-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:
Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by:
-
- 04 Dec, 2021 7 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:
-
Lorenzo Bianconi authored
Enable/disable internal i2c controller slave autoprobing at bootstrap. Disable sensor-hub is useful if i2c controller clock/data lines are connected through a pull-up with other chip lines (e.g. SDO/SA0). Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
-
Lorenzo Bianconi authored
Introduce the capability to disable sensorhub through a device-tree property since there are some configurations where users want to explicitly disable sensor-hub auto-probing at bootstrap. A typical configuration is when the sensorhub clock/data lines are connected to a pull-up resistor since no slave sensors are connected to the i2c master. If SDO/SA0 line is connected to the same pull-up resistor, when the driver tries to probe slave devices connected on sensor-hub, it will force SDO/SA0 line to low, modifying the device i2c address. Tested-by:
Mario Tesi <mario.tesi@st.com> Signed-off-by:
-
- 27 Nov, 2021 5 commits
-
-
Andriy Tryshnivskyy authored
Add test for newly introduced type IIO_VAL_INT_64. Signed-off-by:
Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Andriy Tryshnivskyy authored
Add KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf) for every test. Also use ARRAY_SIZE(values) where it is possible. Signed-off-by:
-
Antoniu Miclaus authored
The shared parameter should be configurable based on its usage, and not constrained to IIO_SHARED_BY_TYPE. This patch aims to improve the flexibility in using the IIO_ENUM_AVAILABLE define and avoid redefining custom iio enums that expose the shared parameter. An example is the ad5766.c driver where IIO_ENUM_AVAILABLE_SHARED was defined in order to achieve `shared` parameter customization. The current state of the IIO_ENUM_AVAILABLE implementation will imply similar redefinitions each time a driver will require access to the `shared` parameter. An example would be admv1013 driver which will require custom device attribute for the frequency translation modes: Quadrature I/Q mode and Intermediate Frequency mode. Signed-off-by:
Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20211119085627.6348-1-antoniu.miclaus@analog.comSigned-off-by:
-
Paul Cercueil authored
We know that the buffer's alignment will always be a power of two; therefore, we can use the faster round_down() macro. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
-
Paul Cercueil authored
This structure was never used anywhere, so it can safely be dropped. It will later be re-introduced as a different structure in a different header. Signed-off-by:
-
- 20 Nov, 2021 1 commit
-
-
Andy Shevchenko authored
Use dedicated variable for index in the loop in the iio_buffers_alloc_sysfs_and_mask(). This will make code cleaner and less error prone as proved by previous changes done in this function. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211013094923.2473-3-andriy.shevchenko@linux.intel.comSigned-off-by:
-
- 17 Nov, 2021 6 commits
-
-
Maslov Dmitry authored
Previously ltr501 driver supported a number of light and, proximity sensors including ltr501, ltr559 and ltr301. This adds support for another light sensor ltr303 used in Seeed Studio reTerminal, a carrier board for Raspberry Pi 4 CM. Signed-off-by:
Maslov Dmitry <maslovdmitry@seeed.cc> Link: https://lore.kernel.org/r/20211106174137.6783-1-maslovdmitry@seeed.ccSigned-off-by:
-
Xu Wang authored
The print function dev_err() is redundant because platform_get_irq() already prints an error. Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20211105015504.39226-1-vulab@iscas.ac.cnSigned-off-by:
-
Gwendal Grignou authored
When processing raw data using channel scan_type.shift as source of trust to shift data appropriately. When processing the temperature channel, use a 16bit big endian variable as buffer to increase conversion readability. Signed-off-by:
Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20211104082413.3681212-14-gwendal@chromium.orgSigned-off-by:
-
Gwendal Grignou authored
Minor cleanup: bit is already defined as chan->scan_type.realbits, use bit when needed. Signed-off-by:
-
Gwendal Grignou authored
By using scan_type.realbits when processing raw data, we use scan_type.shit only once, thus we don't need to define a local variable for it anymore. Signed-off-by:
-
Gwendal Grignou authored
Use channel definition as root of trust and replace constant when reading elements directly using the raw sysfs attributes. Signed-off-by:
-
