| Message ID | 20260604120201.116925-3-vo.kratky@seznam.cz (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-23733-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10]) by mxe881.netcup.net (Postfix) with ESMTPS id B8DD71C1377 for <noreply@patchwork.local>; Thu, 4 Jun 2026 14:12:04 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=seznam.cz; spf=pass (sender IP is 172.234.253.10) smtp.mailfrom=linux-sunxi+bounces-23733-noreply=patchwork.local@lists.linux.dev smtp.helo=sea.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.234.253.10 as permitted sender) client-ip=172.234.253.10; envelope-from=linux-sunxi+bounces-23733-noreply=patchwork.local@lists.linux.dev; helo=sea.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 8572930EDA56 for <noreply@patchwork.local>; Thu, 4 Jun 2026 12:03:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 90489439019; Thu, 4 Jun 2026 12:03:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=seznam.cz header.i=@seznam.cz header.b="lIJ33aU4" X-Original-To: linux-sunxi@lists.linux.dev Received: from mxd.seznam.cz (mxd.seznam.cz [77.75.76.210]) (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 60537407590 for <linux-sunxi@lists.linux.dev>; Thu, 4 Jun 2026 12:03:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=77.75.76.210 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780574597; cv=none; b=L6z+1O9+KQ0zdueMLm3vLk6vJ4MdQRJ7z6AwRpwN+0rQjJC9isR50bdBu1zctWbnb74Ex6YO1XFm8GS6/7+KcsiP7CSNO8NZ4ZLr5LpVMbGBF0CyvpAE5qbJQmL6RoCkTiMTb53ZXofhHJCdWS8wTaTmkXmT7PQ5ODr8ziqs6OE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780574597; c=relaxed/simple; bh=QFEQrU77b3rQqPpg15z8IOQJWoxfKOinMogreiAN7OU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nJIa8xOVHNdeWKaeDYTU5VssIsrffZLt42Yv2I/pvT0H5j0Z0Gu1KClULhkHqfYBPn1XXzwqUh+tMt89LES+ZOcza7zLcwvinCDb34VEt2tfLuXhAXhkXrt343ln/+7WmB+sbsQZb+KYkPsnwtH0MYpOw4d9dHEnlvJs6DniPCM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=seznam.cz; spf=pass smtp.mailfrom=seznam.cz; dkim=pass (2048-bit key) header.d=seznam.cz header.i=@seznam.cz header.b=lIJ33aU4; arc=none smtp.client-ip=77.75.76.210 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=seznam.cz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=seznam.cz Received: from email.seznam.cz by smtpc-mxd-85fb448c55-l247v (smtpc-mxd-85fb448c55-l247v [2a02:598:96:8a00::1200:706]) id 451ebd62fd7190ed47e027fe; Thu, 04 Jun 2026 14:02:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=szn1; t=1780574575; bh=yg44805tHXrZI2MFXh1k7JymAUPm/8cNpCDnOcYJ4LA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=lIJ33aU4RSOjH7pERYIWfnMajC6hGTYYVbtw9DXDvoibOvd72ilxSJFKi3GAr1OH/ 1iYloXtr5Bks67Wuq+auD63ep3apxdaOGN1tlQWl7iS/QoNz2K4ktdqt2vLWAbZjFk 7bHoZtGla0z8rHZOIjGOjglkBkppT0yz1GoLubd0PKqw7kuMdUVESMkDu5hEaEnUHM Rkbwms5Mpn9+EZ5PBimuntCTvygE52AnVi72YyZ38+SQqM5VSZ8HSFzJeWXeWTuTcf R8IgBanROqPZB9hpP15ZDEKuw/u0BVfkQSIcbLP74gvk6T2Cg4opJlVmL/QqohkJMx fMLJPkfBijNGQ== Received: from archlinux (ezechiel.sdb.cz [185.100.196.77]) by smtpd-relay-b58bfc659-k9lmt (szn-email-smtpd/2.0.73) with ESMTPA id a1f98a3b-d877-4d67-a75d-db9b2bd38245; Thu, 04 Jun 2026 14:02:52 +0200 From: =?utf-8?b?Vm9qdMSbY2ggS3LDoXRrw70=?= <vo.kratky@seznam.cz> To: linux-iio@vger.kernel.org Cc: =?utf-8?b?Vm9qdMSbY2ggS3LDoXRrw70=?= <vo.kratky@seznam.cz>, 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>, Sakari Ailus <sakari.ailus@linux.intel.com>, Linus Walleij <linusw@kernel.org>, Wolfram Sang <wsa+renesas@sang-engineering.com>, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 02/11] iio: adc: change from %ld to %pe for PTR_ERR() printing Date: Thu, 4 Jun 2026 13:59:22 +0200 Message-ID: <20260604120201.116925-3-vo.kratky@seznam.cz> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260604120201.116925-1-vo.kratky@seznam.cz> References: <20260604120201.116925-1-vo.kratky@seznam.cz> 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 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 |
None
|
|
Commit Message
Vojtěch Krátký
June 4, 2026, 11:59 a.m. UTC
Replace numeric PTR_ERR() logging with the %pe format specifier
so that error values are printed in a more readable form.
This change was identified using a Coccinelle semantic patch.
No functional change intended.
Signed-off-by: Vojtěch Krátký <vo.kratky@seznam.cz>
---
drivers/iio/adc/sun4i-gpadc-iio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: Pre-existing issues: - [High] Direct return on devm_thermal_of_zone_register failure skips critical error cleanup (PM leak and Use-After-Free). - [High] Unbalanced disable_irq() on sun4i_prepare_for_irq() error path permanently disables the IRQ. -- commit 4c81144898d1e91a3f1c0bfb6354a6f38c7251b4 Author: Vojtěch Krátký <vo.kratky@seznam.cz> iio: adc: change from %ld to %pe for PTR_ERR() printing This commit replaces numeric PTR_ERR() logging with the %pe format specifier. The goal is to print error values in a more readable form. > diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c > index 479115ea50bf9..5d7a61abcaeae 100644 > --- a/drivers/iio/adc/sun4i-gpadc-iio.c > +++ b/drivers/iio/adc/sun4i-gpadc-iio.c [ ... ] > @@ -639,8 +639,8 @@ static int sun4i_gpadc_probe(struct platform_device *pdev) > */ > if (IS_ERR(info->tzd) && PTR_ERR(info->tzd) != -ENODEV) { > dev_err(&pdev->dev, > - "could not register thermal sensor: %ld\n", > - PTR_ERR(info->tzd)); > + "could not register thermal sensor: %pe\n", > + info->tzd); > return PTR_ERR(info->tzd); [Severity: High] This isn't a bug introduced by this patch, but returning directly here skips the err_map cleanup label. If devm_thermal_of_zone_register() fails with an error other than -ENODEV, this code returns directly. Does this leave the device's runtime PM enabled because the pm_runtime_disable() call in the err_map block is skipped? Also, if the device was probed via sun4i_gpadc_probe_mfd(), iio_map_array_register() was successfully called earlier: drivers/iio/adc/sun4i-gpadc-iio.c:sun4i_gpadc_probe_mfd() { ... ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps); ... } By skipping iio_map_array_unregister() at the err_map label, does this leave a dangling pointer in the global IIO maps pointing to indio_dev? Since indio_dev is managed by devres (devm_iio_device_alloc), its memory will be freed immediately upon probe failure. Could this result in a use-after-free when another subsystem attempts to read from the map? > } > } While reviewing this file, I also noticed another pre-existing regression in sun4i_gpadc_read(). [Severity: High] This is a pre-existing issue, but does the unbalanced disable_irq() on the sun4i_prepare_for_irq() error path permanently disable the IRQ? drivers/iio/adc/sun4i-gpadc-iio.c:sun4i_gpadc_read() { ... ret = sun4i_prepare_for_irq(indio_dev, channel, irq); if (ret) goto err; enable_irq(irq); ... err: pm_runtime_put_autosuspend(indio_dev->dev.parent); disable_irq(irq); mutex_unlock(&info->mutex); } If sun4i_prepare_for_irq() fails, the code jumps to the err label and unconditionally executes disable_irq(irq). Because enable_irq(irq) was never reached, this increases the IRQ disable depth. Since the IRQs are initially requested with IRQF_NO_AUTOEN (initial depth = 1), the unbalanced disable_irq() bumps the depth to 2. On subsequent successful reads, enable_irq() will only decrement the depth back to 1. Does this leave the IRQ permanently masked, causing wait_for_completion_timeout() to continually time out?
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c index 479115ea50bf..5d7a61abcaea 100644 --- a/drivers/iio/adc/sun4i-gpadc-iio.c +++ b/drivers/iio/adc/sun4i-gpadc-iio.c @@ -508,7 +508,7 @@ static int sun4i_gpadc_probe_dt(struct platform_device *pdev, &sun4i_gpadc_regmap_config); if (IS_ERR(info->regmap)) { ret = PTR_ERR(info->regmap); - dev_err(&pdev->dev, "failed to init regmap: %d\n", ret); + dev_err(&pdev->dev, "failed to init regmap: %pe\n", info->regmap); return ret; } @@ -639,8 +639,8 @@ static int sun4i_gpadc_probe(struct platform_device *pdev) */ if (IS_ERR(info->tzd) && PTR_ERR(info->tzd) != -ENODEV) { dev_err(&pdev->dev, - "could not register thermal sensor: %ld\n", - PTR_ERR(info->tzd)); + "could not register thermal sensor: %pe\n", + info->tzd); return PTR_ERR(info->tzd); } }