iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one device as the frontend device which
can be "linked" against one or multiple backend devices. All the IIO and
userspace interface is expected to be registers/managed by the frontend
device which will callback into the backends when needed (to get/set
some configuration that it does not directly control).

The basic framework interface is pretty simple:
- Backends should register themselves with @devm_iio_backend_register()
- Frontend devices should get backends with @devm_iio_backend_get()

Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one device as the frontend device which
can be "linked" against one or multiple backend devices. All the IIO and
userspace interface is expected to be registers/managed by the frontend
device which will callback into the backends when needed (to get/set
some configuration that it does not directly control).

The basic framework interface is pretty simple:
- Backends should register themselves with @devm_iio_backend_register()
- Frontend devices should get backends with @devm_iio_backend_get()

Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one device as the frontend device which
can be "linked" against one or multiple backend devices. All the IIO and
userspace interface is expected to be registers/managed by the frontend
device which will callback into the backends when needed (to get/set
some configuration that it does not directly control).

The basic framework interface is pretty simple:
- Backends should register themselves with @devm_iio_backend_register()
- Frontend devices should get backends with @devm_iio_backend_get()

Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one device as the frontend device which
can be "linked" against one or multiple backend devices. All the IIO and
userspace interface is expected to be registers/managed by the frontend
device which will callback into the backends when needed (to get/set
some configuration that it does not directly control).

The basic framework interface is pretty simple:
- Backends should register themselves with @devm_iio_backend_register()
- Frontend devices should get backends with @devm_iio_backend_get()

Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one device as the frontend device which
can be "linked" against one or multiple backend devices. All the IIO and
userspace interface is expected to be registers/managed by the frontend
device which will callback into the backends when needed (to get/set
some configuration that it does not directly control).

The basic framework interface is pretty simple:
- Backends should register themselves with @devm_iio_backend_register()
- Frontend devices should get backends with @devm_iio_backend_get()

Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one device as the frontend device which
can be "linked" against one or multiple backend devices. All the IIO and
userspace interface is expected to be registers/managed by the frontend
device which will callback into the backends when needed (to get/set
some configuration that it does not directly control).

The basic framework interface is pretty simple:
- Backends should register themselves with @devm_iio_backend_register()
- Frontend devices should get backends with @devm_iio_backend_get()

Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one

iio: add the IIO backend framework

[ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]

This is a Framework to handle complex IIO aggregate devices.

The typical architecture is to have one device as the frontend device which
can be "linked" against one or multiple backend devices. All the IIO and
userspace interface is expected to be registers/managed by the frontend
device which will callback into the backends when needed (to get/set
some configuration that it does not directly control).

The basic framework interface is pretty simple:
- Backends should register themselves with @devm_iio_backend_register()
- Frontend devices should get backends with @devm_iio_backend_get()

Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

iio: light: Add gain-time-scale helpers

Some light sensors can adjust both the HW-gain and integration time.
There are cases where adjusting the integration time has similar impact
to the scale of t

iio: light: Add gain-time-scale helpers

Some light sensors can adjust both the HW-gain and integration time.
There are cases where adjusting the integration time has similar impact
to the scale of the reported values as gain setting has.

IIO users do typically expect to handle scale by a single writable 'scale'
entry. Driver should then adjust the gain/time accordingly.

It however is difficult for a driver to know whether it should change
gain or integration time to meet the requested scale. Usually it is
preferred to have longer integration time which usually improves
accuracy, but there may be use-cases where long measurement times can be
an issue. Thus it can be preferable to allow also changing the
integration time - but mitigate the scale impact by also changing the gain
underneath. Eg, if integration time change doubles the measured values,
the driver can reduce the HW-gain to half.

The theory of the computations of gain-time-scale is simple. However,
some people (undersigned) got that implemented wrong for more than once.

Add some gain-time-scale helpers in order to not dublicate errors in all
drivers needing these computations.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/268d418e7cffcdaa2ece6738478bbc57692c213e.1680263956.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: add filter subfolder

Add filter subfolder for IIO devices that handle filter functionality.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonatha

iio: add filter subfolder

Add filter subfolder for IIO devices that handle filter functionality.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: add addac subdirectory

For IIO devices that expose both ADC and DAC functionality.

Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20211205114045.17

iio: add addac subdirectory

For IIO devices that expose both ADC and DAC functionality.

Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20211205114045.173612-2-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio:cdc:ad7150: Move driver out of staging.

This capacitance to digital converter (CDC) driver is compliant with
the IIO ABI. Note, not all features supported (e.g. window event modes)
but the driv

iio:cdc:ad7150: Move driver out of staging.

This capacitance to digital converter (CDC) driver is compliant with
the IIO ABI. Note, not all features supported (e.g. window event modes)
but the driver should be in a useful functional state.

The cleanup was done against QEMU emulation of the device rather than
actual hardware. Whilst this was a bit of an experiment, it made it
easy to confirm that the driver remained in a consistent working state
through the various refactors. If it worked in the first place, it
should still be working after this cleanup.

Given some IIO drivers require expensive hardware setups, (not particularly
true with this one) the use of QEMU may provide a viable way forward
for providing testing during code changes where previously we'd had
to rely on sharp eyes and crossed fingers.

Note, no explicit MAINTAINERS entry as it will be covered by the
generic catch-alls for ADI and IIO drivers which are sufficient.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210314181511.531414-25-jic23@kernel.org

show more ...

iio: Add basic unit test for iio_format_value()

The IIO core provides a function to do formatting of fixedpoint numbers.

In the past there have been some issues with the implementation of the
funct

iio: Add basic unit test for iio_format_value()

The IIO core provides a function to do formatting of fixedpoint numbers.

In the past there have been some issues with the implementation of the
function where for example negative numbers were not handled correctly.

Introduce a basic unit test based on kunit that tests the function and
ensures that the generated output matches the expected output.

This gives us some confidence that future modifications to the function
implementation will not break ABI compatibility.

To run the unit tests follow the kunit documentation and add

CONFIG_IIO=y
CONFIG_IIO_TEST_FORMAT=y

to the .kunitconfig and run

> ./tools/testing/kunit/kunit.py run
Configuring KUnit Kernel ...
Building KUnit Kernel ...
Starting KUnit Kernel ...
============================================================
======== [PASSED] iio-format ========
[PASSED] iio_test_iio_format_value_integer
[PASSED] iio_test_iio_format_value_fixedpoint
[PASSED] iio_test_iio_format_value_fractional
[PASSED] iio_test_iio_format_value_fractional_log2
[PASSED] iio_test_iio_format_value_multiple
============================================================
Testing complete. 21 tests run. 0 failed. 0 crashed.
Elapsed time: 8.242s total, 0.001s configuring, 3.865s building, 0.000s running

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201215191743.2725-3-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: position: Add support for Azoteq IQS624/625 angle sensors

This patch adds support for the Azoteq IQS624 and IQS625 angular position
sensors, capable of reporting the angle of a rotating shaft d

iio: position: Add support for Azoteq IQS624/625 angle sensors

This patch adds support for the Azoteq IQS624 and IQS625 angular position
sensors, capable of reporting the angle of a rotating shaft down to 1 and
10 degrees of accuracy, respectively.

This patch also introduces a home for linear and angular position sensors.
Unlike resolvers, they are typically contactless and use the Hall effect.

Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...

counter: stm32-lptimer: add counter device

Add support for new counter device to stm32-lptimer.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Jonathan Cameron <Jonathan.Camer

counter: stm32-lptimer: add counter device

Add support for new counter device to stm32-lptimer.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

staging: iio: ad2s1200: Move driver out of staging

Move the iio driver for the ad2s1200 and ad2s1205 resolver-to-digital
converter out of staging, into mainline iio subsystems.

Signed-off-by: David

staging: iio: ad2s1200: Move driver out of staging

Move the iio driver for the ad2s1200 and ad2s1205 resolver-to-digital
converter out of staging, into mainline iio subsystems.

Signed-off-by: David Veenstra <davidjulianveenstra@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

iio: afe: rescale: new driver

If an ADC channel measures the midpoint of a voltage divider, the
interesting voltage is often the voltage over the full resistance.
E.g. if the full voltage is too big

iio: afe: rescale: new driver

If an ADC channel measures the midpoint of a voltage divider, the
interesting voltage is often the voltage over the full resistance.
E.g. if the full voltage is too big for the ADC to handle.
Likewise, if an ADC channel measures the voltage across a shunt
resistor, with or without amplification, the interesting value is
often the current through the resistor.

This driver solves these problems by allowing to linearly scale a channel
and/or by allowing changes to the type of the channel.

Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

iio: multiplexer: new iio category and iio-mux driver

When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
to create one

iio: multiplexer: new iio category and iio-mux driver

When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
to create one virtual iio channel for each multiplexer state.

Depends on the generic multiplexer subsystem.

Cache any ext_info values from the parent iio channel, creating a private
copy of the ext_info attributes for each multiplexer state/channel.

Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8

The ACCES 104-QUAD-8 is a general purpose quadrature encoder
counter/interface board. The 104-QUAD-8 is capable of monitoring the
outputs of

iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8

The ACCES 104-QUAD-8 is a general purpose quadrature encoder
counter/interface board. The 104-QUAD-8 is capable of monitoring the
outputs of eight encoders via four on-board LSI/CSI LS7266R1 24-bit
dual-axis quadrature counter chips. Core functions handled by the
LS7266R1, such as direction and total count, are available.

Performing a write to a counter's IIO_CHAN_INFO_RAW sets the counter and
also clears the counter's respective error flag. Although the counters
have a 25-bit range, only the lower 24 bits may be set, either directly
or via a counter's preset attribute. Interrupts are not supported by
this driver.

This driver adds IIO support for the ACCES 104-QUAD-8 and ACCES
104-QUAD-4. The base port addresses for the devices may be configured
via the base array module parameter.

Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

show more ...

iio: potentiostat: add LMP91000 support

Add support for the LMP91000 potentiostat which is used for chemical
sensing applications.

Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off

iio: potentiostat: add LMP91000 support

Add support for the LMP91000 potentiostat which is used for chemical
sensing applications.

Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

show more ...

iio: Add support for creating IIO devices via configfs

This is similar with support for creating triggers via configfs.
Devices will be hosted under:
* /config/iio/devices

We allow users to regist

iio: Add support for creating IIO devices via configfs

This is similar with support for creating triggers via configfs.
Devices will be hosted under:
* /config/iio/devices

We allow users to register "device types" under:
* /config/iio/devices/<device_types>/

Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

show more ...

iio: light: add MAX30100 oximeter driver support

MAX30100 is an heart rate and pulse oximeter sensor that works using
two LEDS of different wavelengths, and detecting the light reflected
back.

This

iio: light: add MAX30100 oximeter driver support

MAX30100 is an heart rate and pulse oximeter sensor that works using
two LEDS of different wavelengths, and detecting the light reflected
back.

This patchset adds support for both IR and RED LED channels which can
be processed in userspace to determine heart rate and blood oxygen
levels.

Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

show more ...

iio: core: Introduce IIO software triggers

A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for ha

iio: core: Introduce IIO software triggers

A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.

Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.

Software triggers can be created directly from drivers or from user
space via configfs interface.

To sum up, this dynamically creates "triggers" group to be found under
/config/iio/triggers and offers the possibility of dynamically
creating trigger types groups. The first supported trigger type is
"hrtimer" found under /config/iio/triggers/hrtimer.

Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

show more ...

iio: core: Introduce IIO configfs support

This patch creates the IIO configfs root group. The group
will appear under <mount-point>/iio/, usually /config/iio.

We introduce configfs support in IIO i

iio: core: Introduce IIO configfs support

This patch creates the IIO configfs root group. The group
will appear under <mount-point>/iio/, usually /config/iio.

We introduce configfs support in IIO in order to be able to easily
create IIO objects from userspace. The first supported IIO objects
are triggers introduced with next patches.

Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Tested-by: Matt Ranostay <matt.ranostay@intel>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

show more ...

iio: Move IIO Dummy Driver out of staging

This patch moves the reference IIO dummy driver from drivers/staging/iio
into a separate folder, drivers/iio/dummy and adds the proper Kconfig
and Makefile

iio: Move IIO Dummy Driver out of staging

This patch moves the reference IIO dummy driver from drivers/staging/iio
into a separate folder, drivers/iio/dummy and adds the proper Kconfig
and Makefile for it.

A new config menu entry called IIO dummy driver has also been added
in the Industrial I/O support menu, corresponding to this driver.

Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

show more ...