From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 ED8413859CE for ; Mon, 9 Feb 2026 16:46:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770655586; cv=none; b=uVZ2HSHeOZzLop35LBQvNNqTvPl4T+ruUrDxMBY4Ukub6bnI4kL8fNSxaQFHbNDqzZ/Ajwc2Ollsa//8B7E4aR4+aXs9OXJQS2aS6dpMox6ZAiXDGb1X/W4BNMneL5h3EuPYfg8FVU+V29JAX/ApIUQicYwWnwIA1UswHcXFLgw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770655586; c=relaxed/simple; bh=CwohizHSnVaA2NNgNrCByNQlZ1oJaWWA0GxEuHaseKg=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Ea5g4bI41N/5JrmC94h7aAixrChk0L0s5gDYSZAdVE2F4+OIUMHJ6jjWt8gCyUK9UAvDuRY+BVoS8HzNy5XDZb1v0GuS4nB4IAIK5hlHbW8GPGbpMJxIPnPq8Y9P4Z8puWlWV7I88lGt/o/c59LX4Dm5QiA9RS0ZldHja8cygC4= 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=CtyEMc4G; arc=none smtp.client-ip=209.85.128.44 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="CtyEMc4G" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4834826e5a0so6106275e9.2 for ; Mon, 09 Feb 2026 08:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770655584; x=1771260384; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=lLb8ag3ra6IO++ksPTcs7qsE4fbhw6boR1CyaCV8y8M=; b=CtyEMc4GwyVBEzvrQEIciduy2i4+EtGAxYgjt3wFjCosVAoyBNl7oOKNDjIz9W3sT7 84syF377CGo9ImIx2b9ZGlR0qZ/wIsbxCHqENnSUfjviyYRz6wb5nE7mgS3ZdafYH0hw b4D0E1IbYYVS8y9XAYyKMDuKhHAx/y6yYFL73FJbDPOZuXq0ztVG4OoG7zG+Lr8hOfa0 iKubVufqn/GVW7UuRmuR5Ry+bJ0NyuZQnzgREWMmzepaNbBZV5zXGddC3+uzz7TVSOgc 2ZTlXC+1EBoh1THLXy9T+l+m+w/102Mjkj6HfGrORZA2qt0FtOoTzaL/vifxxdBH2Fdv 1IVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770655584; x=1771260384; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lLb8ag3ra6IO++ksPTcs7qsE4fbhw6boR1CyaCV8y8M=; b=rWjjv4uewuyfGoiQghGy5r9li4fSlfCNe1WS++G0IUyf2pg+z2Lgqvr2DVOPv/FBrZ qxCuuiFUW6huvqXyZX4K1kVzv5pE8Qr8pjqUPtg+teeRvLagL5oK8QrF1FYDvolp+4aB L6kYjECqCQHlO02cRyYzsRQTvewyenYFzSGH8xXj2Oz9/1bpAyTHFmR1PjhJnimsBqB1 pYM8Mne++K9VqkaoKqo8L9X8wyjk7HbWqiddbWV229tkgsExIDzcs/RMMTdbyT4ZtQnx wyYrajGEuUk1QaeBwie6FIpdTSHkB3yOIbIIoUYN+IZLpLc2J7TTbKdfIiotxFSmGwd5 gwAA== X-Forwarded-Encrypted: i=1; AJvYcCUCYeL02+3DL9KvgR35CO0sGrOahs2DTeOIPx9/Fh0bq3fJRjyHo3WvahK8eU/zhZO+fMC5ciQ04XHzjLg=@vger.kernel.org X-Gm-Message-State: AOJu0Yxnry9oDD7dAYDbWKeyT+LEe/dYrKU+MOUuxl7XCIwjfBqgnw0f pqLn4b27djgS9wRGLwkr+rNiI9Yn/fQASNmNAPrmJefvQy5JrGWyV5o1 X-Gm-Gg: AZuq6aLbQYKbtoCMZcK2LWAr0DDL3OGrrNzSGcWD2r4a9K7sWFN3O2Ru3tiz81KcHTr umZ2UMEtLIWYCrlsgN2ajHGLBknihmSNQA5+J/n2AK8FVlwiUqcyt7wXtl2RpmoceDW7w6BpFYY 7zZNayzcQCn0vMhAxKaMab4YwsRUyKAjGy74LMX8v1H1fg9sUrsTUqRSWc329toHNtnFLVmzIpj 8cUHd7K8dNVwT8rdfK09YPmAByMC48wDlggiPBc1Im+YRTS1ELIeRy3Y9/AR1cCr1qV8S0LEE2r E1CpQ1MSsxmI+aY3wVaZnYY+jPSRTeI5HTgfngWR0wsuqUjx3bGQpQRFRkvOEP40IeqXy5aaqE1 PVblcgpVpUowLeYCJeZJq3fkVnZU/lSX8WxIaWxqQOGgA6oUImOGJkSDCB+eonz/0K822PZcDoE 37aCLWs4q+lsKyJNL5djJZdah29iSuvp8= X-Received: by 2002:a05:600c:45cb:b0:477:8985:4036 with SMTP id 5b1f17b1804b1-483201dd216mr157441135e9.1.1770655584079; Mon, 09 Feb 2026 08:46:24 -0800 (PST) Received: from [192.168.1.187] ([148.63.225.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4834d5d78cfsm1924275e9.1.2026.02.09.08.46.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Feb 2026 08:46:23 -0800 (PST) Message-ID: Subject: Re: [PATCH v2 2/4] iio: backend: add devm_iio_backend_get_by_index() From: Nuno =?ISO-8859-1?Q?S=E1?= To: David Lechner , Antoniu Miclaus , Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , Nuno =?ISO-8859-1?Q?S=E1?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Olivier Moysan , Mark Brown , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org Date: Mon, 09 Feb 2026 16:47:06 +0000 In-Reply-To: References: <550323d752213f177b7673bdd42e667f1d2228cb.1770393792.git.antoniu.miclaus@analog.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 Mon, 2026-02-09 at 09:28 -0600, David Lechner wrote: > On 2/8/26 3:24 AM, Nuno S=C3=A1 wrote: > > On Fri, 2026-02-06 at 18:07 +0200, Antoniu Miclaus wrote: > > > Add a new function to get an IIO backend by its index in the > > > io-backends device tree property. This is useful for multi-channel > > > devices that have multiple backends, where looking up by index is > > > more straightforward than using named backends. > > >=20 > > > The new function directly uses the index to find the backend referenc= e > > > in the io-backends property, avoiding the need for io-backend-names. > > >=20 > > > Signed-off-by: Antoniu Miclaus > > > --- > > > =C2=A0drivers/iio/industrialio-backend.c | 51 +++++++++++++++++++++++= +++++++ > > > =C2=A0include/linux/iio/backend.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 2 ++ > > > =C2=A02 files changed, 53 insertions(+) > > >=20 > > > diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industr= ialio- > > > backend.c > > > index 447b694d6d5f..3b692d48481e 100644 > > > --- a/drivers/iio/industrialio-backend.c > > > +++ b/drivers/iio/industrialio-backend.c > > > @@ -1008,6 +1008,57 @@ struct iio_backend *devm_iio_backend_get(struc= t device *dev, > > > const char *name) > > > =C2=A0} > > > =C2=A0EXPORT_SYMBOL_NS_GPL(devm_iio_backend_get, "IIO_BACKEND"); > > > =C2=A0 > > > +static struct iio_backend * > > > +__devm_iio_backend_fwnode_get_by_index(struct device *dev, > > > + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct fwnode_handle *fwnod= e, > > > + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned int index) > > > +{ > > > + struct fwnode_handle *fwnode_back; > > > + struct iio_backend *back; > > > + int ret; > > > + > > > + fwnode_back =3D fwnode_find_reference(fwnode, "io-backends", index)= ; > > > + if (IS_ERR(fwnode_back)) > > > + return dev_err_cast_probe(dev, fwnode_back, > > > + =C2=A0 "Cannot get Firmware reference\n"); > > > + > > > + guard(mutex)(&iio_back_lock); > > > + list_for_each_entry(back, &iio_back_list, entry) { > > > + if (!device_match_fwnode(back->dev, fwnode_back)) > > > + continue; > > > + > > > + fwnode_handle_put(fwnode_back); > > > + ret =3D __devm_iio_backend_get(dev, back); > > > + if (ret) > > > + return ERR_PTR(ret); > > > + > > > + back->idx =3D index; > > > + > > > + return back; > > > + } > > > + > > > + fwnode_handle_put(fwnode_back); > > > + return ERR_PTR(-EPROBE_DEFER); > > > +} > >=20 > > I believe we don't necessarily need this. Why can't we use io-backend-n= ames? I get > > that in here we just want something matching the number of channels we = have so giving > > names is probably does not add much added value. But still, I would pre= fer t have > > more simplicity in the API and it should be fairly easy for the fronten= d to use the > > names argument. > >=20 > > _ Nuno S=C3=A1 > >=20 >=20 > IMHO, using names in this case would just be annoying because we would ha= ve to > sprintf the string to add the index to the string. And also have to spend= time > coming up with more complex DT bindings. Using the index seems much simpl= er. >=20 > If you really feel strongly about it though, maybe we could make a > devm_iio_backend_fwnode_get_fmt() function instead that handles the > sprintf() part so that we only have to write that once? >=20 uHu? Maybe I'm completely missing your point but what I had in mind was jus= t something like:=C2=A0 // from the frontend: static const char * const names[] =3D { "adc1", "adc2" } for (c =3D 0; c < ARRAY_SIZE(names); c++) { back =3D devm_iio_backend_get(dev, names[c]); } So yes, I agree we would have a bit more complex bindings and more complexi= ty in the frontend. But on the bright side, no need to change backend code at all. An= d the -names property is already used like the above fairly often If I'm not mist= aken. But again, I can agree that for this usecase getting things by index makes = sense. Given that we just want n backends for n channels, the name does not add much. - Nuno S=C3=A1