From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 B2B0C38FF0F for ; Tue, 13 Jan 2026 12:43:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768308207; cv=none; b=YBopwAtK9fAFzF7X35b1GnSYvOtIQUoiuyf0kKPlcSIz9q5Odb6Ld8/3/HsAwPC4UiKtDz6r2ii6p/scDm7OgkdkGqLed6xT2NMgC3sNvYidtofQV2N24jVly4QVXFUpxIHBovEU4O+SFmLkYgtD5ZnPbTF6bfe9NARnfdxY6yQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768308207; c=relaxed/simple; bh=L3O3sJt+mUneccefToyfz3RiAzBZW6i9zO3xClpZC2c=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=LwYR0ab6eTv76gHQfuPxmPCNk9KO/UOJP8lXGuRxixs1H+Z0SZtL7g0j1TzjT2EEnAPE2UFY+p8fulv7kchOgL0fq67INQzNWnQ7rjIDr1e4o7HoswBU/BgAF0Fjy2rmK9e2EuIuabh9R3u+VE+HsJUS22Xe/jWocCj+PZlBKOk= 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=KUdZvrmT; arc=none smtp.client-ip=209.85.221.45 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="KUdZvrmT" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-42fbc544b09so5985239f8f.1 for ; Tue, 13 Jan 2026 04:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768308204; x=1768913004; 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=sVGMWIu4q8p1YyDY5Ndf2gr61lPlH/BoDgK4ZgFot58=; b=KUdZvrmTer1xIX3vjoPWzoJ0iVMy1cN4LOR8GhnD7h+Gs23FqC+m8GyyBn3knCNPpy NA779LMTefmNJjYJcsi48v1obFoPQeWNvYkdKkrc0RXRG8Irs/mXyEu9Ot0WVgB9ogl/ lA9zYWL3Fk7yyBdoF60EmHNoykicNBGiJU2v3Hrd5yA37cxp/x+Bn6w0cev0rG4PmXzk ipCx+0b+LvGvkIwWx9EMHLUgo/cN6bTNOruZBJt0gjV8Z5c6OolNUZMjNbiW8RuhW/Oe 6XGl+vpJVb2ua4tYm7NDjQRuwC5nl99/+9Cri4pIZ7ifxzxe5NJV20SDLpEddV30aH6c LOug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768308204; x=1768913004; 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=sVGMWIu4q8p1YyDY5Ndf2gr61lPlH/BoDgK4ZgFot58=; b=NGkwTESJwKfQc9w8YJ3xxslN6UK8sUVYCmtJmyplTNabMVTdzvI4ETs6bqqklRAa0y mYB7HlPWDI+7Je1ei1dY1t+aWWpREg10cQzSqsPqsImCrFEg10jbMk3Ypgs4jHcGLIc8 4g59qurusEkpNe7oOiNS97PJajvzuRj4Zumfbu4xmbRyeB5hXkU6EPXprv2PThLK6KOv CUOARE9lEdsBpu/+v2hp0oC7R/p4MGO2jIok2MQAwZgGhLoqCYbzzorV8/4oTQ61ZwbV 5oCk6q/sC9oBFv1BX263Ogh7CsPDtWxrRCt04yoqXu73arhTfzHcQnaJP4zuWtkug8ZK 2W2g== X-Forwarded-Encrypted: i=1; AJvYcCU1pq6UegScRTcEI8ZCpDBobCZbUIOsn875Np8iNo4kkF6Kjg33yIuHwVOSC20Ee32Vo9qrG6LHHZZsuKE=@vger.kernel.org X-Gm-Message-State: AOJu0YxRm5swB29oPnOVCBdL0wVBcW1yzvFyai139BVCtar1f3wrh/hQ 0qdcPsvG2S0kSfYvA6DCwCimYFogDhmDuOtN0swYzHPHW78l6cGVcUg1 X-Gm-Gg: AY/fxX4RQzAfnBYtc+r/v+oL3l85uH9mdZv5OONJd1sH36aUmJv2Ii5JiI0tdfh4FU0 fbmo+4K22GFb0nd1STsl+dAbI+0CIWFA1b3C2eEVV364DG3xlR9GKFjp+uj+oMXLK6voNRCUjhV y3yBPIFSRfP9HU7IBOHvce+3Vv0H+nbgqIYZi5Pt/7ZQewYkplIjrxNM6wxPO0x8mkS4Ntc32Pd j5os41srnzUp1ScEBnascw8kOfAyOHitKK0sCBVMG8ePmmgXvFkg0YnGd97ww060jGrPFsHnoSL xHfALTcnZozsG25nHNsAbyYN5Y3j4Q3HkuBqeM6exiyGfljlE4vYqWXqcOo5qujEr6bmt1fg/lM UZR27o097l2SegHMitRBOVrz6ulf5m8pbe5ecHi4bOr1KoMOukV1ku9UMVkOJ983253wOxCkKfG /bMOmaLH6HBHo= X-Google-Smtp-Source: AGHT+IFjZ9JQSa0TsHDK8takR3IQvAY4G3RlkYtO0mzzhCMkuO7qULp+a2Ir7ye8NQZAS07jOTQgGA== X-Received: by 2002:a5d:588f:0:b0:430:fdfc:7dd3 with SMTP id ffacd0b85a97d-432c37d2efdmr26634762f8f.50.1768308203832; Tue, 13 Jan 2026 04:43:23 -0800 (PST) Received: from [10.5.0.2] ([185.128.9.206]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ede7esm44956945f8f.32.2026.01.13.04.43.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 04:43:23 -0800 (PST) Message-ID: <186a9a1a9cf8bd6c4c91bac62344b7015e696005.camel@gmail.com> 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 12:44:06 +0000 In-Reply-To: <39f4b68b-0bbc-4c41-a8ee-206209900a66@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> <39f4b68b-0bbc-4c41-a8ee-206209900a66@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 13:49 +0200, Tomas Melin wrote: > Hi, >=20 > On 13/01/2026 12:52, Nuno S=C3=A1 wrote: > > 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: >=20 > > > > >=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 t= o > > > > > some external path that we have no visibility of? i.e. We configu= re the > > > > > 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. > >=20 > > So do you have some completely different data path bypassing IIO (just = curious)? >=20 > Yes, IP handles data reception and data transfer outside of iio context. >=20 > >=20 > > >=20 > > > But that being said, I'm leaning towards thinking that perhaps a > > > minimalistic backend should always be registered after all. That woul= d > > > keep the idea of the backend always existing intact. > > > But since the backend can be missing a lot of the features defined fo= r > > > the current ADI backend, capability handling would need to be added t= o > > > the backend framework to make it functional. > > >=20 > > > Looking into how this could be achieved with reasonable impact, I hav= e > > > tried to identify capabilities that we could add for starters, and th= en > > > have the frontend behave differently depending on what features are p= resent. > > >=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 > >=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= interfaces so > > it is easier to deal with bad choices :). >=20 > I understand this concern, but would anticipate that there are only a > limited number of capabilties that need to be handled, so it should stay > fairly managable. >=20 > > =C2=A0 > >=20 > > We would still need to "combine" these capabilities feature with a dumm= y backend that > > would dummy implement the more common/expected like (chan)enable/disabl= e and so on. >=20 > I think the dummy backend is probably not gonna be needed as the current > axi backend can advertise the available set of capabilities. The > frontends are then free to make use of the capability bits as needed. > In my use case, I need to implement a limited backend that does not > claim any capabilities but only provides a minimum set of functionality. >=20 Ok, looking at the driver indeed it seems we would not need much advertised= . Let's see how something like the above would look like and discuss on top o= f that. - Nuno S=C3=A1