<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/include/linux/iio, branch v6.8-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>iio: linux/iio.h: fix Excess kernel-doc description warning</title>
<updated>2023-12-26T16:02:46+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2023-12-23T05:05:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8645e659e2d227f6ce8fcea1ac640c324fbbb3e6'/>
<id>8645e659e2d227f6ce8fcea1ac640c324fbbb3e6</id>
<content type='text'>
Remove the @of_xlate: lines to prevent the kernel-doc warning:

include/linux/iio/iio.h:534: warning: Excess struct member 'of_xlate' description in 'iio_info'

Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Jonathan Cameron &lt;jic23@kernel.org&gt;
Cc: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: linux-iio@vger.kernel.org
Link: https://lore.kernel.org/r/20231223050556.13948-1-rdunlap@infradead.org
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove the @of_xlate: lines to prevent the kernel-doc warning:

include/linux/iio/iio.h:534: warning: Excess struct member 'of_xlate' description in 'iio_info'

Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Jonathan Cameron &lt;jic23@kernel.org&gt;
Cc: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: linux-iio@vger.kernel.org
Link: https://lore.kernel.org/r/20231223050556.13948-1-rdunlap@infradead.org
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: buffer-dma: Get rid of outgoing queue</title>
<updated>2023-12-21T11:28:47+00:00</updated>
<author>
<name>Paul Cercueil</name>
<email>paul@crapouillou.net</email>
</author>
<published>2023-12-19T17:50:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ee9ec49046951eff704752669f0c388b506ddbdf'/>
<id>ee9ec49046951eff704752669f0c388b506ddbdf</id>
<content type='text'>
The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.

While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much easier to
just check each block's state manually, and keep a counter for the next
block to dequeue.

Since the new DMABUF based API wouldn't use the outgoing queue anyway,
getting rid of it now makes the upcoming changes simpler.

With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
be removed.

Signed-off-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Link: https://lore.kernel.org/r/20231219175009.65482-2-paul@crapouillou.net
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.

While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much easier to
just check each block's state manually, and keep a counter for the next
block to dequeue.

Since the new DMABUF based API wouldn't use the outgoing queue anyway,
getting rid of it now makes the upcoming changes simpler.

With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
be removed.

Signed-off-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Link: https://lore.kernel.org/r/20231219175009.65482-2-paul@crapouillou.net
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: core: introduce trough info element for minimum values</title>
<updated>2023-12-11T19:37:10+00:00</updated>
<author>
<name>Javier Carrasco</name>
<email>javier.carrasco.cruz@gmail.com</email>
</author>
<published>2023-12-11T12:27:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5bc2ea60897e0f899fb93930dd867dae7c8eb11f'/>
<id>5bc2ea60897e0f899fb93930dd867dae7c8eb11f</id>
<content type='text'>
The IIO_CHAN_INFO_PEAK info element is used for maximum values and
currently there is no equivalent for minimum values. Instead of
overloading the existing peak info element, a new info element can
be added.

In principle there is no need to add a _TROUGH_SCALE element as the
scale will be the same as the one required for INFO_PEAK, which in
turn is sometimes omitted if a single scale for peaks and raw values
is required.

Add an IIO_CHAN_INFO_TROUGH info element for minimum values.

Signed-off-by: Javier Carrasco &lt;javier.carrasco.cruz@gmail.com&gt;
Link: https://lore.kernel.org/r/20231211122747.9723-1-579lpy@gmail.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The IIO_CHAN_INFO_PEAK info element is used for maximum values and
currently there is no equivalent for minimum values. Instead of
overloading the existing peak info element, a new info element can
be added.

In principle there is no need to add a _TROUGH_SCALE element as the
scale will be the same as the one required for INFO_PEAK, which in
turn is sometimes omitted if a single scale for peaks and raw values
is required.

Add an IIO_CHAN_INFO_TROUGH info element for minimum values.

Signed-off-by: Javier Carrasco &lt;javier.carrasco.cruz@gmail.com&gt;
Link: https://lore.kernel.org/r/20231211122747.9723-1-579lpy@gmail.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: adc: ad9467: fix scale setting</title>
<updated>2023-12-10T11:41:00+00:00</updated>
<author>
<name>Nuno Sa</name>
<email>nuno.sa@analog.com</email>
</author>
<published>2023-12-07T12:39:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b73f08bb7fe5a0901646ca5ceaa1e7a2d5ee6293'/>
<id>b73f08bb7fe5a0901646ca5ceaa1e7a2d5ee6293</id>
<content type='text'>
When reading in_voltage_scale we can get something like:

root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale
0.038146

However, when reading the available options:

root@analog:/sys/bus/iio/devices/iio:device2# cat
in_voltage_scale_available
2000.000000 2100.000006 2200.000007 2300.000008 2400.000009 2500.000010

which does not make sense. Moreover, when trying to set a new scale we
get an error because there's no call to __ad9467_get_scale() to give us
values as given when reading in_voltage_scale. Fix it by computing the
available scales during probe and properly pass the list when
.read_available() is called.

While at it, change to use .read_available() from iio_info. Also note
that to properly fix this, adi-axi-adc.c has to be changed accordingly.

Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
Signed-off-by: Nuno Sa &lt;nuno.sa@analog.com&gt;
Reviewed-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-4-a4a33bc4d70e@analog.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When reading in_voltage_scale we can get something like:

root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale
0.038146

However, when reading the available options:

root@analog:/sys/bus/iio/devices/iio:device2# cat
in_voltage_scale_available
2000.000000 2100.000006 2200.000007 2300.000008 2400.000009 2500.000010

which does not make sense. Moreover, when trying to set a new scale we
get an error because there's no call to __ad9467_get_scale() to give us
values as given when reading in_voltage_scale. Fix it by computing the
available scales during probe and properly pass the list when
.read_available() is called.

While at it, change to use .read_available() from iio_info. Also note
that to properly fix this, adi-axi-adc.c has to be changed accordingly.

Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
Signed-off-by: Nuno Sa &lt;nuno.sa@analog.com&gt;
Reviewed-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-4-a4a33bc4d70e@analog.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: event: add optional event label support</title>
<updated>2023-10-11T14:54:41+00:00</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2023-10-06T00:50:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5987279373446e97206a7078b2229446ba871ea0'/>
<id>5987279373446e97206a7078b2229446ba871ea0</id>
<content type='text'>
This adds a new optional field to struct iio_info to allow drivers to
specify a label for the event. This is useful for cases where there are
many events or the event attribute name is not descriptive enough or
where an event doesn't have any other attributes.

The implementation is based on the existing label support for channels.
So either all events of a device have a label attribute or none do.

Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-12-ec00746840fc@baylibre.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds a new optional field to struct iio_info to allow drivers to
specify a label for the event. This is useful for cases where there are
many events or the event attribute name is not descriptive enough or
where an event doesn't have any other attributes.

The implementation is based on the existing label support for channels.
So either all events of a device have a label attribute or none do.

Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-12-ec00746840fc@baylibre.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: improve doc for available_scan_mask</title>
<updated>2023-10-05T13:44:06+00:00</updated>
<author>
<name>Matti Vaittinen</name>
<email>mazziesaccount@gmail.com</email>
</author>
<published>2023-09-27T08:27:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8a76356e7db02ec7b1913db06605e70294d94672'/>
<id>8a76356e7db02ec7b1913db06605e70294d94672</id>
<content type='text'>
The available_scan_mask is an array of bitmaps representing the channels
which can be simultaneously enabled by the driver. In many cases, the
hardware can offer more channels than what the user is interested in
obtaining. In such cases, it may be preferred that only a subset of
channels are enabled, and the driver reads only a subset of the channels
from the hardware.

Some devices can't support all channel combinations. For example, the
BM1390 pressure sensor must always read the pressure data in order to
acknowledge the watermark IRQ, while reading temperature can be omitted.
So, the available scan masks would be 'pressure and temperature' and
'pressure only'.

When IIO searches for the scan mask it asks the driver to use, it will
pick the first suitable one from the 'available_scan_mask' array. Hence,
ordering the masks in the array makes a difference. We should 'prefer'
reading just the pressure from the hardware (as it is a cheaper operation
than reading both pressure and temperature) over reading both pressure
and temperature. Hence, we should set the 'only pressure' as the first
scan mask in available_scan_mask array. If we set the 'pressure and
temperature' as first in the array, then the 'only temperature' will never
get used as 'pressure and temperature' can always serve the user's
needs.

Add (minimal) kerneldoc to the 'available_scan_mask' to hint the user
that the ordering of masks matters.

Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Link: https://lore.kernel.org/r/4e43bf0186df5c8a56b470318b4827605f9cad6c.1695727471.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The available_scan_mask is an array of bitmaps representing the channels
which can be simultaneously enabled by the driver. In many cases, the
hardware can offer more channels than what the user is interested in
obtaining. In such cases, it may be preferred that only a subset of
channels are enabled, and the driver reads only a subset of the channels
from the hardware.

Some devices can't support all channel combinations. For example, the
BM1390 pressure sensor must always read the pressure data in order to
acknowledge the watermark IRQ, while reading temperature can be omitted.
So, the available scan masks would be 'pressure and temperature' and
'pressure only'.

When IIO searches for the scan mask it asks the driver to use, it will
pick the first suitable one from the 'available_scan_mask' array. Hence,
ordering the masks in the array makes a difference. We should 'prefer'
reading just the pressure from the hardware (as it is a cheaper operation
than reading both pressure and temperature) over reading both pressure
and temperature. Hence, we should set the 'only pressure' as the first
scan mask in available_scan_mask array. If we set the 'pressure and
temperature' as first in the array, then the 'only temperature' will never
get used as 'pressure and temperature' can always serve the user's
needs.

Add (minimal) kerneldoc to the 'available_scan_mask' to hint the user
that the ordering of masks matters.

Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Link: https://lore.kernel.org/r/4e43bf0186df5c8a56b470318b4827605f9cad6c.1695727471.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: Remove unused declarations</title>
<updated>2023-09-12T09:42:03+00:00</updated>
<author>
<name>Yue Haibing</name>
<email>yuehaibing@huawei.com</email>
</author>
<published>2023-08-11T09:57:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4eaf928622abc5dabc9b42a0de4dafbe29ddf491'/>
<id>4eaf928622abc5dabc9b42a0de4dafbe29ddf491</id>
<content type='text'>
Commit 0f3a8c3f34f7 ("iio: Add support for creating IIO devices via configfs")
declared but never implemented iio_sw_device_type_configfs_{un}register().
Commit b662f809d410 ("iio: core: Introduce IIO software triggers") declared but
never implemented iio_sw_trigger_type_configfs_{un}register().
Commit a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers")
declared but never implemented fxls8962af_core_remove().
Commit 8dedcc3eee3a ("iio: core: centralize ioctl() calls to the main chardev")
declared but never implemented iio_device_ioctl().

Commit d430f3c36ca6 ("iio: imu: inv_mpu6050: Use regmap instead of i2c specific functions")
removed inv_mpu6050_write_reg() but not its declaration.

Signed-off-by: Yue Haibing &lt;yuehaibing@huawei.com&gt;
Link: https://lore.kernel.org/r/20230811095701.35372-1-yuehaibing@huawei.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 0f3a8c3f34f7 ("iio: Add support for creating IIO devices via configfs")
declared but never implemented iio_sw_device_type_configfs_{un}register().
Commit b662f809d410 ("iio: core: Introduce IIO software triggers") declared but
never implemented iio_sw_trigger_type_configfs_{un}register().
Commit a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers")
declared but never implemented fxls8962af_core_remove().
Commit 8dedcc3eee3a ("iio: core: centralize ioctl() calls to the main chardev")
declared but never implemented iio_device_ioctl().

Commit d430f3c36ca6 ("iio: imu: inv_mpu6050: Use regmap instead of i2c specific functions")
removed inv_mpu6050_write_reg() but not its declaration.

Signed-off-by: Yue Haibing &lt;yuehaibing@huawei.com&gt;
Link: https://lore.kernel.org/r/20230811095701.35372-1-yuehaibing@huawei.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'char-misc-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2023-09-01T16:53:54+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-09-01T16:53:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1c9f8dff62d85ce00b0e99f774a84bd783af7cac'/>
<id>1c9f8dff62d85ce00b0e99f774a84bd783af7cac</id>
<content type='text'>
Pull char/misc driver updates from Greg KH:
 "Here is the big set of char/misc and other small driver subsystem
  changes for 6.6-rc1.

  Stuff all over the place here, lots of driver updates and changes and
  new additions. Short summary is:

   - new IIO drivers and updates

   - Interconnect driver updates

   - fpga driver updates and additions

   - fsi driver updates

   - mei driver updates

   - coresight driver updates

   - nvmem driver updates

   - counter driver updates

   - lots of smaller misc and char driver updates and additions

  All of these have been in linux-next for a long time with no reported
  problems"

* tag 'char-misc-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (267 commits)
  nvmem: core: Notify when a new layout is registered
  nvmem: core: Do not open-code existing functions
  nvmem: core: Return NULL when no nvmem layout is found
  nvmem: core: Create all cells before adding the nvmem device
  nvmem: u-boot-env:: Replace zero-length array with DECLARE_FLEX_ARRAY() helper
  nvmem: sec-qfprom: Add Qualcomm secure QFPROM support
  dt-bindings: nvmem: sec-qfprom: Add bindings for secure qfprom
  dt-bindings: nvmem: Add compatible for QCM2290
  nvmem: Kconfig: Fix typo "drive" -&gt; "driver"
  nvmem: Explicitly include correct DT includes
  nvmem: add new NXP QorIQ eFuse driver
  dt-bindings: nvmem: Add t1023-sfp efuse support
  dt-bindings: nvmem: qfprom: Add compatible for MSM8226
  nvmem: uniphier: Use devm_platform_get_and_ioremap_resource()
  nvmem: qfprom: do some cleanup
  nvmem: stm32-romem: Use devm_platform_get_and_ioremap_resource()
  nvmem: rockchip-efuse: Use devm_platform_get_and_ioremap_resource()
  nvmem: meson-mx-efuse: Convert to devm_platform_ioremap_resource()
  nvmem: lpc18xx_otp: Convert to devm_platform_ioremap_resource()
  nvmem: brcm_nvram: Use devm_platform_get_and_ioremap_resource()
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull char/misc driver updates from Greg KH:
 "Here is the big set of char/misc and other small driver subsystem
  changes for 6.6-rc1.

  Stuff all over the place here, lots of driver updates and changes and
  new additions. Short summary is:

   - new IIO drivers and updates

   - Interconnect driver updates

   - fpga driver updates and additions

   - fsi driver updates

   - mei driver updates

   - coresight driver updates

   - nvmem driver updates

   - counter driver updates

   - lots of smaller misc and char driver updates and additions

  All of these have been in linux-next for a long time with no reported
  problems"

* tag 'char-misc-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (267 commits)
  nvmem: core: Notify when a new layout is registered
  nvmem: core: Do not open-code existing functions
  nvmem: core: Return NULL when no nvmem layout is found
  nvmem: core: Create all cells before adding the nvmem device
  nvmem: u-boot-env:: Replace zero-length array with DECLARE_FLEX_ARRAY() helper
  nvmem: sec-qfprom: Add Qualcomm secure QFPROM support
  dt-bindings: nvmem: sec-qfprom: Add bindings for secure qfprom
  dt-bindings: nvmem: Add compatible for QCM2290
  nvmem: Kconfig: Fix typo "drive" -&gt; "driver"
  nvmem: Explicitly include correct DT includes
  nvmem: add new NXP QorIQ eFuse driver
  dt-bindings: nvmem: Add t1023-sfp efuse support
  dt-bindings: nvmem: qfprom: Add compatible for MSM8226
  nvmem: uniphier: Use devm_platform_get_and_ioremap_resource()
  nvmem: qfprom: do some cleanup
  nvmem: stm32-romem: Use devm_platform_get_and_ioremap_resource()
  nvmem: rockchip-efuse: Use devm_platform_get_and_ioremap_resource()
  nvmem: meson-mx-efuse: Convert to devm_platform_ioremap_resource()
  nvmem: lpc18xx_otp: Convert to devm_platform_ioremap_resource()
  nvmem: brcm_nvram: Use devm_platform_get_and_ioremap_resource()
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: Add event enums for running period and count</title>
<updated>2023-07-23T12:16:18+00:00</updated>
<author>
<name>Waqar Hameed</name>
<email>waqar.hameed@axis.com</email>
</author>
<published>2023-07-19T07:51:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5e1cd3e97e8673d7e3d61e3060cbae83c6e65757'/>
<id>5e1cd3e97e8673d7e3d61e3060cbae83c6e65757</id>
<content type='text'>
There are devices (such as Murata IRS-D200 PIR proximity sensor) that
check the data signal with a running period. I.e. for a specified time,
they count the number of conditions that have occurred, and then signal
if that is more than a specified amount.

`IIO_EV_INFO_PERIOD` resets when the condition no longer is true and is
therefore not suitable for these devices. Add a new `iio_event_info`
`IIO_EV_INFO_RUNNING_PERIOD` that can be used as a running period. Also
add a new `IIO_EV_INFO_RUNNING_COUNT` that can be used to specify the
number of conditions that must occur during this running period.

Signed-off-by: Waqar Hameed &lt;waqar.hameed@axis.com&gt;
Link: https://lore.kernel.org/r/ee4a801ae9b9c4716c7bd23d8f79f232351df8bd.1689753076.git.waqar.hameed@axis.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are devices (such as Murata IRS-D200 PIR proximity sensor) that
check the data signal with a running period. I.e. for a specified time,
they count the number of conditions that have occurred, and then signal
if that is more than a specified amount.

`IIO_EV_INFO_PERIOD` resets when the condition no longer is true and is
therefore not suitable for these devices. Add a new `iio_event_info`
`IIO_EV_INFO_RUNNING_PERIOD` that can be used as a running period. Also
add a new `IIO_EV_INFO_RUNNING_COUNT` that can be used to specify the
number of conditions that must occur during this running period.

Signed-off-by: Waqar Hameed &lt;waqar.hameed@axis.com&gt;
Link: https://lore.kernel.org/r/ee4a801ae9b9c4716c7bd23d8f79f232351df8bd.1689753076.git.waqar.hameed@axis.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: make invensense timestamp module generic</title>
<updated>2023-07-20T18:21:28+00:00</updated>
<author>
<name>Jean-Baptiste Maneyrol</name>
<email>jean-baptiste.maneyrol@tdk.com</email>
</author>
<published>2023-06-06T16:21:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0ecc363ccea71eda6a2cceade120489259bcdb33'/>
<id>0ecc363ccea71eda6a2cceade120489259bcdb33</id>
<content type='text'>
Rename common module to inv_sensors_timestamp, add configuration
at init (chip internal clock, acceptable jitter, ...) and update
inv_icm42600 driver integration.

Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Link: https://lore.kernel.org/r/20230606162147.79667-4-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rename common module to inv_sensors_timestamp, add configuration
at init (chip internal clock, acceptable jitter, ...) and update
inv_icm42600 driver integration.

Signed-off-by: Jean-Baptiste Maneyrol &lt;jean-baptiste.maneyrol@tdk.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Link: https://lore.kernel.org/r/20230606162147.79667-4-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
