Jonathan Cameron [Thu, 10 Sep 2020 17:32:34 +0000 (18:32 +0100)]
iio:humidity:hdc100x: Drop of_match_ptr protection.
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:30 +0000 (18:32 +0100)]
iio:chemical:sgp30: Use local variable dev to simplify code
This cleans up the code at bit, but is primarily here as a precusor
to the next patch. I've only done this for the two functions
which use the dev pointer repeatedly.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:29 +0000 (18:32 +0100)]
iio:chemical:atlas-sensor: Drop of_match_ptr and use generic fw accessors
of_match_ptr() prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver and use generic fw accessors to check
if there is a fw_node and get the id.
It might be neater to use pointers rather than indexes for
the device_data but that is another issue and should be handled
separately.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:28 +0000 (18:32 +0100)]
iio:chemical:ams-iaq-core: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:27 +0000 (18:32 +0100)]
iio:resolver:ad2s1200: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:26 +0000 (18:32 +0100)]
iio:temperature:tmp007: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:25 +0000 (18:32 +0100)]
iio:temperature:tsys01: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:24 +0000 (18:32 +0100)]
iio:pressure:zpa2326: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:23 +0000 (18:32 +0100)]
iio:pressure:ms5637: Drop of_match_ptr protection
This prevents use of this driver with ACPI via PRP0001 and is
an example of an anti pattern I'm trying to remove from IIO.
Hence drop from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:22 +0000 (18:32 +0100)]
iio:pressure:ms5611: Drop of_match_ptr and CONFIG_OF protections
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:21 +0000 (18:32 +0100)]
iio:pressure:icp10100: Drop of_match_ptr and CONFIG_OF protections
These prevents use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:19 +0000 (18:32 +0100)]
iio:dac:ti-dac5571: Drop of_match_ptr and CONFIG_OF protections
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:18 +0000 (18:32 +0100)]
iio:dac:ti-dac082s085: Drop of_match_ptr and CONFIG_OF protections
These prevent the use of this driver with ACPI via PRP0001 and are
an example of an anti pattern I'm trying to remove from IIO.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:17 +0000 (18:32 +0100)]
iio:dac:mcp4725: drop of_match_ptr and use generic fw properties
This enables use of ACPI PRP0001 and removes an antipattern I am
trying to stop people copying in IIO.
This particular case is more complex than most because it allowed
probing via sysfs with out a fwnode but would presumably always
have then failed. Now the code will assume that properties are
the defaults if not specified or the firmware node is not present.
This relaxation of the constraints should not break any existing
cases and may enable some new ones.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:15 +0000 (18:32 +0100)]
iio:dac:ad5593r: Drop of_match_ptr and ACPI_PTR protections.
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20200910173242.621168-12-jic23@kernel.org
Jonathan Cameron [Thu, 10 Sep 2020 17:32:14 +0000 (18:32 +0100)]
iio:dac:ad5592r: Drop of_match_ptr and ACPI_PTR protections.
These result in a very small reduction in driver size, but at the
cost of more complex build and slightly harder to read code.
In the case of of_match_ptr it also prevents use of PRP0001
ACPI based identification. In this particular case we have
a valid ACPI/PNP ID that I am assuming was issued by Analog
Devices. That should be used in preference to PRP0001 but doesn't
mean we should prevent that route.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20200910173242.621168-11-jic23@kernel.org
Jonathan Cameron [Thu, 10 Sep 2020 17:32:13 +0000 (18:32 +0100)]
iio:dac:ad5446: Drop of_match_ptr and CONFIG_OF protections
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.
Hence drop them from this driver.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:12 +0000 (18:32 +0100)]
iio:potentiometer:mcp4531: Drop of_match_ptr and CONFIG_OF protections.
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.
Hence drop them from this driver.
Also switch to device_get_match_data() from of_ variant and adjust
headers to reflect the change.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:11 +0000 (18:32 +0100)]
iio:potentiometer:mcp4131: Drop of_match_ptr and use generic fw interfaces.
This change allows the use of the driver with ACPI via PRP0001
and remove an example of an anti pattern I'm trying to remove from IIO.
Also adjust includes to reflect this change.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:10 +0000 (18:32 +0100)]
iio:potentiometer:mcp4018: Drop of_match_ptr and CONFIG_OF protections.
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.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:08 +0000 (18:32 +0100)]
iio:potentiometer:max5481: Drop of_match_ptr and CONFIG_OF protections.
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 <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Maury Anderson <maury.anderson@rockwellcollins.com> Cc: Matthew Weber <matthew.weber@rockwellcollins.com> Cc: Slawomir Stepien <sst@poczta.fm> Link: https://lore.kernel.org/r/20200910173242.621168-5-jic23@kernel.org
Jonathan Cameron [Thu, 10 Sep 2020 17:32:07 +0000 (18:32 +0100)]
iio:potentiometer:max5432: Drop of_match_ptr and use generic fw accessors
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.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:06 +0000 (18:32 +0100)]
iio:potentiometer:ds1803: Drop of_match_ptr and CONFIG_OF protections
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.
Jonathan Cameron [Thu, 10 Sep 2020 17:32:05 +0000 (18:32 +0100)]
iio:potentiometer:ad5272: Drop of_match_ptr and CONFIG_OF protections.
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.
Jonathan Cameron [Sun, 13 Sep 2020 13:21:13 +0000 (14:21 +0100)]
iio:imu:adis16400: Sort out missing kernel doc.
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'
Alexandru Ardelean [Thu, 17 Sep 2020 12:59:51 +0000 (15:59 +0300)]
iio: buffer: split buffer sysfs creation to take buffer as primary arg
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.
Martin Blumenstingl [Tue, 15 Sep 2020 19:26:21 +0000 (21:26 +0200)]
iio: adc: meson-saradc: Make the of_device_id array style consistent
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.
Jonathan Cameron [Sat, 5 Sep 2020 17:47:20 +0000 (18:47 +0100)]
staging:iio:light: drop stale ABI docs
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.
Jonathan Cameron [Sat, 5 Sep 2020 17:47:18 +0000 (18:47 +0100)]
staging:iio:dac:max517 remove documentation
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.
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.
staging: iio: adis16240: Use Managed device functions
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.
staging: iio: adis16203: Use Managed device functions
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.
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.
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.
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.
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.
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.
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.
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.
Krzysztof Kozlowski [Thu, 10 Sep 2020 16:19:33 +0000 (18:19 +0200)]
dt-bindings: iio: adc: exynos-adc: do not require syscon on S5Pv210
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.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Krzysztof Kozlowski [Thu, 10 Sep 2020 16:19:32 +0000 (18:19 +0200)]
dt-bindings: iio: adc: exynos-adc: require second interrupt with touch screen
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: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huwei.com> Link: https://lore.kernel.org/r/20200910161933.9156-1-krzk@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: David Lechner <david@lechnology.com> Cc: David Lechner <david@lechnology.com> Link: https://lore.kernel.org/r/20200830161154.3201-3-jic23@kernel.org
iio: frequency: adf4350: Replace indio_dev->mlock with own device lock
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.
iio: dac: ti-dac7612: Replace indio_dev->mlock with own device lock
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.
iio: stm32-dac: Replace indio_dev->mlock with own device lock
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.
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).
iio: gyro: adxrs290: use hook for devm resource unwinding
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.
Christian Eggers [Wed, 9 Sep 2020 15:44:39 +0000 (17:44 +0200)]
iio: light: as73211: Increase measurement timeout
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.
Crt Mori [Sun, 6 Sep 2020 21:02:31 +0000 (23:02 +0200)]
iio: temperature: mlx90632: Interface to change object ambient temperature
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.
Krzysztof Kozlowski [Thu, 3 Sep 2020 18:19:26 +0000 (20:19 +0200)]
MAINTAINERS: Move Hartmut Knaack to Credits
Hartmut Knaack was an active reviewer and contributor to the IIO
subsystem and drivers. However his last message on LKML is from
October 2015.
In thanks for Hartmut's effort, move him name to the Credits.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: linux-iio <linux-iio@vger.kernel.org> Link: https://lore.kernel.org/r/20200903181926.5606-2-krzk@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Krzysztof Kozlowski [Thu, 3 Sep 2020 18:19:25 +0000 (20:19 +0200)]
MAINTAINERS: Consolidate Analog Devices IIO entries and remove Beniamin Bia
Emails to Beniamin Bia bounce with no such address so remove him from
maintainers. After this removal, many entries for Analog Devices Inc
IIO drivers look exactly the same so consolidate them.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: linux-iio <linux-iio@vger.kernel.org> Link: https://lore.kernel.org/r/20200903181926.5606-1-krzk@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Douglas Anderson [Tue, 1 Sep 2020 15:19:43 +0000 (08:19 -0700)]
iio: sx9310: Prefer async probe
On one board I found that:
probe of 5-0028 returned 1 after 259547 usecs
While some of this time is attributable to the pile of i2c transfers
that we do at probe time, the lion's share (over 200 ms) is sitting
waiting in the polling loop in sx9310_init_compensation() waiting for
the hardware to indicate that it's done.
There's no reason to block probe of all other devices on our probe.
Turn on async probe.
Andy Shevchenko [Mon, 31 Aug 2020 09:08:10 +0000 (12:08 +0300)]
iio: accel: bma220: Drop ACPI_PTR() and accompanying ifdeffery
The driver is quite likely used only on ACPI based platforms and
rarely build with CONFIG_ACPI=n. Even though, the few dozens of bytes
is better than ugly ifdeffery and inclusion of heavy header.
As a result, replace acpi.h with mod_devicetable.h.
Drops the deprecated compatibles without the vendor name.
Whilst the driver continues to support these for old dt blobs,
any dt bindings that are actuallly verified against this document should
be fixed to add the vendor name.
Added the #io-channel-cells property to allow for consumers.
Alexandru Ardelean [Wed, 26 Aug 2020 05:20:11 +0000 (07:20 +0200)]
iio: buffer-dmaengine: adjust `bytes_used` with residue info
A transfer may fall shorter than the bytes in the block.
This information is available in the residue from the DMA engine, so we can
compute actual `bytes_used` with that by subtracting the residue.
Simple binding so easy to convert.
Dropped the stated value of maximum spi bus frequency as it does
not seem to correspond to the datasheet. The value of 200kHz
is the max sampling frequency of the ADC, not the clock frequency of
the SPI bus.
Added #io-channel-cells to allow use as a provider of channels to
other devices via the consumer binding.
Simple conversion for this ADC driver. Note that I haven't put
limits on the spi-max-sampling-frequency because the adc161s626
doesn't state one clearly defined value.
Added the #io-channel-cells property to allow for consumers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Cc: Matt Ranostay <matt.ranostay@konsulko.com> Link: https://lore.kernel.org/r/20200809111753.156236-6-jic23@kernel.org
Jonathan Cameron [Sun, 9 Aug 2020 11:17:42 +0000 (12:17 +0100)]
dt-bindings: trivial-devices: Add mcp342x ADCs and drop separate binding doc.
These i2c devices have simple bindings, well described by trivial-device.yaml
so rather than convert the binding doc to yaml, let us just add them to
trivial devices and drop the old binding document.
Stefan Popa [Mon, 10 Aug 2020 09:32:56 +0000 (12:32 +0300)]
iio: accel: adxl372: Add support for FIFO peak mode
By default, if all three channels (x, y, z) are enabled, sample sets of
concurrent 3-axis data is stored in the FIFO. This patch adds the option
to configure the FIFO to store peak acceleration (x, y and z) of every
over-threshold event. When pushing to iio buffer we push only enabled
axis data.
Currently the driver configures adxl372 to work in loop mode.
The inactivity and activity timings decide how fast the chip
will loop through the awake and waiting states and the
thresholds on x,y,z axis decide when activity or inactivity
will be detected.
This patch adds standard events sysfs entries for the inactivity
and activity timings: thresh_falling_period/thresh_rising_period
and for the in_accel_x_thresh_falling/rising_value.
Crt Mori [Tue, 18 Aug 2020 21:37:37 +0000 (23:37 +0200)]
iio:temperature:mlx90632: Some stylefixing leftovers
There is some inconsistency and whitespace cleanup performed in this
patch. It was done on top of my other patches, but I can rebase to head
of the togreg branch if it would go in sooner.
For some time the market wants medical grade accuracy in medical range,
while still retaining the declared accuracy outside of the medical range
within the same sensor. That is why we created extended calibration
which is automatically switched to when object temperature is too high.
This patch also introduces the object_ambient_temperature variable which
is needed for more accurate calculation of the object infra-red
footprint as sensor's ambient temperature might be totally different
than what the ambient temperature is at object and that is why we can
have some more errors which can be eliminated. Currently this temperature
is fixed at 25, but the interface to adjust it by user (with external
sensor or just IR measurement of the other object which acts as ambient),
will be introduced in another commit.
Crt Mori [Tue, 18 Aug 2020 21:37:33 +0000 (23:37 +0200)]
iio:temperature:mlx90632: Reduce number of equal calulcations
TAdut4 was calculated each iteration although it did not change. In light
of near future additions of the Extended range DSP calculations, this
function refactoring will help reduce unrelated changes in that series as
well as reduce the number of new functions needed.
Krzysztof Kozlowski [Sat, 29 Aug 2020 06:47:26 +0000 (08:47 +0200)]
iio: multiplexer: iio-mux: Simplify with dev_err_probe()
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20200829064726.26268-18-krzk@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
projects / users / jedix / linux-maple.git / log