| Message ID | 20260514-fix-sunxi-gpadc-sparse-channels-v2-1-d4a66b70c7a7@mmpsystems.pl (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-23358-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114]) by mxe881.netcup.net (Postfix) with ESMTPS id 671BC1C07AC for <noreply@patchwork.local>; Thu, 14 May 2026 05:20:17 +0200 (CEST) Authentication-Results: mxe881; dkim=fail header.d=mmpsystems.pl; spf=pass (sender IP is 172.105.105.114) smtp.mailfrom=linux-sunxi+bounces-23358-noreply=patchwork.local@lists.linux.dev smtp.helo=tor.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.105.105.114 as permitted sender) client-ip=172.105.105.114; envelope-from=linux-sunxi+bounces-23358-noreply=patchwork.local@lists.linux.dev; helo=tor.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id A7030300E5F8 for <noreply@patchwork.local>; Thu, 14 May 2026 03:20:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BC612225416; Thu, 14 May 2026 03:20:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=mmpsystems.pl header.i=@mmpsystems.pl header.b="QYij6wex" X-Original-To: linux-sunxi@lists.linux.dev Received: from s106b.cyber-folks.pl (s106b.cyber-folks.pl [195.78.66.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99B802236E3; Thu, 14 May 2026 03:20:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.78.66.88 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778728809; cv=none; b=VOwuWo4pBs4lUFhKiFAJ+l28JBWK5tqFXdEINFnp+Vg8N+f/+LaxLmwbWfKbSjTkCVJIsaHnY0Qn8SUo+Fh4CzB4IHh76xXENtirn/h+oQ8KXz6TpT+Ir/7AkSGY+4bFbHP6V4SbmwuewUWVlpvpYnha+EVOPHGUXkUGW1+YZI4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778728809; c=relaxed/simple; bh=mAW9smyP3Y9zNh0IDxgH/7BBIen5KUX/2eJMMof12rc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=VcomS5/ueECyNovbu5QAkZJWIppg9HylF8Jx9cAkywY7YzP+/ns239Zyj8osreNE561kr3fo+5NJEx9qF531BsUx8l0w7Kuio5+g9Gc2fg/BIOkwPYp5fV6FvzRBp/Hm9cgToiLl+nMo7sWTUZ6uEIdBu3n+krWjI7J5rBUmWvQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mmpsystems.pl; spf=pass smtp.mailfrom=mmpsystems.pl; dkim=pass (2048-bit key) header.d=mmpsystems.pl header.i=@mmpsystems.pl header.b=QYij6wex; arc=none smtp.client-ip=195.78.66.88 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mmpsystems.pl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mmpsystems.pl DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mmpsystems.pl; s=x; h=Cc:To:Message-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:Subject:Date:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=V8Zv1XxU0NXRkczbbte8VINxmUP6BumFNP4JQShgmbg=; b=QYij6wexY6658C8GQB+Ud1GMHS UexeAtIdV4B5jonQ3oMluQfemg78ENfSZp7IWxTW2ohf83AwadBuA6hoI/Gjz7W6jgvVo5U39RtrT U6vHE0YbnzgzQtUoK3h4OZLc2YA74CM0L0Gly5RhPk2x9l1BR67iZhRUg4w6+HzrI2ekkoRC123Y1 ICxbqKyo1qJriSlFf9dvFHW73Uz0ZYiezUn/FeWy0bc5y5HiFcpbdUhCZlRP2cfa7Ef23FPK15v9X Cn1xO56b2RgSt3vG2hhCbgYlCBwN8TAJ1zkIYU+gLB7eSCKb+U5ubZahS8TzVeqSdqMbTRIpMuX41 YIheyFzg==; Received: from [91.102.182.218] (helo=localhost) by s106.cyber-folks.pl with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from <michal.piekos@mmpsystems.pl>) id 1wNMc8-0000000H9MG-1Eyv; Thu, 14 May 2026 05:19:56 +0200 From: Michal Piekos <michal.piekos@mmpsystems.pl> Date: Thu, 14 May 2026 05:19:34 +0200 Subject: [PATCH v2] iio: adc: sun20i-gpadc: support non-contiguous channel lookups Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: <20260514-fix-sunxi-gpadc-sparse-channels-v2-1-d4a66b70c7a7@mmpsystems.pl> X-B4-Tracking: v=1; b=H4sIAEU/BWoC/42OTQ6DIBBGr2JYdxrAlsSueo/GheBUaRQJg0Zjv HvBXqDLl7zvZ2eEwSKxR7GzgIslO7kE8lIw0zeuQ7BtYia5VPwuSnjbFWh2q4XON60B8k0ghCw 7HAikVlpyVer2VrHU4gOmyLnwqn9Ms/6gibk2G72lOIXtvLCI7P2/tggQoIwUKCuuDeJzHD1tF HGkqx9YfRzHF6qVKH3kAAAA X-Change-ID: 20260513-fix-sunxi-gpadc-sparse-channels-2b6b2063bd49 To: Jonathan Cameron <jic23@kernel.org>, David Lechner <dlechner@baylibre.com>, =?utf-8?q?Nuno_S=C3=A1?= <nuno.sa@analog.com>, Andy Shevchenko <andy@kernel.org>, Chen-Yu Tsai <wens@kernel.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org> Cc: linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Michal Piekos <michal.piekos@mmpsystems.pl>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <nick.desaulniers+lkml@gmail.com>, Bill Wendling <morbo@google.com>, Justin Stitt <justinstitt@google.com>, llvm@lists.linux.dev X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1778728785; l=2567; i=michal.piekos@mmpsystems.pl; s=20260301; h=from:subject:message-id; bh=mAW9smyP3Y9zNh0IDxgH/7BBIen5KUX/2eJMMof12rc=; b=IzE2aCtNGPDvgiHxMVpRWxq6l4Hz7kBMcZiHPIsDF1KFpqFB8KN5/bGtIJbN82SZJaMKOPjtR AyNgm7Y1d/EClBYHORnzkw4FSpaGRdXUTikaUr9cxnFtfZu18gfBWjD X-Developer-Key: i=michal.piekos@mmpsystems.pl; a=ed25519; pk=Aixyx03If7ZDamiKKN0lsa+0mtA+WjIuIf2ZQVYNBqg= X-Authenticated-Id: michal.piekos@mmpsystems.pl X-Rspamd-Server: rspamd-worker-8404 X-Spamd-Result: default: False [-0.16 / 15.00]; BAYES_HAM(-5.50)[99.99%]; RBL_SENDERSCORE(2.00)[172.105.105.114:from]; SUSPICIOUS_RECIPS(1.50)[]; R_DKIM_REJECT(1.00)[mmpsystems.pl:s=x]; DMARC_POLICY_SOFTFAIL(1.00)[mmpsystems.pl : SPF not aligned (relaxed),none]; MAILLIST(-0.15)[generic]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; HAS_LIST_UNSUB(-0.01)[]; TAGGED_RCPT(0.00)[lkml]; PRECEDENCE_BULK(0.00)[]; RCPT_COUNT_TWELVE(0.00)[17]; FUZZY_BLOCKED(0.00)[rspamd.com]; FORGED_SENDER_MAILLIST(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[tor.lore.kernel.org:rdns,tor.lore.kernel.org:helo]; FREEMAIL_CC(0.00)[vger.kernel.org,lists.infradead.org,lists.linux.dev,mmpsystems.pl,kernel.org,gmail.com,google.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[mmpsystems.pl:-]; ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1]; R_SPF_ALLOW(0.00)[+ip4:172.105.105.114:c]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; FREEMAIL_TO(0.00)[kernel.org,baylibre.com,analog.com,gmail.com,sholland.org]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:63949, ipnet:172.105.96.0/20, country:SG]; TAGGED_FROM(0.00)[bounces-23358-noreply=patchwork.local]; RCVD_COUNT_FIVE(0.00)[5]; FROM_NEQ_ENVFROM(0.00)[michal.piekos@mmpsystems.pl,linux-sunxi@lists.linux.dev]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 671BC1C07AC X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
[v2] iio: adc: sun20i-gpadc: support non-contiguous channel lookups
|
|
Commit Message
Michal Piekos
May 14, 2026, 3:19 a.m. UTC
Using consumer driver like iio-hwmon which resolve channels thorugh
io-channels phandles will fail for sparse channels because IIO core by
default threats phandle argument as index into channel array.
eg. <&gpadc 1> will fail if there is only channel@1 specified
Add .fwnode_xlate() which maps DT phandle to the registered channel
whose chan->channel matches the hardware channel number. It allows
sparse channel maps to be consumed by drivers like iio-hwmon.
Tested on Radxa Cubie A5E.
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
Changes in v2:
- Move loop variable declaration into the for statement
- Fix indentation using clang-format
- Correct commit wording
- Link to v1: https://patch.msgid.link/20260513-fix-sunxi-gpadc-sparse-channels-v1-1-6c21e290bcee@mmpsystems.pl
To: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
To: Nuno Sá <nuno.sa@analog.com>
To: Andy Shevchenko <andy@kernel.org>
To: Chen-Yu Tsai <wens@kernel.org>
To: Jernej Skrabec <jernej.skrabec@gmail.com>
To: Samuel Holland <samuel@sholland.org>
To: Nathan Chancellor <nathan@kernel.org>
To: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
To: Bill Wendling <morbo@google.com>
To: Justin Stitt <justinstitt@google.com>
Cc: linux-iio@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-sunxi@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
Cc: llvm@lists.linux.dev
---
drivers/iio/adc/sun20i-gpadc-iio.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
---
base-commit: 1d5dcaa3bd65f2e8c9baa14a393d3a2dc5db7524
change-id: 20260513-fix-sunxi-gpadc-sparse-channels-2b6b2063bd49
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
Comments
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] Missing validation of iiospec->nargs leads to uninitialized stack memory read - [Low] Spelling and grammar errors in the commit message -- commit 0da362a2628891f0ec84a4906fcbc3b1521286d2 Author: Michal Piekos <michal.piekos@mmpsystems.pl> iio: adc: sun20i-gpadc: support non-contiguous channel lookups This commit adds a fwnode_xlate callback to support sparse channel maps by mapping the devicetree phandle argument to the registered channel whose ID matches the hardware channel number. > Using consumer driver like iio-hwmon which resolve channels thorugh > io-channels phandles will fail for sparse channels because IIO core by > default threats phandle argument as index into channel array. This isn't a bug, but there are typos in the commit message: "thorugh" instead of "through", and "threats" instead of "treats". > diff --git a/drivers/iio/adc/sun20i-gpadc-iio.c b/drivers/iio/adc/sun20i-gpadc-iio.c > index 861c14da75add..78c9a52f38df0 100644 > --- a/drivers/iio/adc/sun20i-gpadc-iio.c > +++ b/drivers/iio/adc/sun20i-gpadc-iio.c [ ... ] > @@ -139,8 +139,20 @@ static irqreturn_t sun20i_gpadc_irq_handler(int irq, void *data) > return IRQ_HANDLED; > } > > +static int > +sun20i_gpadc_fwnode_xlate(struct iio_dev *indio_dev, > + const struct fwnode_reference_args *iiospec) > +{ > + for (unsigned int i = 0; i < indio_dev->num_channels; i++) > + if (indio_dev->channels[i].channel == iiospec->args[0]) Is it possible to read uninitialized stack memory here? The IIO core function __fwnode_iio_channel_get() allocates iiospec on the stack without zero-initializing it. When parsing a reference from a malformed devicetree node (e.g., #io-channel-cells = <0>), an ACPI table, or a software node, fwnode_property_get_reference_args() returns success and sets iiospec->nargs = 0 but leaves the args array unmodified. If iiospec->nargs is not verified, this evaluates iiospec->args[0] using uninitialized memory. If this garbage data happens to match an existing channel ID, the driver could spuriously map a random channel. Should this function check if iiospec->nargs < 1 before accessing the arguments array? > + return i; > + > + return -EINVAL; > +} > +
On Thu, May 14, 2026 at 05:19:34AM +0200, Michal Piekos wrote: > Using consumer driver like iio-hwmon which resolve channels thorugh > io-channels phandles will fail for sparse channels because IIO core by > default threats phandle argument as index into channel array. > eg. <&gpadc 1> will fail if there is only channel@1 specified > > Add .fwnode_xlate() which maps DT phandle to the registered channel > whose chan->channel matches the hardware channel number. It allows > sparse channel maps to be consumed by drivers like iio-hwmon. > > Tested on Radxa Cubie A5E. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
diff --git a/drivers/iio/adc/sun20i-gpadc-iio.c b/drivers/iio/adc/sun20i-gpadc-iio.c index 861c14da75ad..78c9a52f38df 100644 --- a/drivers/iio/adc/sun20i-gpadc-iio.c +++ b/drivers/iio/adc/sun20i-gpadc-iio.c @@ -139,8 +139,20 @@ static irqreturn_t sun20i_gpadc_irq_handler(int irq, void *data) return IRQ_HANDLED; } +static int +sun20i_gpadc_fwnode_xlate(struct iio_dev *indio_dev, + const struct fwnode_reference_args *iiospec) +{ + for (unsigned int i = 0; i < indio_dev->num_channels; i++) + if (indio_dev->channels[i].channel == iiospec->args[0]) + return i; + + return -EINVAL; +} + static const struct iio_info sun20i_gpadc_iio_info = { .read_raw = sun20i_gpadc_read_raw, + .fwnode_xlate = sun20i_gpadc_fwnode_xlate, }; static void sun20i_gpadc_reset_assert(void *data)