Received-SPF: pass (google.com: domain of linux-kernel+bounces-189745-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240507-iio-add-support-for-multiple-scan-types-v1-0-95ac33ee51e9@baylibre.com>
 <20240507-iio-add-support-for-multiple-scan-types-v1-3-95ac33ee51e9@baylibre.com>
 <20240519201241.7c60abac@jic23-huawei> <ebf18ed1-a82f-4c0a-9a63-2c428b5aee40@baylibre.com>
 <20240520171205.000035b0@Huawei.com> <5cf036d5-1eb3-4f63-82f9-d01b79b7fe47@baylibre.com>
 <20240525171408.36bda583@jic23-huawei> <003d0998-dd25-45ab-9bb1-feda2d0f91a3@baylibre.com>
 <20240526131018.40c772d6@jic23-huawei>
In-Reply-To: <20240526131018.40c772d6@jic23-huawei>
From: David Lechner <dlechner@baylibre.com>
Date: Sun, 26 May 2024 08:53:19 -0500
Message-ID: <CAMknhBGhk5VNG+L-HyT3=b2h38k0-dGwTfoWzxLTZfsKuidvtQ@mail.gmail.com>
Subject: Re: [PATCH RFC 3/4] iio: add support for multiple scan types per channel
To: Jonathan Cameron <jic23@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>, 
	Michael Hennerich <Michael.Hennerich@analog.com>, =?UTF-8?B?TnVubyBTw6E=?= <nuno.sa@analog.com>, 
	Julien Stephan <jstephan@baylibre.com>, Esteban Blanc <eblanc@baylibre.com>, linux-iio@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, May 26, 2024 at 7:11=E2=80=AFAM Jonathan Cameron <jic23@kernel.org>=
 wrote:
>
> On Sat, 25 May 2024 12:04:46 -0500
> David Lechner <dlechner@baylibre.com> wrote:
>
> > On 5/25/24 11:14 AM, Jonathan Cameron wrote:
> > > On Fri, 24 May 2024 10:56:55 -0500
> > > David Lechner <dlechner@baylibre.com> wrote:
> > >
> > >> On 5/20/24 11:12 AM, Jonathan Cameron wrote:
> > >>> On Mon, 20 May 2024 08:51:52 -0500
> > >>> David Lechner <dlechner@baylibre.com> wrote:
> > >>>
> > >>>> On 5/19/24 2:12 PM, Jonathan Cameron wrote:
> > >>>>> On Tue,  7 May 2024 14:02:07 -0500
> > >>>>> David Lechner <dlechner@baylibre.com> wrote:
> > >>>>>

..

> >
> > Maybe we are talking about two different things but calling them the sa=
me thing?
>
> I'm not sure.  Sounds like we both think our point is entirely obvious an=
d clearly
> it isn't :(
>
> > > Key is the complete lack of
> > > association between what is returned by the get_current_scan_type() c=
allback
> > > and this ext_scan_type array.
> >
> > Why would the caller of get_current_scan_type() need to know that the
> > returned value is associated with ext_scan_type?
>
> Because you are validating ext_scan_type, not the return of get_current_s=
can_type().
> They may or may not include the same data - to make this a good interface=
, that isn't
> error prone, get_current_scan_type() must return one that has been valida=
ted - i.e.
> is in the ext_scan_type array.
>
> I've looked several times and maybe I'm just failing to spot what ensures=
 the validation
> is sufficient.
>

Ah, I finally get it now. I was having tunnel vision and it didn't
even occur to me that someone might be tempted to return anything that
wasn't a pointer to the ext_scan types array.

> >
> > >
> > > So either:
> > > 1) Make it do so - easiest being to return an index into the array ra=
ther than
> > >    a possibly unrelated scan_type -
> >

This option 1) makes sense to me now.

Do we also need to validate that the index returned is <
num_ext_scan_types in iio_get_current_scan_type()?