IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The deta angle and deta velocity channels were added in parallel with
color temperature and chromacity so this merge had to assign a
consistent order. I put the color related ones second.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
In most cases, ambient color sensors also support the x and y light
colors, which represent the coordinates on the CIE 1931 chromaticity
diagram. Thus, add channel type for chromaticity.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Link: https://lore.kernel.org/r/20230919081054.2050714-7-Basavaraj.Natikar@amd.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
In most cases, ambient color sensors also support light color
temperature, which is measured in kelvin. Thus, add channel type light
color temperature.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Link: https://lore.kernel.org/r/20230919081054.2050714-3-Basavaraj.Natikar@amd.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The delta velocity is defined as a piece-wise integration of
acceleration data. The delta velocity represents the linear velocity
change between two consecutive measurements and it
is measured in m / s (meters per second).
In order to track the total linear velocity change during a desired
period of time, simply sum-up the delta velocity samples acquired
during that time.
IIO currently does not offer a suitable channel type for this
type of measurements hence this patch adds it.
Signed-off-by: Ramona Bolboaca <ramona.bolboaca@analog.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230808075059.645525-3-ramona.bolboaca@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The delta angle is defined as a piece-wise integration of angular
velocity data. The delta angle represents the amount of
angular displacement between two consecutive measurements and it
is measured in radians.
In order to track the total angular displacement during a desired
period of time, simply sum-up the delta angle samples acquired
during that time.
IIO currently does not offer a suitable channel type for this
type of measurements hence this patch adds it.
Signed-off-by: Ramona Bolboaca <ramona.bolboaca@analog.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230808075059.645525-2-ramona.bolboaca@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The `scripts/kernel-doc -v -none -Wall` reports several issues
with the kernel doc in IIO core C file. Update the comments
accordingly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20230724110204.46285-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Let the krealloc_array() copy the original data and
check for a multiplication overflow.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230724110204.46285-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
In the snippets like the following
if (...)
return / goto / break / continue ...;
else
...
the 'else' is redundant. Get rid of it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230721170022.3461-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
min() has strict type checking and preferred over min_t() for
unsigned types to avoid overflow. Here it's unclear why min_t()
was chosen since both variables are of the same type. In any
case update to use min().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230721170022.3461-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Commit 813665564b ("iio: core: Convert to use firmware node handle
instead of OF node") switched the kind of nodes to use for label
retrieval in device registration. Probably an unwanted change in that
commit was that if the device has no parent then NULL pointer is
accessed. This is what happens in the stock IIO dummy driver when a
new entry is created in configfs:
# mkdir /sys/kernel/config/iio/devices/dummy/foo
BUG: kernel NULL pointer dereference, address: ...
...
Call Trace:
__iio_device_register
iio_dummy_probe
Since there seems to be no reason to make a parent device of an IIO
dummy device mandatory, let’s prevent the invalid memory access in
__iio_device_register when the parent device is NULL. With this
change, the IIO dummy driver works fine with configfs.
Fixes: 813665564b ("iio: core: Convert to use firmware node handle instead of OF node")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Link: https://lore.kernel.org/r/20230719083208.88149-1-mzamazal@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
None of the current users is using gaps in the list of the items.
No need to have a specific function for that, just replace it by
library available __sysfs_match_string().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230118074828.66155-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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á <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20221012151620.1725215-5-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These APIs are analogous to iio_device_claim_direct_mode() and
iio_device_release_direct_mode() but, as the name suggests, with the
logic flipped. While this looks odd enough, it will have at least two
users (in following changes) and it will be important to move the IIO
mlock to the private struct.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20221012151620.1725215-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
When a IIO device is registered, the IIO core creates an attribute group on
its own, where it puts the channel attributes, and where it copies the
attributes in indio_dev->info->attrs.
Unfortunately it doesn't take care of binary attributes (i.e. it only
consider indio_dev->info->attrs->attrs, and it ignores
indio_dev->info->attrs->bin_attrs).
Fix this by making the IIO layer take care also of the binary attributes.
Note that while it is necessary to copy the non-binary attributes because
the IIO layer needs more room to add the channels attribute, it should be
enough to assign the bin_attrs pointer to the binary attributes pointed by
indio_dev->info->attrs->bin_attrs.
Signed-off-by: Andrea Merello <andrea.merello@iit.it>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220907132205.28021-8-andrea.merello@iit.it
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add modifiers for reporting rotations as euler angles (i.e. yaw, pitch and
roll).
Signed-off-by: Andrea Merello <andrea.merello@iit.it>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220907132205.28021-5-andrea.merello@iit.it
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add IIO_MOD_LINEAR_X, IIO_MOD_LINEAR_Y and IIO_MOD_LINEAR_Z modifiers to te
IIO core, which is preparatory for adding the Bosch BNO055 IMU driver.
Bosch BNO055 IMU can report raw accelerations (among x, y and z axis) as
well as the so called "linear accelerations" (again, among x, y and z axis)
which is basically the acceleration after subtracting gravity and for which
those new modifiers are for.
Signed-off-by: Andrea Merello <andrea.merello@iit.it>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220907132205.28021-2-andrea.merello@iit.it
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
If an IIO driver uses callbacks from another IIO driver and calls
iio_channel_start_all_cb() from one of its buffer setup ops, then
lockdep complains due to the lock nesting, as in the below example with
lmp91000.
Since the locks are being taken on different IIO devices, there is no
actual deadlock. Fix the warning by telling lockdep to use a different
class for each iio_device.
============================================
WARNING: possible recursive locking detected
--------------------------------------------
python3/23 is trying to acquire lock:
(&indio_dev->mlock){+.+.}-{3:3}, at: iio_update_buffers
but task is already holding lock:
(&indio_dev->mlock){+.+.}-{3:3}, at: enable_store
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&indio_dev->mlock);
lock(&indio_dev->mlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by python3/23:
#0: (sb_writers#5){.+.+}-{0:0}, at: ksys_write
#1: (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter
#2: (kn->active#14){.+.+}-{0:0}, at: kernfs_fop_write_iter
#3: (&indio_dev->mlock){+.+.}-{3:3}, at: enable_store
#4: (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_update_buffers
Call Trace:
__mutex_lock
iio_update_buffers
iio_channel_start_all_cb
lmp91000_buffer_postenable
__iio_update_buffers
enable_store
Fixes: 67e17300dc ("iio: potentiostat: add LMP91000 support")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220829091840.2791846-1-vincent.whitchurch@axis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Prefer lines > 80 characters over splitting dereferences across multiple
lines. Reported by checkpatch.pl.
Signed-off-by: Joe Simmons-Talbott <joetalbott@gmail.com>
Link: https://lore.kernel.org/r/20220819182012.219523-1-joetalbott@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Address an ABI gap for device where the offset of both lines in a
differential pair may be controlled so as to allow a wider range of
inputs, but without having any direct effect of the differential
measurement.
_offset cannot be used as to remain in line with existing usage,
userspace would be expected to apply it as (_raw + _offset) * _scale
whereas _zeropoint is not. i.e. If we were computing the differential
in software it would be.
((postive_raw + _zeropoint) - (negative_raw + zeropoint) + _offset) * _scale
= ((postive_raw - negative_raw) + _offset) * _scale
= (differential_raw + _offset) * _scale
Similarly calibbias is expected to tweak the measurement seen, not
the adjust the two lines of the differential pair.
Needed for in_capacitanceX-capacitanceY_zeropoint for the
AD7746 CDC driver.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220626122938.582107-12-jic23@kernel.org
iio_format_avail_range() should print range as follow [min, step, max], so
the function was previously calling iio_format_list() with length = 3,
length variable refers to the array size of values not the number of
elements. In case of non IIO_VAL_INT values each element has integer part
and decimal part. With length = 3 this would cause premature end of loop
and result in printing only one element.
Signed-off-by: Fawzi Khaber <fawzi.khaber@tdk.com>
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Fixes: eda20ba1e2 ("iio: core: Consolidate iio_format_avail_{list,range}()")
Link: https://lore.kernel.org/r/20220718130706.32571-1-jmaneyrol@invensense.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As reported by checkpatch.pl. Where possible use DEVICE_ATTR_RO(),
DEVICE_ATTR_RW(), and __ATTR_RO(). Change function names to be
<var>_show() for read and <var>_store() for write.
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Joe Simmons-Talbott <joetalbott@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220601185414.251571-1-joetalbott@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Discussion of the series:
https://lore.kernel.org/all/20220405135758.774016-1-catalin.marinas@arm.com/
mm, arm64: Reduce ARCH_KMALLOC_MINALIGN brought to my attention that
our current IIO usage of L1CACHE_ALIGN is insufficient as their are Arm
platforms out their with non coherent DMA and larger cache lines at
at higher levels of their cache hierarchy.
Rename the define to make it's purpose more explicit. It will be used
much more widely going forwards (to replace incorrect ____cacheline_aligned
markings.
Note this patch will greatly reduce the padding on some architectures
that have smaller requirements for DMA safe buffers.
The history of changing values of ARCH_KMALLOC_MINALIGN via
ARCH_DMA_MINALIGN on arm64 is rather complex. I'm not tagging this
as fixing a particular patch from that route as it's not clear what to tag.
Most recently a change to bring them back inline was reverted because
of some Qualcomm Kryo cores with an L2 cache with 128-byte lines
sitting above the point of coherency.
c1132702c7 Revert "arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"
That reverts:
65688d2a05 arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES) which
refers to the change originally being motivated by Thunder x1 performance
rather than correctness.
Fixes: 6f7c8ee585 ("staging:iio: Add ability to allocate private data space to iio_allocate_device")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20220508175712.647246-2-jic23@kernel.org
This function was introduced with the ability to pick a clock.
There are no upstream users so presumably it isn't as obviously useful
as it seemed at the time. Hence drop it.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220220163327.424696-1-jic23@kernel.org
Switch the IIO core to use firmware node handle instead of OF node.
This will allow to get label from firmware on non-OF systems.
Note, this doesn't change of_iio_*() APIs for now.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220413180202.19220-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This entry should, under no situation, be modified by device
drivers. Now that we have limited its read access to device drivers
really needing it and did so through a dedicated helper, we can
easily move this variable to the opaque structure in order to
prevent any further modification from non-authorized code (out of the
core, basically).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20220207143840.707510-12-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
In order to later move this variable within the opaque structure, let's
create a helper for accessing it in read-only mode. This helper will be
exposed to device drivers and kept accessible for the few that could need
it. The write access to this variable however should be fully reserved to
the core so in a second step we will hide this variable into the opaque
structure.
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220207143840.707510-11-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As we are going to hide the currentmode inside the opaque structure,
this helper would soon need to call a non-inline function which would
simply drop the benefit of having the helper defined inline in a header.
One alternative is to move this helper in the core as there is no more
interest in defining it inline in a header. We will pay the minor cost
either way.
Let's do like the iio_device_id() helper which also refers to the opaque
structure and gets defined in the core.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220207143840.707510-10-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in checks for
size and alignment.
This patch converts the places in the IIO core that follow the pattern of
return s*printf(...)
to
return sysfs_emit(...)
This covers the new places that have been introduced where sprintf() is
used for formatting sysfs output since the last time this was done in
commit 83ca56b663 ("iio: core: Use sysfs_emit() (trivial bits)").
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211216185217.1054495-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Drvdata is typically used by drivers to attach driver specific data to a
device. It is used to retrieve driver specific information when only the
device to which the data is attached is available.
In the IIO core in the `iio_device_alloc()` function we call
`iio_device_set_drvdata(indio_dev, indio_dev)`. This sets the drvdata of
the IIO device to itself.
This is rather unnecessary since if we have a pointer to the IIO device to
call `iio_device_get_drvdata()` on it we don't need to call the function
since we already have the pointer. If we only have a pointer to the `struct
device` we can use `dev_to_iio_dev()` to get the IIO device from it.
Furthermore the drvdata is supposed to be reserved for drivers, so it
should not be used by the IIO core in the first place.
The `set_drvdata()` has been around from the very beginning of the IIO
framework and back then it was used in the IIO device sysfs attribute
handling code. But that was subsequently replaced with a `dev_to_iio_dev()`
in commit e53f5ac52e ("iio: Use dev_to_iio_dev()") and other cleanups.
The self `set_drvdata()` is now no longer needed and can be removed.
Verified that there no longer any users by checking for potential users
using the following two coccinelle scripts and reviewing that none of the
matches are problematic code.
<smpl>
@@
struct iio_dev *iio_dev;
expression dev;
identifier fn !~ "(remove|resume|suspend)";
@@
fn(...)
{
...
*iio_dev = dev_get_drvdata(dev)
...
}
</smpl>
<smpl>
@r1@
position p;
struct iio_dev *indio_dev;
identifier dev_fn =~ "^dev_";
identifier devm_fn =~ "^devm_";
@@
(
dev_fn
|
devm_fn
)
(&indio_dev@p->dev, ...)
@@
struct iio_dev *indio_dev;
position p != r1.p;
@@
*&indio_dev@p->dev</smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_device_type struct is never modified, mark it as const. This allows
it to be placed in a read-only memory section, which will protect against
accidental or deliberate modification.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211031080421.2086-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As these are very late in the 5.15 cycle and non are particularly urgent,
they can wait for the merge window.
Key element in this set is Yang Yingliang has identified a number of
issues in error paths introduced recently when we added multiple
buffer support.
Other fixes:
* adi,ad5662
- Fix handling of i2c_master_send() return value.
* adi,ad5766
- Fix a wrong dt-property name that indicated wrong units and
did not mach the bindings.
- Associated 'fix' of the bindings example to have a possible scale.
* st,pressure-spi
- Add some missing entries to the spi_device_id table to ensure
auto-loading works.
* ti,tsc2046
- Fix a backwards comparison leading to a false dev_warn
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAmFxs7kRHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FojEXhAAn8OoUwEaViRbrVuPJmWCLuhZR8/ke1HE
9WFXYjVvr6+FIyxgOxTVhoVd0LmcqzgeMg0si8CvnXvmx0mYqRyGxSgZ0oSWOfNR
/RhfbL3RKyWmbp5ey3JuJxGS9Py1LXSFycsC7igjrgySqGo05kLrMpGkMr2g3d6a
OKBOaoiBQPEvYmkNlFLOhtWGHNA4mICmi7UWwcfeN667SWKT3VFpBllSQwRpRXtz
h/h0XhJg72x7JdJJsiBAWX9IsbBm9bXjaeXWZldDNnrZRS3VKTXzAkMTI0Wu0Rrq
voEXvh74ys280aXoh5eHzN4OLdGBTJLVRjNaEAUaSMry4oWPpnkkda9pYY8dCcaR
b8kPxn68PnrjbBG5et3PBo+/XAh7C0Ny2ETEqI8qlNk9adqUEl0wixuUUEljEqVE
2rB35SEJYJzl0V0Up2uZMzYhPsfw+kbZoLUPyLfL9uNW3r1l9xgQURTM74UZcSdI
cV2kcGWZdIX6IKVrChhPpeXcsS9ZWljWzUGu4IFBw1h9X6jwhbWJvACj889Rf4EI
+ndjCylpE4aJfoZI7JSg5i41KvEGbwE3SkrKZTMNWe6aPajhcylzeG9+jxsAYaPn
+hnKbPTE99oaopu1Od/s2EUtmIontZQy74aDfbQM3HU8fHmauk8/+L9kDNlkV2b3
ZWbSw6Z2g4g=
=jYCH
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-5.16a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next
Jonathan writes:
First set of IIO fixes for the 5.16 cycle
As these are very late in the 5.15 cycle and non are particularly urgent,
they can wait for the merge window.
Key element in this set is Yang Yingliang has identified a number of
issues in error paths introduced recently when we added multiple
buffer support.
Other fixes:
* adi,ad5662
- Fix handling of i2c_master_send() return value.
* adi,ad5766
- Fix a wrong dt-property name that indicated wrong units and
did not mach the bindings.
- Associated 'fix' of the bindings example to have a possible scale.
* st,pressure-spi
- Add some missing entries to the spi_device_id table to ensure
auto-loading works.
* ti,tsc2046
- Fix a backwards comparison leading to a false dev_warn
* tag 'iio-fixes-for-5.16a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio:
iio: buffer: Fix memory leak in iio_buffers_alloc_sysfs_and_mask()
iio: adc: tsc2046: fix scan interval warning
iio: core: fix double free in iio_device_unregister_sysfs()
iio: core: check return value when calling dev_set_name()
iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups()
iio: buffer: Fix double-free in iio_buffers_alloc_sysfs_and_mask()
iio: buffer: Fix memory leak in __iio_buffer_alloc_sysfs_and_mask()
iio: buffer: check return value of kstrdup_const()
iio: dac: ad5446: Fix ad5622_write() return value
Documentation:devicetree:bindings:iio:dac: Fix val
drivers: iio: dac: ad5766: Fix dt property name
iio: st_pressure_spi: Add missing entries SPI to device ID table
Currently IIO only supports buffer mode for capture devices like ADCs. Add
support for buffered mode for output devices like DACs.
The output buffer implementation is analogous to the input buffer
implementation. Instead of using read() to get data from the buffer write()
is used to copy data into the buffer.
poll() with POLLOUT will wakeup if there is space available.
Drivers can remove data from a buffer using iio_pop_from_buffer(), the
function can e.g. called from a trigger handler to write the data to
hardware.
A buffer can only be either a output buffer or an input, but not both. So,
for a device that has an ADC and DAC path, this will mean 2 IIO buffers
(one for each direction).
The direction of the buffer is decided by the new direction field of the
iio_buffer struct and should be set after allocating and before registering
it.
Co-developed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Co-developed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Mihail Chindris <mihail.chindris@analog.com>
Link: https://lore.kernel.org/r/20211007080035.2531-2-mihail.chindris@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
I got the double free report:
BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
iio_device_unregister_sysfs+0x108/0x13b [industrialio]
iio_dev_release+0x9e/0x10e [industrialio]
device_release+0xa5/0x240
If __iio_device_register() fails, iio_dev_opaque->groups will be freed
in error path in iio_device_unregister_sysfs(), then iio_dev_release()
will call iio_device_unregister_sysfs() again, it causes double free.
Set iio_dev_opaque->groups to NULL when it's freed to fix this double free.
Not this is a local work around for a more general mess around life time
management that will get cleaned up and should make this handling
unnecesarry.
Fixes: 32f171724e ("iio: core: rework iio device group creation")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20211013030532.956133-1-yangyingliang@huawei.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The point of this new change is to make the IIO tree actually parsable.
Before, given this attribute as a filename:
in_voltage0_aux_sample_rate
Userspace had no way to know if the attribute name was
"aux_sample_rate" with no extended name, or "sample_rate" with "aux" as
the extended name, or just "rate" with "aux_sample" as the extended
name.
This was somewhat possible to deduce when there was more than one
attribute present for a given channel, e.g:
in_voltage0_aux_sample_rate
in_voltage0_aux_frequency
There, it was possible to deduce that "aux" was the extended name. But
even with more than one attribute, this wasn't very robust, as two
attributes starting with the same prefix (e.g. "sample_rate" and
"sample_size") would result in the first part of the prefix being
interpreted as being part of the extended name.
To address the issue, knowing that channels will never have both a label
and an extended name, set the channel's label to the extended name.
In this case, the label's attribute will also have the extended name in
its filename, but we can live with that - userspace can open
in_voltage0_<prefix>_label and verify that it returns <prefix> to obtain
the extended name.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210618123005.49867-3-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Extended names are a problem for user-space as they make the filenames
in sysfs sometimes not parsable. They are now deprecated in favor of
labels.
This change makes sure that a device driver won't provide both labels
and extended names for its channels. It has never been the case and we
don't want it to happen.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210618123005.49867-2-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
All of the users of iio_read_mount_matrix() are using the very same
property name. Moreover, the property name is hard coded in the API
documentation.
Make this clear and avoid duplication now and in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210518112546.44592-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The devm_iio_device_alloc() function is supposed to return NULL and not
error pointers. Returning an error pointer will lead to a crash in the
callers.
Fixes: cf5724e915 ("iio: core: simplify some devm functions")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/YJ+a1yaMu2QNATgt@mwanda
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is already an acessor function used to access it, making this
move straight forward.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426174911.397061-10-jic23@kernel.org
No reason for this to be exposed to the drivers, so lets move it to the
opaque structure.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210426174911.397061-8-jic23@kernel.org
