linux-kernel - Re: [PATCH] iio: adc: ad9467: Fix the "don't allow reading vref if not available" case

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: <5c2d828b-247a-419f-97a9-a77a6653e846@baylibre.com>
Date: Thu, 5 Dec 2024 18:03:37 -0600
From: David Lechner <dlechner@...libre.com>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Nuno Sa <nuno.sa@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
 Jonathan Cameron <jic23@...nel.org>
Cc: linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>, linux-iio@...r.kernel.org
Subject: Re: [PATCH] iio: adc: ad9467: Fix the "don't allow reading vref if
 not available" case

On 12/5/24 2:47 PM, Christophe JAILLET wrote:
> The commit in Fixes add a special case when only one possible scale is
> available.
> If several scales are available, it sets the .read_avail field of the
> struct iio_info to ad9467_read_avail().
> 
> However, this field already holds this function pointer, so the code is a
> no-op.
> 
> Update ad9467_info to actually reflect the intent described in the commit
> message. Keep .read_avail to NULL, unless it is changed to
> ad9467_read_avail() in the probe at runtime.
> 
> Fixes: b92f94f74826 ("iio: adc: ad9467: don't allow reading vref if not available")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
> ---
> This patch is compile tested only and is completely speculative.
> 
> Another solution would be to keep ad9467_info as a const struct as it was
> before and add a new ad9467_info_no_read structure.

Yes, making it static const again would be best. Modifying static structs
that are shared between all instances like this based on the properties of
a single instance is asking for trouble down the road.

> This way, instead of writing in the structure itself, we would choose at
> runtime which version to use. The main benefit would be keep this structure
> with function pointer const.
> ---