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 106AA1A9F88 for ; Mon, 2 Feb 2026 10:28:16 +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=1770028098; cv=none; b=EyiAJlIKrN0OcS+bSzeHT4AvxqdzA2RfEFEd49V4E8cyjLSx2NwBLvIBPUNGwyBQpVMxuioWLD/xwLQpjhmCFSFVT5qzezSXbZS8Q8uqJxoC2VD9wCGvFgyGqcBsI/oIseAZmDcVmTAyXSGcGILRfvznjPsvUxsA7KkOpStLU7I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770028098; c=relaxed/simple; bh=rvNHL0ubLKI3zwcs+VS8kKlMu8XCU3hV0f73ltP7w04=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=IL2rxI2NzdYUppaOhETYwstatleAmaUTKvCXZgklHTJef1lDrpRrG2+9BXjVu33c90oe+U2uArkre9Sx0PVFMlWBeG4wrmd+DvXqq0GELfZCSPIP+XF5f0KRumAdVtX5OX473xyj0OexYkdzr9hnj4IQQrQXgmvWHeU7Eyq8q28= 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=QMKxaRTu; 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="QMKxaRTu" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-432d2c7a8b9so3749980f8f.2 for ; Mon, 02 Feb 2026 02:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770028095; x=1770632895; 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=SpynF7IJVQf6tAq+x4y7ONqAJ6iCab/3R//bsH8hURg=; b=QMKxaRTuOlmVFBxOEUdaxPkYgctAz0x1yP/Ui+KRUA10BFFBYhQHdhj6F3iczXoY6S ObmZAqvrQzWtvcfEDDvdNTyz/8O+LOfFpONEOiCOs/f+Vc3XQ5v+73ngAK/UeOx19aJm W/X9sJ9skMH/do0NmBN7eny6JChUCKbt8kWJjKoICVa+x1iXDbHIJS2TzMD96zLUGIVA 2U5NV5ZJ8RLCypmqwTbXxbKi+phMthagbpgIFlSxRVfjsJcyNIjE9hZ35PaNMg2h5Fz1 QOq7h6epARUNM+I3tjvDPtDeWWjWyMSlyl6sUffUrZ3D3hEPEjqOC2BWtG2cFRzCxnX3 MM+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770028095; x=1770632895; 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=SpynF7IJVQf6tAq+x4y7ONqAJ6iCab/3R//bsH8hURg=; b=JhcCWK1gn6/8/4yOxFWgM7SJSzchVKTxhiaDoGJwMDycFL10BQrddiSJT5XWAaw9GD /oEanqjhqpdLH9wyuWJk0V/4oh7ojUdBhONYT9DaXwmjwQ2ysT9p5mTDKVP0l2uKYGIj GT1H1exXFSdFw5ojYsJjoA9CHe2eLYHWXcGcJoB8EZs/DkdV5epwu8bNvwYuGZR5rASZ hZVIdGmqsg6caCgd33NIhN3vYR1C7L0A6VKwO6p8p83KtWUyvMX2jwEA0o9Oun3iTPyk ItGmvvQdzDHz3vSYHY14Ndrbv/A8tRzdJbNzeiYRUSvobJx4kvwM65oo1j5CW/9MvEi9 YL9w== X-Forwarded-Encrypted: i=1; AJvYcCVa7uGtTR9/Nzk1/mhDo2KLc4HsoFtBiA0CstUvRgLNAGQu7XCqKtJ6PeKMmIP6YEJ4TS8d/EGdtFhdwx4=@vger.kernel.org X-Gm-Message-State: AOJu0YzyZqQbt5h8Crr+j+Jpp5yDC4iwICS9corpXQaEwrslm1IIjwyM G9vq64pbXewTq4HWxO5NNkvN8DZ/CCb+3stKow+S0keLPIuIT9XpqtDL X-Gm-Gg: AZuq6aKVF9LHaGJmJseV2B4cQVBy466TrBvE7PMlf50Y6ipOz4qpatp5dB8ao14LCP4 WVmjslb14cSVTvnwxtYu/N7GanTKTn7LWIfdEHS3mEBBTeEKnwHBtaJCbTwTnsSw75pzmQDwIll LLkcNUnzlx7RjHVgYW+QC6hJxbsm90KuBAEimkgV8Bn1wbVnlAQgOYdCjsqvxcPuxMuAq1kzCj2 H7vgueiZUmK8O0EieFzcN60IHBP8Izacwry5+fOkf4qbPv/fslvStGIVDyoOMqdzIHceLk/DpSO Y8Re7xKoGLrBiuYXUcqf//aZ92/gXVrzPmc43LkZ7Ntfr7Va2n1nWiwcADXA0ZKfLJ7MFWNR+Zf Y6m0ZUzDhDg0vpfCSYNaxzU6JTpa+L2B0OcVzRl7I4UtjyQ3/WLDSL7aLaSozKGycijfJqxVxY7 vUiTDcklUkuWqFzdYPHG8= X-Received: by 2002:a05:6000:2689:b0:435:930a:658e with SMTP id ffacd0b85a97d-435f3ab06f2mr16177653f8f.53.1770028095214; Mon, 02 Feb 2026 02:28:15 -0800 (PST) Received: from [192.168.1.187] ([148.63.225.166]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131cefdsm43860452f8f.23.2026.02.02.02.28.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 02:28:14 -0800 (PST) Message-ID: <812a8c408c2e3a87ebe1ddc983acdc2cebe3b36b.camel@gmail.com> Subject: Re: [PATCH v5 1/4] iio: industrialio-backend: support backend capabilities From: Nuno =?ISO-8859-1?Q?S=E1?= To: David Lechner , Tomas Melin , Michael Hennerich , Nuno Sa , Lars-Peter Clausen , Jonathan Cameron , Andy Shevchenko , Olivier Moysan Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 02 Feb 2026 10:28:57 +0000 In-Reply-To: <688cbfb1-0944-492a-929d-91ebb9ab22fb@baylibre.com> References: <20260130-b4-ad9467-optional-backend-v5-0-7da803ba7326@vaisala.com> <20260130-b4-ad9467-optional-backend-v5-1-7da803ba7326@vaisala.com> <688cbfb1-0944-492a-929d-91ebb9ab22fb@baylibre.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 Sat, 2026-01-31 at 14:30 -0600, David Lechner wrote: > On 1/30/26 3:16 AM, Tomas Melin wrote: > > Not all backends support the full set of capabilities provided by the > > industrialio-backend framework. Capability bits can be used in frontend= s > > and backends for checking for a certain feature set, or if using > > related functions can be expected to fail. > >=20 > > Capability bits should be set by a compatible backend and provided when > > registering the backend. > >=20 >=20 > ... >=20 > > +/** > > + * enum iio_backend_capabilities - Backend capabilities > > + * Backend capabilities can be used by frontends to check if a given > > + * functionality is supported by the backend. This is useful for front= end > > + * devices which are expected to work with alternative backend > > + * implementations. Capabilities are loosely coupled with operations, > > + * meaning that a capability requires certain operations to be impleme= nted > > + * by the backend. A capability might be mapped to a single operation = or > > + * multiple operations. >=20 > It would be helpful to list these operations explicitly for each > enum member. >=20 > > + * > > + * @IIO_BACKEND_CAP_CALIBRATION: Backend supports digital interface > > + * calibration. Calibration procedure is device specific. > > + * @IIO_BACKEND_CAP_BUFFERING: Backend supports buffering. >=20 > I assume this means it supports devm_iio_backend_request_buffer()? >=20 > In IIO, we usually say "buffer" and rarely "buffering" so this name and > description is a bit confusing to me. >=20 > > + * @IIO_BACKEND_CAP_ALWAYS_ON: Backend does not need to be explicitly > > + * enabled/disabled. It is always on. >=20 > Do we actually need this one? Alternative could be, for example: >=20 > int iio_backend_enable(struct iio_backend *back) > { > int ret; >=20 > ret =3D iio_backend_op_call(back, enable); > =09 > return ret =3D=3D -EOPNOTSUPP ? 0 : ret; > } I would prefer not to assume we can ignore the backend not supporting the call. It opens up the question for other operations. My preferred way for this kind of fundamental operation (enabling/disabling= ) would be to check with DT maintainers if we could have some kind of fixed-b= ackend (fixed in the sense the HW is present but not controlled by Linux) dummy de= vice that with implement a no-OP enable/disable(). - Nuno S=C3=A1