From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 142B8C83F12 for ; Mon, 28 Aug 2023 13:36:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MoAu8QbMIOFvvBcIyivWEQi4HaxQtC0O0dPf53w4dnk=; b=nqKoaVwqLmHxpr wh/QzfsvGYXTsqRSJoTFgjsV4f8FLGwfq+k846mIjrlHSkbuyjairAYZmoo00wTwhWLFV1enyEmDE PKCmiXjcK7sNX07sNXzBOSAFCqJT67b78i4bUhMAVfFJx6fgCuZxy30oSSo+qOWi0BtktVpsl9oH+ bhIiO0f2O6JH4Gy9wF29O2K4mOQw5Pkq3poSq1GlLBeuy1SZppGmxdSVcsIBeI7G0UTnB9wk8GQgh o2PUGrYujq8hw51eDgHAUrDJqcm2TKWRqJy/dTFYHZviK/5XqlczuTFwS0/rnoPmKBv/ya2+oxek5 dj3kmT48OBV+ZPOHSwXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qacPQ-009e66-0h; Mon, 28 Aug 2023 13:36:00 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qacPN-009e5X-0J for linux-arm-kernel@lists.infradead.org; Mon, 28 Aug 2023 13:35:58 +0000 Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-26f3975ddd4so2030078a91.1 for ; Mon, 28 Aug 2023 06:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693229755; x=1693834555; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=auACfXGCbbFOjB74ybEF5PVfXFncMm7FKTVCup4nmSo=; b=pkRtKdz88GxIDbRaMkj5fW3vKxh/MAV7cl5mx7RZiLDySt3g7Yb6VnnFbv28BKybqh r+79lVauJuvdY1+lqzPPzfiqWCVOlNgr0+LciOjJzvRGiwAste4+er+0J96hKdpAz1f7 Yio3aKqzQezji6rhTpQilqhJoBZNHjaZbrwv48Kepy397tcfropdqNMlBH7GsKq2LcbT Jw6CGEFS8HA5nB7+knscdH1ieuHGFa/wSG6KG2DyQD09MEFAdkTvDwzF1Yrrq1yH4SQ5 kfHlZ4Q91aq3jOZ5iKO86uGBUo3lM/HpQ7J92m6eOmlQ2HCvu0xwjk9TQVm5uvk7NiqN 7+CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693229755; x=1693834555; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=auACfXGCbbFOjB74ybEF5PVfXFncMm7FKTVCup4nmSo=; b=Mx2/e/45UOyLNtM+5xqiTy+fSqTWaXJhE8fF2QW+a6ah+slnloYWSVuEDfB2c8meJZ fCFAptZ2CM/oojrRlX2MKX/GwVxhI/EBJ//WPy37s2dOhjDf4eogC9W26LCMRZEiZfN1 5OrsRVU61KYazP2VgGpJq4h9jlFJsVbT1DtzJOGjSLWbwykAM9H7YwlFPMkpDx2inSw2 +80RWjC/qjXOwHqyLCwcZ55dozA7ywt+3SU79F/jQuFog4lpTuDJ/gkinvnX3AC1PiCX LoEdR2X+KawLXUFyByww4BOGcd3GI3VE0eWjdJnqkS+/sOKZd/2Vl1foZs5wH2seHt13 pN/Q== X-Gm-Message-State: AOJu0Yw2s93/VywqjH49AEq36D8HSMxUWih/MHJf2nHOidQTNRXEmGPu Bs3Fc3AxfIGBLEx/4Xltf64= X-Google-Smtp-Source: AGHT+IGIKxvNNfzWtwnnWnDF807M3LgxxR/+xOoa0ANvJEePdvoDZBASveP8tGfSRLviYuVgBl1ICA== X-Received: by 2002:a17:90b:14d:b0:26d:17d6:399d with SMTP id em13-20020a17090b014d00b0026d17d6399dmr24900491pjb.38.1693229755484; Mon, 28 Aug 2023 06:35:55 -0700 (PDT) Received: from atom0118 ([2405:201:6815:d8ef:d0d4:95e1:652c:465b]) by smtp.gmail.com with ESMTPSA id o7-20020a17090a4b4700b0025be7b69d73sm7099991pjl.12.2023.08.28.06.35.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Aug 2023 06:35:54 -0700 (PDT) Date: Mon, 28 Aug 2023 19:05:47 +0530 From: Atul Kumar Pant To: Michal Simek Cc: shubhrajyoti.datta@amd.com, sai.krishna.potthuri@amd.com, bp@alien8.de, tony.luck@intel.com, james.morse@arm.com, mchehab@kernel.org, rric@kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, shuah@kernel.org Subject: Re: [PATCH v1] drivers: edac: Drop unnecessary error check for debugfs_create_dir Message-ID: <20230828133547.GA58271@atom0118> References: <20230815203826.51792-1-atulpant.linux@gmail.com> <723e803b-6f8b-ceb3-e987-4a6f83d89222@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <723e803b-6f8b-ceb3-e987-4a6f83d89222@amd.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230828_063557_137506_8E937EE3 X-CRM114-Status: GOOD ( 27.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 25, 2023 at 09:31:54AM +0200, Michal Simek wrote: > > > On 8/15/23 22:38, Atul Kumar Pant wrote: > > This patch removes the error checking for debugfs_create_dir. > > Avoid using "This patch". Thanks for pointing this out. I'll remember this. > > > Even if we get an error from this function, other debugfs APIs will > > handle the error value and doesn't crash in that case. Hence caller can > > safely ignore the errors that occur during the creation of debugfs nodes. > > First of all which issue do you have? Did you see that folder is not created? I have not seen any issue as such. But going by the comments before the debugfs_create_dir API (https://elixir.bootlin.com/linux/latest/source/fs/debugfs/inode.c#L583), we can ignore safely ignore the return value from this API. > > I am not quite sure if this is the right behavior. > In the code there is > 135 if (!parent) > 136 parent = edac_debugfs; > > It means you are right that if creating ocm folder can fail and properties > will be still created under edac_debugfs but is this the right behavior? > > altera_edac/armada_xp_edac/i10nm/i5100/igen6/others are checking return > value that's why I can't see any reason to remove this checking from one > driver. > > If you want to fix all please send patch for all but I don't think it will > improve situation and it will just hide different issue if creating folder > fails. Understood your point. Are you suggesting that we should keep these checks as it is, or should I fix for all the drivers and upload the patch ? > And debugfs will be disabled in production system anyway. > > Thanks, > Michal > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel