- 21 Sep, 2020 4 commits
-
-
Jonathan Cameron authored
These prevent use of this driver with ACPI via PRP0001 and are an example of an anti pattern I'm trying to remove from IIO. Also use device_get_match_data() rather than devicetree only version. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20200910173242.621168-7-jic23@kernel.org
-
Jonathan Cameron authored
Given that an ACPI binding must start with 3 or 4 capitals, this cannot represent a valid binding. It seems unlikely anything out there is using it. Signed-off-by:
-
Jonathan Cameron authored
These prevent use of this driver with ACPI via PRP0001 and are an example of an anti pattern I'm trying to remove from IIO. Whilst this driver has an ACPI binding, it is not of a form that is valid under ACPI so will be dropped shortly. Also switch to device_get_match_data() and switch headers. Signed-off-by:
-
Jonathan Cameron authored
These prevent use of this driver with ACPI via PRP0001 and are an example of an anti pattern I'm trying to remove from IIO. Drop them to remove this restriction. Also switch headers to reflect this change. Signed-off-by:
Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20200910173242.621168-4-jic23@kernel.org
-
- 17 Sep, 2020 4 commits
-
-
Jonathan Cameron authored
These prevent use of this driver with ACPI via PRP0001 and are an example of an anti pattern I'm trying to remove from IIO. Drop them to remove this restriction. Also switch of.h for mod_devicetable.h include given use of struct of_device_id which is defined in that header. Signed-off-by:
-
Jonathan Cameron authored
These prevent use of this driver with ACPI via PRP0001 and are an example of an anti pattern I'm trying to remove from IIO. Drop them to remove this restriction. Also added mod_devicetable.h include given use of struct of_device_id which is defined in that header. Signed-off-by:
-
Jonathan Cameron authored
I'd like to be enable W=1 for all IIO builds as it catches real issues as well as more minor documentation issues such as this (also good to fix though!) drivers/iio/imu/adis16400.c:183: warning: Function parameter or member 'avail_scan_mask' not described in 'adis16400_state' Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200913132115.800131-2-jic23@kernel.org
-
Alexandru Ardelean authored
Currently the iio_buffer_{alloc,free}_sysfs_and_mask() take 'indio_dev' as primary argument. This change splits the main logic into a private function that takes an IIO buffer as primary argument. That way, the functions can be extended to configure the sysfs for multiple buffers. Signed-off-by:
-
- 16 Sep, 2020 25 commits
-
-
Martin Blumenstingl authored
Use only one line for the closing bracket of the last entry and the opening bracket for the next one to keep the style across the whole array consistent. Also add a "sentinel" comment to the last entry and remove the comma to ensure that there won't be any entry after it. No functional changes. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200915192621.13202-1-martin.blumenstingl@googlemail.comSigned-off-by:
-
Alexandru Ardelean authored
The proper error code should be ENODEV (vs EINVAL) in case the chip ID isn't recognized. Signed-off-by:
-
Alexandru Ardelean authored
We should probably print what the expected chip-ID is. We already have that information available, based on the device specified via device-tree. Signed-off-by:
-
Jonathan Cameron authored
These docs are both suffering from being out of date, and from being superceeded by the documentation in Documentation/driver-api/iio Note the inkern.txt drop is left for now as this is an area not well covered by the more recent documentation outside staging. Signed-off-by:
-
Jonathan Cameron authored
There are no remaining light drivers in staging/iio. The content of this file are either included in the non staging ABI docs, or don't seem to be used in any current driver. Signed-off-by:
-
Jonathan Cameron authored
These seem to be up to date but never moved out of staging when the driver did. Hence let us move them out now. Signed-off-by:
Brian Masney <masneyb@onstation.org> Cc: Brian Masney <masneyb@onstation.org> Link: https://lore.kernel.org/r/20200905174721.216452-3-jic23@kernel.org
-
Jonathan Cameron authored
Whilst there is some useful info in here, it can be easily obtained from datasheets. Some of the info should perhaps be incorporated into a device tree bindings doc. As this didn't move out of staging with the driver, I'm suggesting we just drop it. We don't generally carry per driver documentation with the exception of non standard ABI which is not the case here. Signed-off-by:
-
Liu Shixin authored
module_platform_driver() makes the code simpler by eliminating boilerplate code. Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Link: https://lore.kernel.org/r/20200914065401.3726354-1-liushixin2@huawei.comSigned-off-by:
-
Nuno Sá authored
Drop `adis_setup_buffer_and_trigger()`. All users were updated to use the devm version of this function. This avoids having almost the same code repeated. Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20200915120258.161587-11-nuno.sa@analog.comSigned-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Nuno Sá authored
Use the adis managed device functions to setup the buffer and the trigger. The ultimate goal will be to completely drop the non devm version from the lib. Since we are here, drop the `.remove` callback by further using devm functions. Signed-off-by:
-
Krzysztof Kozlowski authored
The ADC in S5Pv210 does not have ADC phy registers in separate block for which syscon would be needed. Remove this requirement to fix dtbs_check warnings like: arch/arm/boot/dts/s5pv210-fascinate4g.dt.yaml: adc@e1700000: 'samsung,syscon-phandle' is a required property Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Jonathan Cameron <Jonathan.Cameron@huwei.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200910161933.9156-2-krzk@kernel.orgSigned-off-by:
-
Krzysztof Kozlowski authored
The ADC in S3C/S5P/Exynos SoCs can be used also for handling touch screen. In such case the second interrupt is required. This second interrupt can be anyway provided, even without touch screens. This fixes dtbs_check warnings like: arch/arm/boot/dts/s5pv210-aquila.dt.yaml: adc@e1700000: interrupts: [[23], [24]] is too long Signed-off-by:
-
Jonathan Cameron authored
Conversion from txt to yaml. The binding documents that as not all boards will make use of the ADC channels via a consumer driver. It does no harm however, so we will leave it as required. Signed-off-by:
David Lechner <david@lechnology.com> Cc: David Lechner <david@lechnology.com> Link: https://lore.kernel.org/r/20200830161154.3201-3-jic23@kernel.org
-
Jonathan Cameron authored
Simple binding conversion from txt to yaml. Only addition was #io-channel-cells to allow for potential consumers of the channels on this device. Signed-off-by:
-
Sergiu Cuciurean authored
As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock. The lock protect the state of the device from potential concurrent writes. The device is configured via a sequence of SPI writes, and this lock is meant to prevent the start of another sequence before another one has finished. This is part of a bigger cleanup. Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/Signed-off-by:
Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by:
-
Sergiu Cuciurean authored
As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock on the device's state from potential concurrent write accesses from userspace. The write operation requires an SPI write, then toggling of a GPIO, so the lock aims to protect the sanity of the entire sequence of operation. This is part of a bigger cleanup. Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/Signed-off-by:
-
Sergiu Cuciurean authored
As part of the general cleanup of indio_dev->mlock, this change replaces it with a local lock. The lock protects against potential races when reading the CR reg and then updating, so that the state of pm_runtime is consistent between the two operations. This is part of a bigger cleanup. Link: https://lore.kernel.org/linux-iio/CA+U=Dsoo6YABe5ODLp+eFNPGFDjk5ZeQEceGkqjxXcVEhLWubw@mail.gmail.com/Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Link: https://lore.kernel.org/r/20200916092349.75647-1-alexandru.ardelean@analog.comSigned-off-by:
-
- 13 Sep, 2020 7 commits
-
-
Nishant Malpani authored
Extend support to read/write byte data from/to the device using debugfs iio interface. Signed-off-by:
Nishant Malpani <nish.malpani25@gmail.com> Reviewed-by:
-
Nishant Malpani authored
Include 'interrupts' property and provide a suitable example for using a GPIO interrupt line. Signed-off-by:
-
Nishant Malpani authored
Provide a way for continuous data capture by setting up buffer support. The data ready signal exposed at the SYNC pin of the ADXRS290 is exploited as a hardware interrupt which triggers to fill the buffer. Triggered buffer setup was tested with both hardware trigger (DATA_RDY) and software triggers (sysfs-trig & hrtimer). Signed-off-by:
-
Nishant Malpani authored
Make use of devm_add_action_or_reset() hook to switch device into STANDBY mode during standard resource unwinding. The patch includes a helper function, in the form of adxrs290_set_mode(), to realise driving the device into STANDBY mode. Signed-off-by:
-
Krzysztof Kozlowski authored
Conversion of error paths to dev_err_probe() dropped one return statement. The driver will continue to probe if getting booster regulator fails. Fixes: ce30eeb6 ("iio: adc: stm32: Simplify with dev_err_probe()") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Christian Eggers authored
We found some sensors which are much slower (20% at room temperature) than nominal. According to the data sheet, up to 27% is possible. Now I add 33% to the nominal time out, hopefully this is enough. Signed-off-by:
Christian Eggers <ceggers@arri.de> Link: https://lore.kernel.org/r/20200909154439.10308-1-ceggers@arri.de Fixes: 403e5586 ("iio: light: as73211: New driver") Signed-off-by:
-
Crt Mori authored
Since object temperature might be different than the sensor temperature the infrared sensors should provide an interface to inject ambient temperature. This was in past done via write to ambient temperature interface (in_temp_ambient_raw), but I think most people did not know about it. This solution introduces a new iio type of the CALIBAMBIENT which is hopefully more descriptive and more explicit about the purpose and capabilities of the sensors. Signed-off-by:
Crt Mori <cmo@melexis.com> Reviewed-by:
-
