From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 565EC36E48A for ; Thu, 15 Jan 2026 11:53:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768478029; cv=none; b=rqsKmwv4xCGzdig6Di1+WCG07HkSTNtv9UqhGum6DqT/IXi3d3dCFOsJa4hallecf6WvRSWIt4GQeQod/qYSrnKKsWQLIYa9mDw95xTPMtra56e2jFGGJ3MFtK4WGwJdXDY2GubXne7spH0CjeYU01EHAORUwPt8oPRskFj+VTY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768478029; c=relaxed/simple; bh=/XYcX4ZF6hkWrb5Pi3v0AQi1e8aX65EI/WLYoPfoLGo=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=S+OT2kCax5gmpkBwg4/Bf2tmqqf05XztnkwDXvgZK/hp7fHUB49QgMul+7dF0yGFlWOQALlX8RzsTshLcOeDc0mW/CD/sPU98hKrOaRBhqpmgmNZCVeWppzOwFVxbyBP80YYjaxX1oMbCMvZ493+f2byJ6RfFkaqOb3BQ6DUEWE= 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=M6qgRXKg; arc=none smtp.client-ip=209.85.128.47 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="M6qgRXKg" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4801d24d91bso1196375e9.2 for ; Thu, 15 Jan 2026 03:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768478027; x=1769082827; 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=FeN1NqskDMCkofNqgbz9AjaJHZXyD+S3GI7j/r2RdhE=; b=M6qgRXKgxVAHUESQwY3+VZ44dwUydaqXms7yDCZxAGBxFJ5dHVDlWZGaKZQbZxlHhm YLDc/9eDPFhOBImmZMyoxt6yt5BAsCWKwI5CqbXGZfklyXtACbR95G47lgtF4NHxcRtI WHi4t9XmY7gZ/IQs59bkx9cbTS6DZdABu5T+GF+KC+BUJj4MMWzPvtBT6P7Vc2h+gLN5 3uyNRYiJ/X5qrE3Pfbc/zwR5faHBGvZBwBAwiJHDoLg1WhopO6WlUVw27UQ4HaXo00E+ AeYSaBH5k5FUxN2XgM99qTiPAU9IrBO7XjhwKn/8chEHc+YwWCgHEUJj0lsgFL4+XlhR B/hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768478027; x=1769082827; 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=FeN1NqskDMCkofNqgbz9AjaJHZXyD+S3GI7j/r2RdhE=; b=ZLgDmpl72Xlc++dFMQUOCLk1amDBOYpp7uOMg8H1aB8ShfhpG5JOXc0gGY8q5alG3A 4DBBJHYysXGy2xsvVODYUBsJV6AtndWABFIJzhBj8dJ4ILed43l2jHVVsI0NY+fpqDh5 J19MrHc9sgYIn95lv3L7DGz43+roY2UOTjGGZnbQz+svz3rZvdLS2gO97F/TSb2mtiE4 ClXkxdwxvr03CVIoBvuLa367A0okz8S80jgZJGX13n0T0QYFrLXllV25FwNEiggkd2cl lmX4Dat2XtKSvDimKlujgclRoEsO77H1bsmHmpl7KAaS1PuPP0UBPnT1BuwW6mk/c8Ul tNnA== X-Forwarded-Encrypted: i=1; AJvYcCUt1WLm1Ge2F/qefdWlEvo/tdlgYISWfyjXEEBpPwF+kiNyMODzT31GTWiNN43wj9+96hnhX8QwLRzBod8=@vger.kernel.org X-Gm-Message-State: AOJu0YzYVGJ5dAAQRxnmHRqSg8apGwpwHA9l9hGmCJtJn+UKrAVdQ/3X WU56+ho2uKwvuAhnO6dgxD65bNmBLDpZf0s0syT81NUW6ppJU4QxgUp/ X-Gm-Gg: AY/fxX4xmbNyXf+kouuGoHvNC57RuGoEKXqQXr+zD4CnoAbvZgPhdGUDyhVGWqAP7tZ o4Feh4PIBt/sZfDnjKEdT6hoaRoUMsQF0sp1Bmz5dwn7c0NP1imE8YK8qbnd6Tw7RvTqbvumdN6 iwPVVBANelsJzVPdhc+x+A4udlm9uDXhgmBy/3moXR6SBlIjqY2COF9uWMIvEkSjeCCoFW0iTyv 6z7Jbenino/h+w+pk1PZnwnp+fFcyLwj1J0jweiYEnxMZDKe+BdlDaCvwu9n+sZUtvS79KQn87F fGA9gbnYPPqUjrE5jGxAbwvKve03Pavq1P06whIwZHfQ9r8CeB/cuCiZk8TBOpGIXoEHZgIpgxC tYKNe1AyQ2J1TM6l6mAlGuQaIUFZYbfdiNJDd4afeMAcJXMBcpWoi9iUmaBzzdutKdNxHaCXJ9J 1vzM9hr+nCGVKgqNUYu1Q= X-Received: by 2002:a05:600c:3f16:b0:479:1b0f:dfff with SMTP id 5b1f17b1804b1-47ee32fd19emr69502975e9.10.1768478026429; Thu, 15 Jan 2026 03:53:46 -0800 (PST) Received: from [192.168.1.187] ([161.230.67.253]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee27d9aaesm44884595e9.3.2026.01.15.03.53.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 03:53:46 -0800 (PST) Message-ID: <9214d1ba49ee31e4f35d8d3fe5d894142e1d6fef.camel@gmail.com> Subject: Re: [PATCH v3 4/4] iio: adc: ad9467: check for backend capabilities From: Nuno =?ISO-8859-1?Q?S=E1?= To: Tomas Melin , Michael Hennerich , Nuno Sa , Lars-Peter Clausen , Jonathan Cameron , David Lechner , Andy Shevchenko , Olivier Moysan Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 15 Jan 2026 11:54:28 +0000 In-Reply-To: <68cee45e-4822-41af-a0da-d1b88166425d@vaisala.com> References: <20260114-b4-ad9467-optional-backend-v3-0-d2c84979d010@vaisala.com> <20260114-b4-ad9467-optional-backend-v3-4-d2c84979d010@vaisala.com> <34e97dbb610e82953657d8354c0a343a9e1fa57a.camel@gmail.com> <68cee45e-4822-41af-a0da-d1b88166425d@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 Wed, 2026-01-14 at 17:23 +0200, Tomas Melin wrote: > Hi, >=20 > On 14/01/2026 14:29, Nuno S=C3=A1 wrote: > > On Wed, 2026-01-14 at 10:45 +0000, Tomas Melin wrote: > > > Add capability checks for operation with backends that do not support > > > full set of features, but are otherwise compatible with the device. > > >=20 >=20 > > > + return 0; > > > + > >=20 > > As David suggested, it might make more sense to do the check from the c= allers. Not as > > important as within the backend functions though. > >=20 > > > =C2=A0 /* all points invalid */ > > > =C2=A0 bitmap_fill(st->calib_map, st->calib_map_size); > > > =C2=A0 > > > @@ -1357,7 +1366,7 @@ static int ad9467_probe(struct spi_device *spi) > > > =C2=A0 return ret; > > > =C2=A0 > > > =C2=A0 ret =3D devm_iio_backend_request_buffer(&spi->dev, st->back, i= ndio_dev); > > > - if (ret) > > > + if (ret && ret !=3D -EOPNOTSUPP) > > > =C2=A0 return ret; > >=20 > > Don't agree with the above. I would prefer to see a dedicated CAP for b= uffering > > otherwise I would argue why not doing the same for everything? While it= might > > be acceptable merging IIO_BACKEND_CAP_TEST_PATTERNS and IIO_BACKEND_CAP= _CALIBRATION > > (given they are related to some extent), that does not apply to bufferi= ng. >=20 > Okay perhaps we first need to agree on how we define a capability;) >=20 > So my thinking here was that calibration capability expands across > several or even many op calls, so it's a feature level thing and > requires several coordinated functions. So does the test pattern, but > it's a sub entity of the calibration so I merged the two together. So > checking for a capability in these cases makes sense, since checking > against a single operation call for determining if the capability is > present is not easy and which function would it be, etc. Makes sense. >=20 > The backend buffer on the other hand maps to a single op call (in theory > two). So checking for that buffering capability can be done by checking > if the op call is supported (eopnotsupp). I was kindof thinking that why > need a capability if the mapping is 1:1 and the information is available > through that error value directly? Yeah, TBH the only reason I can think of is readability. To me, it is more explicit: if (has_buffering()) request_buffer(); //not allowed to fail And can be a bit confusing having a mix of has_capability() and checking fo= r error codes. But yes, checking for specific error codes for determining behavior is a co= mmon pattern so I won't be nitpicky about it. >=20 > On frontend level, like here it is known that the driver can function > without that buffering, so if the backend does not supported it can be > okay to proceed. > If we add a capability for a single operation that has 1:1 mapping then > basically we should map all and that is not really the point? > I see the capability like a contract between the backend and frontend on > feature level, that the feature is there but the implementation of a > specific capability might actually differ depending on the use case > (like we see with ad9467 and ad485x calibration and their backends) >=20 > What are your thoughts about this? >=20 Ok, I think it makes sense to me but maybe we should be more explicit/clear= in the docs: "... meaning that a capability requires certain=C2=A0 operations to be implemented by the backend" Maybe s/certain/multiple and we could even mention that if a frontend is in= terested in knowing that a operation is not supported, the error code can be checked (though this could be obvious already). Let's see what Jonathan and others thinks about it. - Nuno S=C3=A1