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: <20250112115638.1b163908@jic23-huawei>
Date: Sun, 12 Jan 2025 11:56:38 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org, cosmin.tanislav@...log.com, 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 Tue, 7 Jan 2025 11:53:44 -0600
David Lechner <dlechner@...libre.com> wrote:

> 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.

Good idea.  Given we always allow any attribute to change any other, having
duplicates for ABI backwards compatibility is fine.

Thanks,

Jonathan