Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1917348ybl; Sat, 10 Aug 2019 12:28:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqzOo13X9vloB/GZ4d2WJec7Ach3tlWYTxMe4lBQpvgpuGfoaSzybrq+NaQHQB1EKsf3fHmW X-Received: by 2002:a17:90a:db08:: with SMTP id g8mr15330687pjv.39.1565465330881; Sat, 10 Aug 2019 12:28:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565465330; cv=none; d=google.com; s=arc-20160816; b=OYbyY1LrQrBznuVJmXJHveFEeynR2NzjrS9Ve3fhCd3HrUzplomgdk3Ev0tde3NtP5 x3dTcy+V6axUydsb93bS9/7jJ36uAyrpGpY0Z2Wix19tFqvkf5ENCknWLE9PHRplPvmz 17Z0266pdu6aEmZUKqGjEGraploExCdoXKz6WKDcEmoQw+OQjSD+U+qSyYkzXiF3h1y6 jZ8wjLDdHPLANnOqDtKBGU0pkaaNO6g06lQlnz1tF2FeqIzYYVjCVDjWVQ0WyPGy6IoQ UnTOg+5DLKhNGKycvxeMwVdUFsvCWN4mh82k58U5LrBBaJd6wd5wQGYow19SjKHPxyod rSXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=2uFK9z5krg0H8/9crNiTWxgcFxHH5iz+VrnuHe2Blhs=; b=Rfq3y002wlm5Opuw9/muEcgOZTkx0RVAKfGHNjYVYX4oqRiBYMjIfBHrBgMQ5ejbpZ ZoiE6SGIIlce0xJ5V9OZKlV8jSiuZydvX0Ol54DsMkEQYhpbAH0HiQ7pb7dmbca4+UME 7MV6Wx8Oo15VcKbXRw/1K+2zAqwb0MRIJSk5Mw07pEYhIfIvzqWd6pHpyg5jtDxn93Ha ohU+q+Lp+4tvnO3aRs/c4OZ3oOPGA4qzEhUzzgBNjJbRyHcguUNhuMdmptVBqM+UKdCK /4AQcLGXmEXiTk7gdiRWeuU+yrnxU6AArqkP2Mjn+86jM8JUU53enBh1sZruuPmAZGqU SLlQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 16si10769722pfc.213.2019.08.10.12.28.33; Sat, 10 Aug 2019 12:28:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726341AbfHJT1r (ORCPT + 99 others); Sat, 10 Aug 2019 15:27:47 -0400 Received: from smtp08.smtpout.orange.fr ([80.12.242.130]:41473 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726104AbfHJT1r (ORCPT ); Sat, 10 Aug 2019 15:27:47 -0400 Received: from belgarion ([90.76.53.202]) by mwinf5d31 with ME id nXTS2000D4MlyVm03XTeb7; Sat, 10 Aug 2019 21:27:43 +0200 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Sat, 10 Aug 2019 21:27:43 +0200 X-ME-IP: 90.76.53.202 From: Robert Jarzmik To: Greg Kroah-Hartman Cc: dan.j.williams@intel.com, vkoul@kernel.org, Daniel Mack , Haojian Zhuang , linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/6] dma: pxa_dma: no need to check return value of debugfs_create functions References: <20190612122557.24158-1-gregkh@linuxfoundation.org> <20190612122557.24158-4-gregkh@linuxfoundation.org> X-URL: http://belgarath.falguerolles.org/ Date: Sat, 10 Aug 2019 21:27:26 +0200 In-Reply-To: <20190612122557.24158-4-gregkh@linuxfoundation.org> (Greg Kroah-Hartman's message of "Wed, 12 Jun 2019 14:25:55 +0200") Message-ID: <87tvaorfc1.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/26 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greg Kroah-Hartman writes: Hi Greg, > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Also, because there is no need to save the file dentry, remove the > variable that was saving it as it was never even being used once set. > > Cc: Daniel Mack > Cc: Haojian Zhuang > Cc: Robert Jarzmik > Cc: Vinod Koul > Cc: Dan Williams > Cc: linux-arm-kernel@lists.infradead.org > Cc: dmaengine@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Greg Kroah-Hartman > --- > drivers/dma/pxa_dma.c | 56 +++++++++---------------------------------- > 1 file changed, 11 insertions(+), 45 deletions(-) > > diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c > index b429642f3e7a..0f698f49ee26 100644 > --- a/drivers/dma/pxa_dma.c > +++ b/drivers/dma/pxa_dma.c > @@ -132,7 +132,6 @@ struct pxad_device { > spinlock_t phy_lock; /* Phy association */ > #ifdef CONFIG_DEBUG_FS > struct dentry *dbgfs_root; > - struct dentry *dbgfs_state; > struct dentry **dbgfs_chan; > #endif > }; > @@ -326,31 +325,18 @@ static struct dentry *pxad_dbg_alloc_chan(struct pxad_device *pdev, > int ch, struct dentry *chandir) > { > char chan_name[11]; > - struct dentry *chan, *chan_state = NULL, *chan_descr = NULL; > - struct dentry *chan_reqs = NULL; > + struct dentry *chan; > void *dt; > > scnprintf(chan_name, sizeof(chan_name), "%d", ch); > chan = debugfs_create_dir(chan_name, chandir); > dt = (void *)&pdev->phys[ch]; > > - if (chan) > - chan_state = debugfs_create_file("state", 0400, chan, dt, > - &chan_state_fops); > - if (chan_state) > - chan_descr = debugfs_create_file("descriptors", 0400, chan, dt, > - &descriptors_fops); > - if (chan_descr) > - chan_reqs = debugfs_create_file("requesters", 0400, chan, dt, > - &requester_chan_fops); > - if (!chan_reqs) > - goto err_state; > + debugfs_create_file("state", 0400, chan, dt, &chan_state_fops); > + debugfs_create_file("descriptors", 0400, chan, dt, &descriptors_fops); > + debugfs_create_file("requesters", 0400, chan, dt, &requester_chan_fops); This is not strictly equivalent. Imagine that the debugfs_create_dir() fails and returns NULL : - in the former case, neither "state", "descriptors" nor "requesters" would be created - in the new code, "state", "descriptors" nor "requesters" will be created in the debugfs root directory Apart from that it looks fine. Cheers. -- Robert