<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux/iio/iio.h, branch linux-6.9.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>iio: core: make iio_bus_type const</title>
<updated>2024-02-17T16:16:11+00:00</updated>
<author>
<name>Ricardo B. Marliere</name>
<email>ricardo@marliere.net</email>
</author>
<published>2024-02-08T19:37:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=89b1b86fc77367fac470258acdf470ffe2edc8d4'/>
<id>89b1b86fc77367fac470258acdf470ffe2edc8d4</id>
<content type='text'>
Now that the driver core can properly handle constant struct bus_type,
move the iio_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Suggested-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ricardo B. Marliere &lt;ricardo@marliere.net&gt;
Acked-by: Nuno Sa &lt;nuno.sa@analog.com&gt;
Link: https://lore.kernel.org/r/20240208-bus_cleanup-iio-v1-1-4a167c3b5fb3@marliere.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>
Now that the driver core can properly handle constant struct bus_type,
move the iio_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Suggested-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ricardo B. Marliere &lt;ricardo@marliere.net&gt;
Acked-by: Nuno Sa &lt;nuno.sa@analog.com&gt;
Link: https://lore.kernel.org/r/20240208-bus_cleanup-iio-v1-1-4a167c3b5fb3@marliere.net
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: locking: introduce __cleanup() based direct mode claiming infrastructure</title>
<updated>2024-02-17T16:16:10+00:00</updated>
<author>
<name>Jonathan Cameron</name>
<email>Jonathan.Cameron@huawei.com</email>
</author>
<published>2024-01-28T15:05:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1dae0cb79ceacbdc7495c5f83ca71e1c12a24d7c'/>
<id>1dae0cb79ceacbdc7495c5f83ca71e1c12a24d7c</id>
<content type='text'>
Allows use of:

       iio_device_claim_direct_scoped(return -EBUSY, indio_dev) {
       }

to automatically call iio_device_release_direct_mode() based on scope.
Typically seen in combination with local device specific locks which
are already have automated cleanup options via guard(mutex)(&amp;st-&gt;lock)
and scoped_guard(). Using both together allows most error handling to
be automated.

Reviewed-by: Nuno Sa &lt;nuno.a@analog.com&gt;
Link: https://lore.kernel.org/r/20240128150537.44592-2-jic23@kernel.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>
Allows use of:

       iio_device_claim_direct_scoped(return -EBUSY, indio_dev) {
       }

to automatically call iio_device_release_direct_mode() based on scope.
Typically seen in combination with local device specific locks which
are already have automated cleanup options via guard(mutex)(&amp;st-&gt;lock)
and scoped_guard(). Using both together allows most error handling to
be automated.

Reviewed-by: Nuno Sa &lt;nuno.a@analog.com&gt;
Link: https://lore.kernel.org/r/20240128150537.44592-2-jic23@kernel.org
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<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-stable.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: 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-stable.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-stable.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>Merge tag 'char-misc-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2023-07-03T19:46:47+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-07-03T19:46:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=44aeec836da880c73a8deb2c7735c6e7c36f47c3'/>
<id>44aeec836da880c73a8deb2c7735c6e7c36f47c3</id>
<content type='text'>
Pull Char/Misc updates from Greg KH:
 "Here is the big set of char/misc and other driver subsystem updates
  for 6.5-rc1.

  Lots of different, tiny, stuff in here, from a range of smaller driver
  subsystems, including pulls from some substems directly:

   - IIO driver updates and additions

   - W1 driver updates and fixes (and a new maintainer!)

   - FPGA driver updates and fixes

   - Counter driver updates

   - Extcon driver updates

   - Interconnect driver updates

   - Coresight driver updates

   - mfd tree tag merge needed for other updates on top of that, lots of
     small driver updates as patches, including:

   - static const updates for class structures

   - nvmem driver updates

   - pcmcia driver fix

   - lots of other small driver updates and fixes

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

* tag 'char-misc-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (243 commits)
  bsr: fix build problem with bsr_class static cleanup
  comedi: make all 'class' structures const
  char: xillybus: make xillybus_class a static const structure
  xilinx_hwicap: make icap_class a static const structure
  virtio_console: make port class a static const structure
  ppdev: make ppdev_class a static const structure
  char: misc: make misc_class a static const structure
  /dev/mem: make mem_class a static const structure
  char: lp: make lp_class a static const structure
  dsp56k: make dsp56k_class a static const structure
  bsr: make bsr_class a static const structure
  oradax: make 'cl' a static const structure
  hwtracing: hisi_ptt: Fix potential sleep in atomic context
  hwtracing: hisi_ptt: Advertise PERF_PMU_CAP_NO_EXCLUDE for PTT PMU
  hwtracing: hisi_ptt: Export available filters through sysfs
  hwtracing: hisi_ptt: Add support for dynamically updating the filter list
  hwtracing: hisi_ptt: Factor out filter allocation and release operation
  samples: pfsm: add CC_CAN_LINK dependency
  misc: fastrpc: check return value of devm_kasprintf()
  coresight: dummy: Update type of mode parameter in dummy_{sink,source}_enable()
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull Char/Misc updates from Greg KH:
 "Here is the big set of char/misc and other driver subsystem updates
  for 6.5-rc1.

  Lots of different, tiny, stuff in here, from a range of smaller driver
  subsystems, including pulls from some substems directly:

   - IIO driver updates and additions

   - W1 driver updates and fixes (and a new maintainer!)

   - FPGA driver updates and fixes

   - Counter driver updates

   - Extcon driver updates

   - Interconnect driver updates

   - Coresight driver updates

   - mfd tree tag merge needed for other updates on top of that, lots of
     small driver updates as patches, including:

   - static const updates for class structures

   - nvmem driver updates

   - pcmcia driver fix

   - lots of other small driver updates and fixes

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

* tag 'char-misc-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (243 commits)
  bsr: fix build problem with bsr_class static cleanup
  comedi: make all 'class' structures const
  char: xillybus: make xillybus_class a static const structure
  xilinx_hwicap: make icap_class a static const structure
  virtio_console: make port class a static const structure
  ppdev: make ppdev_class a static const structure
  char: misc: make misc_class a static const structure
  /dev/mem: make mem_class a static const structure
  char: lp: make lp_class a static const structure
  dsp56k: make dsp56k_class a static const structure
  bsr: make bsr_class a static const structure
  oradax: make 'cl' a static const structure
  hwtracing: hisi_ptt: Fix potential sleep in atomic context
  hwtracing: hisi_ptt: Advertise PERF_PMU_CAP_NO_EXCLUDE for PTT PMU
  hwtracing: hisi_ptt: Export available filters through sysfs
  hwtracing: hisi_ptt: Add support for dynamically updating the filter list
  hwtracing: hisi_ptt: Factor out filter allocation and release operation
  samples: pfsm: add CC_CAN_LINK dependency
  misc: fastrpc: check return value of devm_kasprintf()
  coresight: dummy: Update type of mode parameter in dummy_{sink,source}_enable()
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: core: use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN</title>
<updated>2023-06-19T23:19:22+00:00</updated>
<author>
<name>Catalin Marinas</name>
<email>catalin.marinas@arm.com</email>
</author>
<published>2023-06-12T15:31:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=88b216d339691888ef98644a5eae62c3d9c8ddf0'/>
<id>88b216d339691888ef98644a5eae62c3d9c8ddf0</id>
<content type='text'>
ARCH_DMA_MINALIGN represents the minimum (static) alignment for safe DMA
operations while ARCH_KMALLOC_MINALIGN is the minimum kmalloc() objects
alignment.

Link: https://lkml.kernel.org/r/20230612153201.554742-11-catalin.marinas@arm.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Tested-by: Isaac J. Manjarres &lt;isaacmanjarres@google.com&gt;
Cc: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: Alasdair Kergon &lt;agk@redhat.com&gt;
Cc: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Cc: Joerg Roedel &lt;joro@8bytes.org&gt;
Cc: Jonathan Cameron &lt;jic23@kernel.org&gt;
Cc: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Cc: Marc Zyngier &lt;maz@kernel.org&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Cc: Mike Snitzer &lt;snitzer@kernel.org&gt;
Cc: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Cc: Robin Murphy &lt;robin.murphy@arm.com&gt;
Cc: Saravana Kannan &lt;saravanak@google.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ARCH_DMA_MINALIGN represents the minimum (static) alignment for safe DMA
operations while ARCH_KMALLOC_MINALIGN is the minimum kmalloc() objects
alignment.

Link: https://lkml.kernel.org/r/20230612153201.554742-11-catalin.marinas@arm.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Acked-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Tested-by: Isaac J. Manjarres &lt;isaacmanjarres@google.com&gt;
Cc: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Cc: Alasdair Kergon &lt;agk@redhat.com&gt;
Cc: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Cc: Joerg Roedel &lt;joro@8bytes.org&gt;
Cc: Jonathan Cameron &lt;jic23@kernel.org&gt;
Cc: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Cc: Marc Zyngier &lt;maz@kernel.org&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Cc: Mike Snitzer &lt;snitzer@kernel.org&gt;
Cc: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Cc: Robin Murphy &lt;robin.murphy@arm.com&gt;
Cc: Saravana Kannan &lt;saravanak@google.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: core: Point users of extend_name field to read_label callback</title>
<updated>2023-05-13T17:28:10+00:00</updated>
<author>
<name>Marijn Suijten</name>
<email>marijn.suijten@somainline.org</email>
</author>
<published>2023-05-01T23:17:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=123627ad03d9915f6a6ecb69bb86a80da69ee972'/>
<id>123627ad03d9915f6a6ecb69bb86a80da69ee972</id>
<content type='text'>
As mentioned and discussed in [1] extend_name should not be used for
full channel labels (and most drivers seem to only use it to express a
short type of a channel) as this affects sysfs filenames, while the
label name is supposed to be extracted from the *_label sysfs file
instead.  This appears to have been unclear to some drivers as
extend_name is also used when read_label is unset, achieving an initial
goal of providing sensible names in *_label sysfs files without noticing
that sysfs filenames are (negatively and likely unintentionally)
affected as well.

Point readers of iio_chan_spec::extend_name to iio_info::read_label by
mentioning deprecation and side-effects of this field.

[1]: https://lore.kernel.org/linux-arm-msm/20221221223432.si2aasbleiicayfl@SoMainline.org/

Suggested-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Marijn Suijten &lt;marijn.suijten@somainline.org&gt;
Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-1-6be5db6e6b5a@somainline.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>
As mentioned and discussed in [1] extend_name should not be used for
full channel labels (and most drivers seem to only use it to express a
short type of a channel) as this affects sysfs filenames, while the
label name is supposed to be extracted from the *_label sysfs file
instead.  This appears to have been unclear to some drivers as
extend_name is also used when read_label is unset, achieving an initial
goal of providing sensible names in *_label sysfs files without noticing
that sysfs filenames are (negatively and likely unintentionally)
affected as well.

Point readers of iio_chan_spec::extend_name to iio_info::read_label by
mentioning deprecation and side-effects of this field.

[1]: https://lore.kernel.org/linux-arm-msm/20221221223432.si2aasbleiicayfl@SoMainline.org/

Suggested-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Marijn Suijten &lt;marijn.suijten@somainline.org&gt;
Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-1-6be5db6e6b5a@somainline.org
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: add struct declaration for iio types</title>
<updated>2022-12-28T17:19:44+00:00</updated>
<author>
<name>Gerald Loacker</name>
<email>gerald.loacker@wolfvision.net</email>
</author>
<published>2022-12-01T07:22:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=08f01cc1d6e240092a6d9bfa21652622657f38f0'/>
<id>08f01cc1d6e240092a6d9bfa21652622657f38f0</id>
<content type='text'>
Add struct for iio type arrays such as IIO_AVAIL_LIST which can be used
instead of int arrays.

Signed-off-by: Gerald Loacker &lt;gerald.loacker@wolfvision.net&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20221201072220.402585-2-gerald.loacker@wolfvision.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>
Add struct for iio type arrays such as IIO_AVAIL_LIST which can be used
instead of int arrays.

Signed-off-by: Gerald Loacker &lt;gerald.loacker@wolfvision.net&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20221201072220.402585-2-gerald.loacker@wolfvision.net
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: core: move 'mlock' to 'struct iio_dev_opaque'</title>
<updated>2022-11-23T19:44:00+00:00</updated>
<author>
<name>Nuno Sá</name>
<email>nuno.sa@analog.com</email>
</author>
<published>2022-10-12T15:16:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=16afe125b53f88b855d2713c8ba253d905dcf3cc'/>
<id>16afe125b53f88b855d2713c8ba253d905dcf3cc</id>
<content type='text'>
Now that there are no more users accessing 'mlock' directly, we can move
it to the iio_dev private structure. Hence, it's now explicit that new
driver's should not directly use this lock.

Signed-off-by: Nuno Sá &lt;nuno.sa@analog.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Link: https://lore.kernel.org/r/20221012151620.1725215-5-nuno.sa@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>
Now that there are no more users accessing 'mlock' directly, we can move
it to the iio_dev private structure. Hence, it's now explicit that new
driver's should not directly use this lock.

Signed-off-by: Nuno Sá &lt;nuno.sa@analog.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Link: https://lore.kernel.org/r/20221012151620.1725215-5-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
