linux-kernel - Re: [PATCH v2 3/3] Documentation: ABI: IIO: Drop AD4130 specific filter_type

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1684bc1a-c983-4baf-8b4d-0c6ff0f1640a@baylibre.com>
Date: Tue, 7 Jan 2025 11:53:44 -0600
From: David Lechner <dlechner@...libre.com>
To: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Cc: cosmin.tanislav@...log.com, jic23@...nel.org, lars@...afoo.de,
 granquet@...libre.com, u.kleine-koenig@...libre.com,
 marcelo.schmitt1@...il.com
Subject: Re: [PATCH v2 3/3] Documentation: ABI: IIO: Drop AD4130 specific
 filter_type_available options

On 1/7/25 9:13 AM, Marcelo Schmitt wrote:
> The only driver exporting filter_type_available attribute is ad7779 and it
> only supports sinc3 and sinc5 filters. Remove options that are not
> presented through filter_type_available attribute.
> 
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@...log.com>
> ---
> Maybe this is not worth it (or desirable?) since the options may come back in
> the future if new drivers happen to need them.

I would be tempted to add filter_type{,_available} attributes to the ad4130
driver that mirrors the existing filter_mode{,_available} attributes. We can't
remove filter_mode since that would break things, but having filter_type in
addition to that would mean than userspace tools could standardize on
filter_type and not have to make a special exception for the different naming
on ad4130.

Then we wouldn't need to delete the extra items here and we wouldn't have to
repeat the docs for sysfs-bus-iio-adc-ad4130. Those docs can just have the
deprecation paragraph and mention that it returns values identical to the
filter_type attributes for backwards compatibility.