From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA41232549E for ; Tue, 13 Jan 2026 10:51:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768301518; cv=none; b=ODXt9qQKPYNiICc3NXp/E/n3IaGOaUGlAKJsUk4oEadidjfAbroTOvsBvl3uSW09RAcgH4G95a3vaRo/dQ7curBE5+fxMPiB9i+TM64RmFM6JSHvdNT7rlLL0W/URtZm5d5QiyjM7wt+LJzej5q2UQ5B6BOK3V4ME1UyswlLJcM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768301518; c=relaxed/simple; bh=wngbeCWJ78AgQdVs8Y4OTon8UJX5Zt1LgSTkbzRSAwY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=fyv/GdzhZk3HUGE9hSwP867nhJH6hvaEiFSg2nZJ7V1e3wgl2tV+FIwgThLz+a/x/CogLyE7Rx+BAx3ieEXbKesn36Y9SEgCTA2JtaCaCFmyIfRrmJNjdwFJtV/5cR/iNjbi6U6dk41E0JVoHAHlU0SJtu2w7iw8ZQp/WyZP2Ws= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PXpgZpr8; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PXpgZpr8" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-430fbb6012bso5968963f8f.1 for ; Tue, 13 Jan 2026 02:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768301515; x=1768906315; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=wynvHKPpqBYNwHxzvvXe3nHnYg6avn76hgMgeTYQIVA=; b=PXpgZpr8wcjXOAWALCVHmJw1Hws4lruBkIfSlJDaphTcXbXvpMVfh/WArrepnnk0o+ C+IeSNhm8zvVlMOO2EuJ4gYoCavC8mULLZxcWkiQ9lJL/7s+blQP+v5kkobt67+3vA5M Ox3f4+8deeXjedH6suMUGCWWV+LXDJy1drM/tJO1+ds1BuN28xd/bUOw8szsoKvvxAVH 1NS1AEFDi4G+equCcKSjUVE9SjFdi0xx204ys5Cw63SfH1hkzV++gJ6e+KPxZIfRQRT7 kmtczGkgwqaXrIGU9cXF/X0TLUQuHBlcSi2DUax4llejUkEcLr9UG4H9Za07jiflFwkx 86IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768301515; x=1768906315; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wynvHKPpqBYNwHxzvvXe3nHnYg6avn76hgMgeTYQIVA=; b=Wj4EDazxHvw/Gb2oiYAWh9zoKuZEZ2u/7JcVqJ9lFgT4avalEyH6WoAtBcrBZFD14M L9qUu/EYBV4Ew7fv1LAqSgt10Bc0zp2veROx9t/oB3oPTRRxYCC9GVpcR8hoKLaNAYQI 1brGbPp5B1/JYm9/DQ6C0xkfG8+8Ml1Y+r5kjpJxsLdO5KQhpZSn6Q318pA+eo3gXHzF 94ob5iT8q7goiM1jWiDR5QKrByBheRncqAe4rY5FbDQNI/eC29lIYKq7YJKBoAkNghFv zrkPkOgmIxBY3LtE3ZlCoZcGib46ywo93WyrogoFrIh1OJnUs4msDzmYad7rHfNIDL7H vSRA== X-Forwarded-Encrypted: i=1; AJvYcCXa1nhRQnIowQb/BoHo1XVibSui2lOZER/9gZZx5rd73tEkgdeilQT3+jFXrcfodMRv8dn8Wkw49wLKSo0=@vger.kernel.org X-Gm-Message-State: AOJu0YwNVyhk2NFBlXThAh9oz44iMZpoIjnLN8wn+am/GHmTQ+VnCXLK VuKGsKdAa5Xmy+JVtqY4TAo2PNHzh3YPwhoNQYIbd7a1FwxXZcCPZ1Y02+oS2p/R X-Gm-Gg: AY/fxX6mtdKuWFOmp65V9Jr+0LldFs8z07mrodHWHmEF66Wfyidcj0MWtdNFYLPpwdJ Roja6vlXHNDsrrgQWP4bD9LJqV+B6RzVp0zgKjISdNEJOGgsqGeDGU7HVGISNEplTpHcmeei6gB vNvuUVZHCh7bjI4YuD1ruFGymHmrzqsuLf8zjGtXs9YVVeKho2QNnSNnC7yryZnTKNbBlrg/bmE j7oqJ4qpS/l4YM2oXv52X7jt2l0VvhKs0KddjqcieGG9uQCnB6xYO2HZQBsYLyUYsHFQCG7UHl0 dfkewUcnl2bcO5kFH13DDFVkeMgX1qn3a7w3aeHsgZlQPsnyTzLiFj0dc/QGPY4SjqCbAjWwfx5 TkeFVOhYNWRX8JocDPxv9xjv7sZwyAIFZ9cHfhtXRleVlLhGQQRFQTLmWmxLaf1YgWaDRK7gPn5 lKCarzMx9lUHpkIiR5uAg= X-Google-Smtp-Source: AGHT+IGMA+7T9erPHocCgSnFpUv/3TN84QugGnjX7iRNwN55w6o7MZeCKJyui0VotySzOLBaIOL7HQ== X-Received: by 2002:a5d:64c8:0:b0:431:32f:3140 with SMTP id ffacd0b85a97d-432c376107dmr25271814f8f.12.1768301514847; Tue, 13 Jan 2026 02:51:54 -0800 (PST) Received: from [192.168.1.187] ([161.230.67.253]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e16d2sm44998383f8f.13.2026.01.13.02.51.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 02:51:54 -0800 (PST) Message-ID: Subject: Re: [PATCH 2/2] iio: adc: ad9467: make iio backend optional From: Nuno =?ISO-8859-1?Q?S=E1?= To: Tomas Melin , Jonathan Cameron Cc: Michael Hennerich , Nuno Sa , Lars-Peter Clausen , David Lechner , Andy Shevchenko , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 13 Jan 2026 10:52:36 +0000 In-Reply-To: <51085acb-91c9-43ad-8f7e-94f1e9c995ed@vaisala.com> References: <20251216-b4-ad9467-optional-backend-v1-0-83e61531ef4d@vaisala.com> <20251216-b4-ad9467-optional-backend-v1-2-83e61531ef4d@vaisala.com> <20251221200014.29af7df8@jic23-huawei> <356a75b0-dc3e-4d10-a827-1af3b4ab638f@vaisala.com> <997f9d13f44031170a4518abf23ee6806d526054.camel@gmail.com> <20260111114109.28b01266@jic23-huawei> <51085acb-91c9-43ad-8f7e-94f1e9c995ed@vaisala.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-01-13 at 09:47 +0200, Tomas Melin wrote: > Hi, >=20 > On 12/01/2026 15:21, Nuno S=C3=A1 wrote: > > On Sun, 2026-01-11 at 11:41 +0000, Jonathan Cameron wrote: > > > On Mon, 05 Jan 2026 14:57:02 +0000 > > > Nuno S=C3=A1 wrote: > > >=20 > > > > On Mon, 2026-01-05 at 13:06 +0200, Tomas Melin wrote: > > > > > Hi, > > > > >=20 > > > > > On 21/12/2025 22:00, Jonathan Cameron wrote:=C2=A0=20 > > > > > > On Tue, 16 Dec 2025 11:40:06 +0000 > > > > > > Tomas Melin wrote: > > > > > > =C2=A0=20 > > > > > > > Not all users can or want to use the device with an iio-backe= nd. > > > > > > > For these users, let the driver work in standalone mode, not = coupled > > > > > > > to the backend or the services it provides. > > > > > > >=20 > > > > > > > Signed-off-by: Tomas Melin =C2=A0= =20 > > > > > > Hi Tomas, > > > > > > =C2=A0=20 > > > > > > > =C2=A0static int ad9467_probe(struct spi_device *spi) > > > > > > > @@ -1352,21 +1361,25 @@ static int ad9467_probe(struct spi_de= vice *spi) > > > > > > > =C2=A0 indio_dev->channels =3D st->info->channels; > > > > > > > =C2=A0 indio_dev->num_channels =3D st->info->num_channels; > > > > > > > =C2=A0 > > > > > > > + /* Using a backend is optional */=C2=A0=20 > > > > > >=20 > > > > > > I'll largely defer to Nuno on the backend aspects but I would l= ike a > > > > > > lot more than a statement that it is optional in this comment. > > > > > > At least something about where the data goes and what a real sy= stem > > > > > > that didn't provide a backend would look like etc.=C2=A0=20 > > > > >=20 > > > > > Having the backend as optional is about flexibility to incorporat= e these > > > > > devices as fits best with the system. The current backend approac= h is > > > > > pretty much dictated with how the ADI default backend is implemen= ted. > > > > > These devices are fully configurable via SPI interface so the bac= kend > > > > > doesn't necessarily need to be anything fancy or even configurabl= e. > > > > >=20 > > > > > So there is atleast two use cases that promote the optional iio-b= ackend > > > > > approach > > > > > =C2=A0- simple backend that is not configurable, no need for a de= dicated > > > > > driver. The backend (FPGA) sits and waits for data and handles it= when > > > > > it arrives=C2=A0=20 > > > >=20 > > > > Agree on the above. Ideally we could have some dummy backend for th= e above but > > > > it is not really easy/maintainable to have it. > > >=20 > > > When we say the backend needs no driver, where does the data end up? > > > Is the idea that it goes into some processing pipeline and sent to > > > some external path that we have no visibility of? i.e. We configure t= he > > > data capture in Linux but never see the data? > >=20 > > Yes, that's also my assumption about Tomas's usecase. >=20 > The data becomes available to user space but there is currently no > immediate need or natural place to create a separate instance to > function as a backend device. So do you have some completely different data path bypassing IIO (just curi= ous)? >=20 > But that being said, I'm leaning towards thinking that perhaps a > minimalistic backend should always be registered after all. That would > keep the idea of the backend always existing intact. > But since the backend can be missing a lot of the features defined for > the current ADI backend, capability handling would need to be added to > the backend framework to make it functional. >=20 > Looking into how this could be achieved with reasonable impact, I have > tried to identify capabilities that we could add for starters, and then > have the frontend behave differently depending on what features are prese= nt. >=20 > Something like this (added to backend_info), > .caps =3D IIO_BACKEND_CAP_TEST_PATTERNS |=C2=A0 --> backend patterns are = avail. > IIO_BACKEND_CAP_BUFFERING |=C2=A0 --> backend has buffering cap. > IIO_BACKEND_CAP_CALIBRATION, --> backend supports calibration >=20 Looks reasonable but I'm still a bit afraid to open this can of worms. But = as Jonathan pointed out multiple times on the backend code, this is mostly inkernel int= erfaces so it is easier to deal with bad choices :). =20 We would still need to "combine" these capabilities feature with a dummy ba= ckend that would dummy implement the more common/expected like (chan)enable/disable an= d so on. We can then decide on a usecase by usecase basis on what should be a capabi= lity or what should be dummy implemented. Bottom line, I'm leaning on "I'm ok with the above" since I expect usecases= like this to be fairly rare (famous last words :)). And It would be nice to have more fe= edback on this one. - Nuno S=C3=A1