linux-kernel - Re: Documentation of iio_read_channel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251109171422.0463d885@jic23-huawei>
Date: Sun, 9 Nov 2025 17:14:22 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: "Luca Weiss" <luca.weiss@...rphone.com>
Cc: "David Lechner" <dlechner@...libre.com>, Nuno Sá
 <nuno.sa@...log.com>, "Andy Shevchenko" <andy@...nel.org>,
 <linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Documentation of iio_read_channel_processed return value

On Sat, 08 Nov 2025 18:55:08 +0100
"Luca Weiss" <luca.weiss@...rphone.com> wrote:

> Hi all,
> 
> I've noticed that the docstring in include/linux/iio/consumer.h for
> iio_read_channel_processed (and likely some other functions in there) is
> wrong because it's saying "Returns an error code or 0." while often it's
> returning e.g. IIO_VAL_INT. In some code paths it's actually returning 0
> but it seems in standard cases it's not.
Hmm. Looks like we have a bug in handling the path that ends up in iio_multiple_value()

I think we just want to change iio_read_channel_processed_scale() to check
that the return value of iio_mutliple_value() < 0 and return ret if so, otherwise
return 0

So to me smells like a bug and the documentation is correct.

Good catch, perhaps spin a patch like the above?  This is made more complex
because a few drivers seem to assume IIO_INT_VAL such as iio/afe/iio-rescale.c so
we will need to fix those up as well.

J

> 
> Could the docstring please be updated so this is clear to users of this
> function? I don't understand IIO well enough to confidently propose
> changes there myself.
> 
> Thanks and kind regards
> Luca