From patchwork Thu May 9 15:39:33 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Lindgren X-Patchwork-Id: 2544541 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by patchwork2.kernel.org (Postfix) with ESMTP id C9DC6DF24C for ; Thu, 9 May 2013 15:40:14 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UaSwz-0004pn-JS; Thu, 09 May 2013 15:40:09 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UaSww-0006wa-M3; Thu, 09 May 2013 15:40:06 +0000 Received: from mho-02-ewr.mailhop.org ([204.13.248.72]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UaSwt-0006w7-F6 for linux-arm-kernel@lists.infradead.org; Thu, 09 May 2013 15:40:04 +0000 Received: from c-50-131-214-131.hsd1.ca.comcast.net ([50.131.214.131] helo=localhost.localdomain) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1UaSwR-000EBa-V9; Thu, 09 May 2013 15:39:36 +0000 Received: from Mutt by mutt-smtp-wrapper.pl 1.2 (www.zdo.com/articles/mutt-smtp-wrapper.shtml) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.131.214.131 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX193nZhLcY9Q2Uuyo9+mR59T Date: Thu, 9 May 2013 08:39:33 -0700 From: Tony Lindgren To: Russell King - ARM Linux Subject: Re: arch/arm/mach-omap2/id.c - IS_ERR_OR_NULL() Message-ID: <20130509153933.GA31554@atomide.com> References: <20130509090911.GM21614@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130509090911.GM21614@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130509_114003_527321_77B4F99A X-CRM114-Status: GOOD ( 18.42 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [204.13.248.72 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org * Russell King - ARM Linux [130509 02:14]: > So, I eliminated all but a very few of these from arch/arm, and I notice > today that there's a new couple of instances introduced by: Sorry I should have noticed that fnord, I had it in my muttrc but had a an unnecessary \ in the expression so it did not work. Here's a patch to fix the issue. Hmm maybe we could redefine IS_ERR_OR_NULL as error in some ARM header as long as drivers don't include it? Regards, Tony From: Tony Lindgren Date: Thu, 9 May 2013 08:27:25 -0700 Subject: [PATCH] ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c Commit 6770b211 (ARM: OMAP2+: Export SoC information to userspace) had some broken return value handling as noted by Russell King: + soc_dev = soc_device_register(soc_dev_attr); + if (IS_ERR_OR_NULL(soc_dev)) { + kfree(soc_dev_attr); + return; + } + + parent = soc_device_to_device(soc_dev); + if (!IS_ERR_OR_NULL(parent)) + device_create_file(parent, &omap_soc_attr); This is nonsense. For the first, IS_ERR() is sufficient. For the second, tell me what error checking is required in the return value of this function: struct device *soc_device_to_device(struct soc_device *soc_dev) { return &soc_dev->dev; } when you've already determined that the passed soc_dev is a valid pointer. If you read the comments against the prototype: /** * soc_device_to_device - helper function to fetch struct device * @soc: Previously registered SoC device container */ struct device *soc_device_to_device(struct soc_device *soc); if "soc" is valid, it means the "previously registered SoC device container" must have succeeded and that can only happen if the struct device has been registered. Ergo, there will always be a valid struct device pointer for any registered SoC device container. Therefore, if soc_device_register() succeeds, then the return value from soc_device_to_device() will always be valid and no error checking of it is required. Simples. The rule as ever applies here: get to know the APIs your using and don't fumble around in the dark hoping that you'll get this stuff right. Fix it as noted by Russell. Reported-by: Russell King Signed-off-by: Tony Lindgren diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 9bc5a18..1272c41 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -648,13 +648,12 @@ void __init omap_soc_device_init(void) soc_dev_attr->revision = soc_rev; soc_dev = soc_device_register(soc_dev_attr); - if (IS_ERR_OR_NULL(soc_dev)) { + if (IS_ERR(soc_dev)) { kfree(soc_dev_attr); return; } parent = soc_device_to_device(soc_dev); - if (!IS_ERR_OR_NULL(parent)) - device_create_file(parent, &omap_soc_attr); + device_create_file(parent, &omap_soc_attr); } #endif /* CONFIG_SOC_BUS */